Bagonca

Recently we here in Bangalore were discussing different ways of doing things to make our software and work environment better. We were all convinced that one way to make our code better was for us all to help each other out to make our own work environment more fun to work. This was just one thing we all were convinced about anyway! Something to celebrate, Hurray!! :-) Of course, there were many different opinions about what it means to make it “better”.

At first sight we thought that it was our work processes that can make a difference in the way we write and perceive our code. Though, this influence can never be ignored, we believe that for a rapid growth company like ours, we programmers and developers also need to improve the way we think about code. We of course should be proud of what we have accomplished so far, but we got to remember as Olle would say, “it’s a marathon we are running for God’s sake!”. We need constant energy and effort to get it across the finish line.

We thought that for us and our code to look better, we got to think better. We got to be code designers and not monkey like application programmer. We need to get constant inspiration and fuel from other code writers and designers out there. We believe that the wheel has been already invented, i.e., someone else in the world would have already solved our problem at hand earlier and probably has a better solution! We just need to google for the right idea and steal it.
Steve jobs once remarked “Good artists copy and great ones steal!”

We steal better designs to be better designers!

So with the initiative from Jayesh we bought this book called “Design patterns: Elements of Resuable Object-Oriented Software” written by a geni called Erich Gamma (and 4 others).  Ganesh started reading it first and gave us a nice 25 minute presentation this Monday morning when our internet line got down. We thought that it was a good start and wanted to continue evangelising our thoughts around code design.

We are thinking of doing a 3 blog series of “From Monkey to Man” depending on the popularity of this article. So please do give us feedbacks and counter arguments to encourage us write more on our reflections on Erich Gamma’s book.

Okay, thats enough of background info. Lets now jump start into what Erich sees in patterns…

Designing object-oriented software is hard, and even harder is designing reusable object oriented software.

How many times have you had the dejavu – that felling that you have solved a problem before but not knowing where or how? If you could remember the details of the previous problem and how you solved it, then you could reuse the experience instead of re-inventing the wheel again? The purpose of Erich Gammas book is to record that experience as “design patterns”

Gamma goes, design patterns capture solutions that have developed and evolved over time. Hence they are not the designs people tend to generate initially. They reflect untold re-design and re-coding as developers have struggled for greater re-use and flexibility in their software. Design patterns capture these solutions in a succinct and easily applied form.

Good object oriented designers will tell you that a re-usable and flexible design is difficult if not impossible to get it “right” the first time. Before a design is finished, they usually try it themselves, reuse it several times, modify it each time and then finally, you have a design that is “good enough” One thing great designers know NOT to do is to solve every problem from the scratch or from the first principle. Rather they want to re-use solutions that have worked for them and others in the past. When they find a solution to be “good enough” they use it again and again. Such experience & thinking is what makes them part of the greats.

Design patterns are NOT about designs such as a dictionary or a tuple or linked lists or queues that can be encoded in classes and reused as it is. Nor, are they complex, domain-specific designs for an entire application. They are descriptions of communicating objects and classes that are customized to solve a general or generic design problem in a particular context.

For instance, take the example of database connectivity, people have solved this in many ways and we do have our own standard. But do we really follow through the standards in all the places? Nope…the basics are that we need to connect to the DB once and only once per request and that it should be void of injection vulnerabilities. Why don’t we use singleton design pattern for this problem and the pattern will itself make sure to create only one connection even though your code attempts again and again?

The design patterns require neither unusual language features nor amazing programming skills or tricks. It can be implemented in Python although it might take a little more work than an ad hoc solution. But the extra effort invariably pays dividends in increased flexibility and re-usability. So, the question if is should we write the operation and function files in a procedural way? Nä, this is monkey work!

If we start designing our code with the back-drop of patterns in mind then we create more robust, re-usable and testable code.

Below are the arguments from Erich to use design patterns:

1. Patterns make it easier to reuse successful designs and architectures.
2. Expressing proven techniques as design patterns makes the codebase more accessible to new developers.
3. Reduces the need for documentation
4. Easier to maintain the system
5. Put simply, design patters help a designer get a design “right ”faster and thus helps him/her reach the customer faster

I will stop here for now. In my next blog, I will talk about the details involved in design patterns…Erich has a solution for the three tier architecture (Model/View/Controller)!

Stealing is NOT bad afterall, it is clever! ;-)