Toolkit: A set of related and reusable classes designed to provide useful, general-purpose functionality. Ex: Collections, IO Library, etc

Framework: A set of cooperating classes that make up a reusable design for specific types of software. Ex: JUnit, Spring, etc

Accordingly to GoF Design Patterns book:

• Creating a class by specifying a class explicitly : If need be use creational patterns instead
• Dependence on specific methods : If need be use Chain of Responsibility or Command pattern instead
• Dependence on Hardware and/or software platforms : Consider using Abstract Factory or Bridge pattern instead
• Dependence on Object Representation or Implementation : Must program to interface and not to implementation. Abstract Factory, Bridge, Memento, Proxy etc patterns can help.
• Dependence on specific Algorithms : Consider using Strategy or Visitor pattern
• Extending functionality by subclassing : Prefer composition over inheritance
• Inability to alter classes conveniently : esp. with third party libraries. Adapter, Decorator and Visitor can help.

What’s surprising is that decades ago people knew about these problems, but still pretty much every system has these problems. What are they doing that these anti-patterns are so sustainable? 

• Inheritance (White-box reuse)
• Composition (Black-box reuse)
• Parameterized Types or Generics

While inheritance makes is easy for extending/reusing behavior, sure has some serious flows which makes it the last choice for reuse.

• Class inheritance is defined statically at compile time. This means you cannot change the implementations inherited from the parent at run-time.
• Inheritance also breaks encapsulation since the subclass is exposed to the details of the parent’s class.
• There is tight coupling between super class’ implementation and subclass’ implementation. Any changes in the parent, forces the child class to also change.

Some of these drawbacks can be avoided by implementing an interface over extending a class.

Usually we want to favor object composition over class inheritance. Object composition overcomes all these problems by talking to composed class via their public interface. Favoring composition also helps in keeping each class encapsulated and focused on one task thus encouraging Single Responsibility principle.

Parameterized types or Generics is also another interesting way to reuse behavior/code. For example, to declare a list of String objects, you supply the String type as a parameter. The language implementation will create a customized version of the List class template for each type of element.

• Clients remained decoupled and unaware of specific class they are using, as far as the underlying class adheres to the defined interface. 
• The client does not need to know with which concrete class its interacting.
• Depending on the context, different implementation classes can be polymorphically provided without having to change client code. Makes it easy for the system to evolve.
• During development even though the concrete class is not available, the client class can be developed. Helps parallelize work.

• From the problem statement, single out all the nouns and verbs - end up with a lot of useless objects which lack clear responsibility. Also can argue for ever whether a method belongs on this object or another (Ex: Should Doctor class have a giveShot method or should Patient class have a takeShot method)
• Focus on collaborations and responsibility - can get overwhelming when you look at a large system. Without tests, they can be very confusing to a 3rd person. Without design metaphors and design patterns one cannot easily understand these systems.
• Try to model the real world - Strict modeling of the real world leads to systems as complicated as real world. Also they seem to be rigid, because they only reflect today’s realities, but not necessarily tomorrows.
• Test Driven Design with Spiking - If the developer does not understand basic design principles and OO concepts, this can lead to big ball of mud. Spiking helps in flushing out the overall approach, while Unit and Acceptance Tests really help in validating the design and creating safety net around the code for easy refactoring. 
• Prototyping followed by Design elaboration phase - one or more quick prototypes helps understand and learn about the system. Based on this learning, developers can choose any of the above design approaches. Big trouble when the prototype is not thrown away and is converted into production code.
• Cow boy coding : Design what? Just type it in notepad and pray it will all work. 

Clearly there is no one best way to do things. My present favorite is Prototyping followed by TDD with a slant on collaborations and responsibility.

Short: They help us solve recurring design problems. Note that : design patterns don’t solve the problem themselves, they help us solve the problem.

Detailed answers:

