Yeah again I am quoting some interesting text from Clean Code

It’s about four simple rules by Kent Beck on simple design:

• Runs all the tests
• Contains no duplications
• Expresses the intent of the programmers
• Minimizes the number of classes and methods

I agree with al the three rules but the fourth one seems little difficult to follow especially if you are also following the Single Responsibility Principle. But since its is listed in the last, I assume it should be given less priority. What do you think?

I know we have have hearing, learning and reading so many things about OO and procedural code from the day we are onto the world of OO. But I just figured out one nice point differentiating between them found in the book Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin aka Uncle Bob.

Procedural code (code using data structures) makes it easy to add new features without changing the existing data structures. OO code, on the other hand, makes it easy to add new classes without changing existing features.

I think above single statement is more than enough if one wants to know the real difference between OO and procedural code. And again you gotta to have some OO experience in order to understand the depth of the statement.

So far, I have been satisfied with the book (completed around 10 chapters) and if you are interested in making your code clean (in the sense of usability and design), then I strongly recommend the book.

Rules are mostly made to be broken and are too often for the lazy to hide behind. – Douglas MacArthur

For the past few weeks, there has been tsunami of debates going on about the principles and rules being followed in the programming world. First initiated by the stackoverflow.com podcast and again triggered by recent CodingHorror post.

Its true that more the rules, more the complexities and constraints. If we just go through the time line of software industry, we can get more and more rules / principles / best practices recommendations as more mature the industry has become or is becoming. The rules and principles of object oriented development that have become popular since early 1990′s or so are the foundation of current software industry trends. But just imagine the beautiful yet complicated world of software development without these doctrines?

Jeff and Joel have been especially critical of Unit Testing and Uncle Bob’s SOLID principles. It is true that there has always been debate among the experts about the magnitude of unit testing your code. While some people may unit test only core components while other may test each and every aspect of their code. Whatever approach people follow, both will be productive and /or counter-productive to some extend. But if we compare the scale of effect between productivity and waste of resources as a result of unit testing, there will be and there has always been in most cases where people have achieved earlier aftermath rather than latter one. I just want to say that yes you can ignore unit test completely and even after that write kickass code but criticizing the concept of unit testing seems to be act of being ignorant especially when you are such a senior programmer. I am also new to unit testing and sometime feel why the fuck I’m writing dual code (original code and unit testing it). But being a rational programmer I will and always follow the industry standard principles and guidelines and I am feeling that my abilty to write clean + resuable code is improving day-by-day.

Jeff and Joel have been especially critical of Unit Testing and Uncle Bob’s SOLID principles. It is true that there has always been debate among the experts about the magnitude of unit testing your code. While some people may unit test only core components while other may test each and every aspect of their code. Whatever approach people follow, both will be productive and /or counter-productive to some extend. But if we compare the scale of effect between productivity and waste of resources as a result of unit testing, there will be and there has always been in most cases where people have achieved earlier aftermath rather than latter one. I just want to say that yes you can ignore unit test completely and even after that write kickass code but criticizing the concept of unit testing seems to be act of being ignorant especially when you are such a senior programmer. I am also new to unit testing and sometime feel why the fuck I’m writing dual code (original code and unit testing it). But being a rational programmer I will and always follow the industry standard principles and guidelines and I am feeling that my abilty to write clean + resuable code is improving day-by-day.
And going to the next topic, I feel criticizing SOLID seems kinda act of irresponsibility. In the world of object computing, SOLID defines the contextual boundary that I take as parameters for making self judgment of my code and measuring myself. For people not familiar with SOLID here is a short intro or you can just google.

• Single Responsibility Principle: A class should have one, and only one, reason to change.
• Open Closed Principle: You should be able to extend a classes behavior, without modifying it.
• Liskov Substitution Principle: Derived classes must be substitutable for their base classes.
• Dependency Inversion Principle: Depend on abstractions, not on concretions.
• Interface Segregation Principle: Make fine grained interfaces that are client specific.

• Release Reuse Equivalency Principle: The granule of reuse is the granule of release.
• Common Closure Principle: Classes that change together are packaged together.
• Common Reuse Principle: Classes that are used together are packaged together.

More information about SOLID can be found here.

Okay for now just forget about Jeff’s post but just look at those comments. After reading some of them I feel the state of dismay at the current state of software industry and came to know there are some people in the world who says GoF Design Patterns is a crap and some just don’t need any rule (kinda cowboy coder).

And the list goes on…

Conclusion

Being a beginner in software world, I may not be appropriate person who could criticize experienced and techies like Jeff and Joel. But sorry guys I don’t give a fuck! I will express my frustration if I’m not satisfied with others’ thought. It’s my right And I also don’t claim that I can follow each and every rules and best practices but still I am trying and will try to write code following them. I want to take programming as the art of craftmanship rather than cowboy work. In my opinion, there are programmers who code to get paid and there are some who code not only to get paid but also as a chance to learn and improve continuously. So, what type of programmer are you?

