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!

I have found relatively old article about the design principle of design patterns dating around June 6, 2005. Though, the article is a bit old dated ( about 2.5 years), after reading it I have definitely learn something new and refreshing about design patterns and especially about the power and flexibility that can be gained from the use of interface.

The four page article in the form of interview with the design pattern guru Erich Gamma, famous for his landmark book Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995) and also a member of popular GoF (Gang of Four) is certainly worth to read if you are interested in design patterns and test driven development.

After reading it, I was able to summarize following points that seem quite interesting and important to me:

• Program to an interface, not an implementation.
• Integration between current refactoring tools and XP.
• Composition over inheritance for low coupling and design flexibility in the sense that sub-class always have to make assumptions about the context of the method it overrides (my favorite).
• Something can be public but that does not mean you have published it. Quote from Martin Fowler, but I’m still a bit confused about it and still researching. I have even posted a question in the stackoverflow but have been unable to get any response clarifying my confusion.
• Interface inheritance. I have seen this when I was going through Repository Pattern in NHibernate.
• Smaller objects configuring the container and customizing the behavior of the container.
• Consistency in API design (for example: using depravation support in JAVA, .NET). Seems easy but really hard to achieve especially for beginners like me

This is my first attempt to try to understand and implement patterns and practices. It is necessary to understand and implement these design patterns in order to make code flexible, re-usable, highly cohesive and less coupled.

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems. - Wikipedia

http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

As this is my first post regarding patterns and practices, I want to express something that I have learnt about Factory Method Pattern. It is a part of Gang-of-Four (GoF) design patterns.

The Factory Method pattern is a way of creating objects, but letting subclasses decide exactly which class to instantiate. Various subclasses might implement the interface; the Factory Method instantiates the appropriate subclass based on information supplied by the client or extracted from the current state. This pattern enables to make decision about which concrete class to be instantiatedin the run-time.

Lets go thru an example:

There is an interface called IPerson and two implemented class named Student and Programmer. The class called PersonFactory is created to make run-time decision about the selection of Student or Programmer thru a static method named GetWorkDone.

UML Diagram


PHP Code