• Communication, Learning and Enhanced Insight: Over the last decade design patterns have become part of every developer’s vocabulary. This really helps in communication. One can easy tell another developer on the team, “I’ve used Command pattern here” and the other developer understands not just the design, but can also easily figure out the rationale behind it. Design Patterns really help in learning, esp. when you are new on a project. Also this helps in providing developers with better insight about parts of the application or 3rd party frameworks they use.
• Decomposing System into Objects : The hard part about OO Design is finding the appropriate objects and decomposing a system. One has to think about encapsulation, granularity, dependencies, flexibility, performance, evolution, reusability and so on. They all influence decomposition, often in conflicting ways. Design Patterns really helps identify less obvious abstractions. These objects are seldom found during analysis or even the early design, they’re discovered later in the course of making a design more flexible and reusable.
• Determining Object Granularity: One thing I struggle a lot with is finding the right level of abstraction and granularity. Design patterns helps in coming up with objects with different levels of granularity that makes sense. 
• Specifying Object Interface : Identifying the right interface and the relationship between various interface is not a one-shot activity. Usually it takes several iterations to identify the right composition of interfaces. Forget interfaces, most of the times, coming up with a method signature can also be quite tricky. Design Patterns really helps in this area.
• Specifying Object Implementation : How should we implement an Object? Given an interface there could be multiple concrete classes of that type, each one can have very different implementations. Design Patterns provide guidance like Program to an interface (type) not an implementation (concrete class) which can result in really good OO code.
• Ensuring right reuse mechanism : When to use Inheritance, when to use Composition, when to use Parameterized Types? Is delegation the right design decision in this context? There are various questions that comes to a programmer’s mind when they are trying to design highly reusable and maintainable code. Knowledge of design patterns can really come handy when making such decisions.
• Relating run-time and compile time structures : An object oriented program’s run-time structure often bares little resembles to this code structure. Sometimes looking at the code does not give us the insights into run-time structure. Knowledge of design patterns can make some of the hidden structure obvious.
• Designing for change : We all know that lack of continuous refactoring and design that doesn’t take change into account risks major redesign in the future. Over the years we’ve also learnt that big upfront designs can’t standup against the constant change/additon of software requirements. We’ve leant grouping elements with similar change life cycle together yields in far more flexible and extendable design. If we think some behavior or element of behavior is most likely to change, we try to abstract that behavior in one place. While we understand these concepts are important design patterns really make it possible to design such systems. Each design pattern lets some aspect of the system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change.

After hearing enough praises about Haskell from folks for the last 2 years, I have decided to give it a shot. I downloaded and installed Glasgow Haskell Compiler (GHC) version 6.8.3 on my Mac. Next I installed EclipseFP 0.10 which gives a Haskell Perspective for Eclipse. Finally I downloaded HUnit 1.0

After installing all of these (which was very smooth), I have a HelloWorld program build Test Driven. Sweet!

Haskell here I come

Returns a string representation of the object. In general, the toString method returns a string that “textually represents” this object. The result should be a concise but informative representation that is easy for a person to read. It is recommended that all subclasses override this method.

I just spend the last 3 hours pairing with Michael Feathers, who is on this way to the airport. Michael spent the last 2 weeks in India. During this stay in India he presented a tutorial on Working Effectively with Legacy Code in Delhi, Bangalore and Mumbai. He presented some simple yet powerful techniques of dealing with various issues in Legacy OO code. 

Mr. Feathers is in India for 2 weeks. He is doing a TDD training for a company in Bangalore.

Flashback: I was really happy when he dropped me an email saying he is coming to India and would like to meet up with Agile enthusiasts in the area. After exchanging a few emails, we settled on running 3 free workshops in Delhi, Bangalore and Mumbai. Yes, that’s right, its your opportunity to meet him in person and spend 3 hrs talking about Working Effectively with Legacy Code.

As usual we are using the Position Paper’s concept to filter in the really interested folks. Over a period of time, the quality of the position papers are improving. Also position papers helps in setting expectations on both sides, the presenter and the participants. The present can adapt their workshop based on the position papers and the participants can gauge what the workshop will feel like based on other people’s position paper. 

I really looking forward to pair with him on my Avatars of TDD experiment.