Yes you can write kickass code by not following any rules or just by creating your own rule but the question is how are you going to compare the quality of your code without these principles and rules?

Readers what do you think?

The title of this post has been taken from this tweet.

Few days ago, I read a post (the post is a bit old) about the the design concept of fat model, skinny controller. After going through that post and this one, for few days I have been thinking and trying to analyze the implementation impact of the concept. I guess I have been petty much impressed after doing some research on the web and going through blogs of experts in this subject.

It won’t be wrong if MVC is called the de-facto pattern of developing web applications. But still, the implementation mechanism of MVC and understanding the overall logic of MVC can be different from developer to developer.
MVC, being mostly implemented in the presentation layer provide powerful mechanism to developers to reuse code (reusing could have been easy if there were only one language or platform to deal with but while developing web applications developers need to deal with many languages and technologies that may or may not integrate well with each other) and significantly apply the concept of object oriented principles and agile methodologies.
Most of the developers and their code I have encountered especially in the PHP seem to embrace the idea of putting business logic in the controller rather than in the model. They regard model as the way only to deal with CRUD operations. It is true that MVC frameworks like Cake and Symphony provide quite powerful ORM capabilities without the need of writing a single SQL query embedding the principles popularized by Rails i.e. convention over configuration, DRY and YAGNI.
But in my opinion, models should not be treated as the the component for dealing with CRUD operations. Model should be responsible for more than that. It’s also true that applying business logic only through models is almost kinda impossible. It’s something like coupling which needs to be reduced but can’t be eliminated completely.
I view controllers as a tunnel that should be responsible for accepting input from the view and passing to the model and accepting raw output from the model and passing it to the view. Making the controller petty fat could make the code difficult to re-use. In reality all these things are easier to say but making the best use of the MVC by making model responsible for most of the business logic and let controllers and views perform their native task can be quite difficult because of the complex nature of the web. Complexity in the sense that there are other languages and technologies as well in the same layer that needs to be integrated and be dealt with. For eg; Server side Flash / SilverLight components, JavaScripts and so on.
So I have been trying for few days to apply the concept of fat model and skinny controller and as expected facing some difficulties especially to make my model more responsible and controller more light or in other word more skinny. Since I was involved in that project from middle so, attaching the business logic only to the model seems quite impossible. So, I am looking forward to do some small project in MVC applying the concept of Fat Model and Skinny Controller.
Until then, I can not claim that this concept must be followed though I still believe this concept should be followed to write re-usable and loosely coupled code.
As usual it would be great if you provide comments and criticisms and I can also know if I am wrong or right.

In my previous post, I had posted a link about the interview with the design patterns guru Erich Gamma. After reading that article, I came to know about the concept of public and published method in a component, class or interface.

“Something can be public but that does not mean you have published it.” – Martin Fowler

For past few days, I have been trying to justify this statement. In the process, I did google the term, but I was unable to find any interesting post until I found the white paper written by Martin Fowler himself (I am damn lucky ). The white paper and two answers I got in the stackoverflow about my question regarding public and published concept has helped me a lot to understand and difference between these almost identical terms.

The scenario of public and published arises especially in the distributed environment when one has to publish his/her code in the form of API to other developers. Once the method or interface or class is published, changing it later will certainly break other’s code.

In JAVA and .NET, with release of new version number of methods, class or interface are treated as deprecated. Changing the behavior of those legacy modules means breaking the code being dependent on them. So, attributes like deprecated are used to inform the clients or service caller to updated their code. APIs are not defined by their source rather by contracts usually in the form of documentation or with the use of refactoring tools and sometimes with the help of reverse engineering with the use of Reflection (System.Reflection in .NET)

Here are the list of advices given by Fowler on publishing interfaces:

• Don’t treat interfaces as published unless they are
• Don’t publish interfaces inside a team (this one related to code ownership)
• Publish as little as you can as late as you can
• Try to make your changes additions

My Implementation

Lets suppose, Boeing‘s Dreamliner uses engine made by Rolls Royce (in reality it does use). For efficient use, there must be a contract between Boeing which call and invoke APIs and services and Rolls Royce which is responsible for designing the contract.

In this scenario, Rolls Royce’s services invoked by Boeing should be according to the contract and the interfaces provided within that contract are all published.

If the contract provides only one interface i.e. IRollsRoyceEngine as published and while other interface as public but not published then, Rolls Royce should be responsible for the change in the IRollsRoyceEngine interface only not IRollsRoyceEngineAnalyzer.

Boeing can of course use IRollsRoyceEngineAnalyzer but Roll Royce is not bind to inform the change in the interface if it happen in the future.

Conclusion

Differentiating published and public interface while designing the contract and API can be encouraging thing to do in the context that change will happen and it is inevitable and it’s just the matter of time. Updating an interface should not break the legacy interface.

Hmm…quite easy to say but certainly not so easy to implement in real projects. Now I am really eager to implement the concept of published and public interfaces and see what it is truly worth of!