The ‘is a’ relationship is expressed with inheritance and ‘has a’ relationship is expressed with composition. Composition simply means using instance variables that refer to other objects.
Which one to favor, composition or inheritance? The guide is that inheritance should be only used when subclass ‘is a’ superclass.
> Don’t use inheritance just to get code reuse. If there is no ‘is a’ relationship then use composition for code reuse. Overuse of implementation inheritance (uses the “extends” key word) can break all the subclasses, if the superclass is modified.
> Do not use inheritance just to get polymorphism. If there is no ‘is a’ relationship and all you want is polymorphism then use interface inheritance with composition, which gives you code reuse.
Saturday, April 2, 2011
Saturday, August 14, 2010
What is a framework?
Last week a friend of mine who is attending a course on web application asked me what is a fremwork? Here is what I tried to explain him:
A framework is a generic architecture which build an infrastructure to develop applications in an specific technology. In simple words it is a set of basic classes and interfaces which build the infrastructure of an application.
Based on this definition it’s easy to think that using a framework is like using an API, when there is a big difference between these two. An API, e.g. Java, the classes are used by developer to do specified functionality: in this case our code call the existing code to do some function but the control of the application flow is by our code.
But using a framework means following an specific architecture; to be more precise extending the framework classes a/o implementing it’s interfaces. In this case the components of the framework have the control of the application flow.
A framework does several things:
• it makes it easier to work with complex technologies
• it ties together a bunch of discrete objects/components into something more useful
• it forces the team (or just me) to implement code in a way that promotes consistent coding, fewer bugs, and more flexible applications
• everyone can easily test and debug the code, even code that they didn't write
Maybe the best defintion is from the authors of Design Patterns:
"When you use a toolkit, you write the main body of the application and call the code you want to reuse. When you use a framework, you reuse the main body and write the code it calls."
"Not only can you build applications faster as a result, but the applications have similar structures. They are easier to maintain, and they seem more consistent o their users. On the other hand, you lose some creative freedom, since many design decisions have been made for you."
"If applications are hard to design, and toolkits are harder, then frameworks are hardest of all. ...Any substantive change to the framework's design would reduce its benefits considerably, since the framework's main contribution to an application is the architecture it defines. Therefore it's imperative to design the framework to be as flexible and extensible as possible."
In conclusion a framework is considered as part of an exisiting software where inserting your code; based on the rule "don't call us we call you". The framework classes will call your application code.
A framework is a generic architecture which build an infrastructure to develop applications in an specific technology. In simple words it is a set of basic classes and interfaces which build the infrastructure of an application.
Based on this definition it’s easy to think that using a framework is like using an API, when there is a big difference between these two. An API, e.g. Java, the classes are used by developer to do specified functionality: in this case our code call the existing code to do some function but the control of the application flow is by our code.
But using a framework means following an specific architecture; to be more precise extending the framework classes a/o implementing it’s interfaces. In this case the components of the framework have the control of the application flow.
A framework does several things:
• it makes it easier to work with complex technologies
• it ties together a bunch of discrete objects/components into something more useful
• it forces the team (or just me) to implement code in a way that promotes consistent coding, fewer bugs, and more flexible applications
• everyone can easily test and debug the code, even code that they didn't write
Maybe the best defintion is from the authors of Design Patterns:
"When you use a toolkit, you write the main body of the application and call the code you want to reuse. When you use a framework, you reuse the main body and write the code it calls."
"Not only can you build applications faster as a result, but the applications have similar structures. They are easier to maintain, and they seem more consistent o their users. On the other hand, you lose some creative freedom, since many design decisions have been made for you."
"If applications are hard to design, and toolkits are harder, then frameworks are hardest of all. ...Any substantive change to the framework's design would reduce its benefits considerably, since the framework's main contribution to an application is the architecture it defines. Therefore it's imperative to design the framework to be as flexible and extensible as possible."
In conclusion a framework is considered as part of an exisiting software where inserting your code; based on the rule "don't call us we call you". The framework classes will call your application code.
Subscribe to:
Comments (Atom)