It seems the excitement and use of Class, Responsibility, Collaboration (CRC) cards has diminished over the years. But with an emphasis on agile development approaches, it seems there is a rise in simple, yet powerful approaches that are low tech. The barrier to entry for CRC cards is pretty low…you just need a pile of 3″x5″ or 4″x6″ index cards and a pen.

Are CRC big upfront design? I don’t think so, but it is a potentially conflicting with Test Driven Development (TDD). I see the greatest value of CRC cards as a way to get a sense for the initial high-level design and not a way to work through the design of every low-level class in a system. This may be most useful in the case of a service oriented system, for example, where you may desire a bit of focus up front on the exposed external interface. Or better yet, a way to talk through a design if you get “stuck”. The downside of CRC cards is that you are not keeping a client-oriented view like you do when using TDD. A client-oriented view is critical to good design and is one of the natural advantages to TDD.

Back to CRC cards…The idea is that each physical index card represents a single class or interface. Each card should have the name of the class at the top, the class responsibility (note that conscious choice to make this singular) on the bottom left and the classes with which the given class collaborates on the bottom right.

CRC Card

I like the smaller 3″x5″ cards because you want to be constrained by space. If you write your class responsibility (typically captured as bullets) and you find that you are running out of room on your card because it is requiring too many bullets, you have already identified that you are likely violating the SRP and you need to break the class up into separate classes or at least rethink your design. If you run out of space for your collaborations, you also likely have an issue.

I like to arrange the cards physically on a table so they are arranged close to their collaborators. The process is typically done with a pair or group of developers and involves a lot of discussion as the cards are created and modified. The cards are a jumpstart mechaims, and like many other artifacts in an agile project, they will be discarded and the software will take on a life of its own.

I have always admired the cleverness of the name Hollywood Principle. I love its name! The essence of this principle is “don’t call us, we’ll call you”. As you know, this is a response you might hear after auditioning for a role in a Hollywood movie. And this is the same concept for the software Hollywood Principle too. The intent is to take care to structure and implement your dependencies wisely.

At its most basic level, the principle is about reducing the coupling in a software system. It gets back to the well known phrase in software development: loose coupling and high cohesion. You can keep classes loosely coupled by ensuring that you don’t have unnecessary references and you are referencing classes and other subsystems properly. Although the Hollywood Principle does not dictate anything about cohesion, it is an important aspect too. Cohesion is about keeping your classes true to their intent and not allowing their behavior to expand beyond its core purpose. Like high coupling, low cohesion doesn’t tend to cause systems to be unstable or not work properly, but will likely lead to difficulty in maintaining the software.

One of the most popular ways to implement, or obey, the Hollywood principle is to use events or callbacks. A well known pattern that follows the Hollywood principle is the observer pattern. This pattern allows one to observe the state of an object in a well defined and non obtrusive manner. It is typically implemented by injecting a callback object (observer) into the class to be observed (subject). The subject simply raises an event in all observers when its state changes. How the observer reacts to the event is outside the scope or care of the subject.

Dependency Injection (DI), which is a form of Inversion of Control (IoC) is another example of the use of the Hollywood principle. Take for example a shopping cart class that requires a reference to a currency conversion service. Traditionally, the shopping cart class would be designed with a reference to the currency convesion service or use a factory to get a reference to the appropriate service implementation. By contrast, using DI, an external mechamism (e.g. Spring or Spring.net) automatically provides a reference to the required currency conversion service at the time the shopping cart class is instantiated.

Cloud computing involves both the architecture of an application (i.e. the way it is designed and the intent behind its design) and the platform on which the application is deployed. Cloud computing is a way to build, deploy and manage applications using Internet-based server infrastructure. It dovetails well with Service oriented Architecture (SoA) in that applications in a cloud are typically developed in a distributed manner with all the application pieces communicating over the Internet.

Cloud offerings differ from different vendors, but, for example, Amazon offers:

• Computing capacity - Elastic Compute Cloud or EC2 is a Linux hosting capability
• Structured data storage - SimpleDB is a web service-based capability for accessing structured data
• Large data storage - Simple Storage Service or S3 is a web service-based capability for storing and retrieving chunks of data
• Queuing service - Simple Queue Service or SQS is a hosted queue for storing messages to support asynchronous message processing

The cloud is promising to companies of all sizes, but is most powerful for small to mid-sized companies that do not have the money, staff or IT infrastructure to support an on-site enterprise data center. Getting a server to be visible on the Internet is easy. But building the technology infrastructure and staff to support a truly 24×7 data center environment with proper redundancy (both from a hardware, software and networking perspective), backup mechanism and physical & software security is not easy. Especially if this environment has to handle heavy peak loads.

The Benefits
Cloud computing offers many benefits:

• Ability to handle increased capacity and expand capacity and capability without any large upfront investment
• Ability to pay for infrastructure much like you pay for your utilities at home. You pay for what you use and you can configure your application to handle peak load without paying for a massive hardware infrastructure.
• Possibility of reducing IT operations staff

The cloud lowers the bar (from a cost and complexity perspective) to entry for mission-critical, enterprise infrastructure and provides easy access to additional capacity as needed. However, not every vendor’s solution is created equal. To get the most out of certain cloud offerings, it may require modifications or rewrites to existing applications.

The Risks
Probably the largest concern surrounding the adoption of cloud computing is lack of trust (by some) in the security surrounding their data on the cloud. The fear of their enterprise data being compromised is a large concern and a barrier to entry for some companies.

However, despite what some folks may believe, most of the large cloud vendors have much more security talent than the typical corporation. And it is absolutely critical for the survival of any cloud vendor to keep their environment as safe as possible.

The second risk is the fear of an outages at the cloud provider. Could this happen? It did happen earlier in 2008 when Amazon had a service outage and applications were not available. Due to these risks, some companies are planning to wait and see how reliable and safe these services are before jumping on board.

The Players
There are a few of big players (Microsoft recently announced their entrance into this market in 2009) and many small startups in the cloud computing space. Most organizations are selecting to work with the big players due to the potential risk involved in outsourcing their application and data to a small unknown vendor. But the smaller companies seem to be pushing the innovation and providing unique offerings.