{ Make this readable }

Sunday, December 12, 2010

What they did not teach in OOP/OOAD class

For over a decade the Gang Of Four Design Patterns or the GoF patterns are they are fondly referred to have become one of the favorite topics in job interviews. And for good reason. It has even led to the rise in the popularity and acceptance of spin offs like - J2EE Blueprints, Enterprise Integration Patterns and even Anti-patterns.

Would it be too much to ask for to teach these concepts in school today in the final semester before sending graduates off into the real world?

However, knowledge of the GoF patterns is not sufficient to build elegant systems. In fact it must be said that an over-reliance and blind following of the GoF patterns quite often leads to bloated and over-engineered systems. Case in point - Spring superseded a bloated J2EE. Google Guice and JEE CDI are in turn attempts to improve upon Spring which itself has gained a lot of weight over the years.

In my experience, I have come to realize that in order to insure a more complete and proper understanding of the art of design and its application in a complex software system, there are 2 other essential sets of design patterns. The lesser known and under used ones:
    1) GRASP - General Responsibility Assignment Software Patterns
    2) SOLID - Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion

Where the GoF patterns and their spin offs explain "how" to build the components; SOLID and GRASP help in understanding "why" those components, packages, abstractions, interfaces and dependencies have to be built and assembled in a certain way.

To drive home the point, just sending off graduates with partial knowledge i.e GoF = "How" and without SOLID + GRASP = "Why" would be like teaching automobile engineers how to machine parts of a car and not teaching them how to assemble the parts to make a drivable car.

If students are expected to figure out the "why" on their own at their first jobs, they will unwittingly build and design Rube Goldberg type of software, inflicting the source code with factories of factories, bad adapters that don't do anything, redundant interfaces, singletons that resist unit testing and the list goes on.... until they learn from experience (if at all). For it takes years of experience and guidance to gain a holistic view of complex systems. Systems thinking also helps a great deal.

While we are discussing the subject of good design there is another important aspect that is even less understood - API design. There is a remedy for that too. Joshua Bloch's - How to Design a Good API and Why it Matters.

In conclusion, I'd like to list down some famous quotations and rules of thumb that help me when I'm designing a particularly tricky system:
   - Simple things should be simple, complex things should be possible (Alan Kay)
   - Simplicity before generality, use before reuse (97 Things ..)
   - Ask yourself if a feature or its design is necessary and sufficient. Anything more is a waste. Anything less means the job is not complete

Until next time!

8 comments:

Ravi Maganti said...

The blog is succinct yet highly informative. Look forward to see more...

Uma Bharath (nee Jagannath) said...

Nice post! Inisghtful and precise. Would love to see more from you on this!

workmad3 said...

I'd call GRASP and SOLID the principles behind patterns personally, as they are really a bit too high-level to fit into the idea of a pattern.

Otherwise, I agree fully... that said, I did come out of university with a course on patterns and GRASP under my belt :) (no SOLID though)

Ashwin Jayaprakash said...

Dieter Rams: ten principles for good design

Ashwin Jayaprakash said...

Principles of User Interface Design

Ashwin Jayaprakash said...

Why shouldn't this apply to design? -
Kurt Vonnegut’s 8 Tips on How to Write a Great Story

Ashwin Jayaprakash said...

"Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defense against complexity."

— David Gelernter, Machine Beauty: Elegance and the Heart of Technology

Ashwin Jayaprakash said...

Some more about YAGNI, LSP, OCP
http://programmers.stackexchange.com/a/162657/98216