Page 2 of 2
Posted: Fri Dec 14, 2007 10:27 pm
by John Cartwright
aliasxneo wrote:Maugrim_The_Reaper wrote:One counter-argument. If everything depends on A_Main - can you reuse them in other applications where A_Main does not exist?
For me, this is the primary argument explaining why encapsulation is a superior method of aggregating objects compared to inheritance.
True, but to counter that I can re-use them in ANY system which uses my framework. I can literally cut and paste a module from one of my applications into another and have it work flawlessly, and this is exactly what I have done. I have a directory of modules like "members" which contains functionality for implementing a basic member system (authentication, login, etc.).
This is a benefit of working in a restrictive atmosphere such as a company where the software is proprietary. However, for opensource projects I would certainly never pick up your code unless it had some form of decoupling from the framework. The Zend Framework had a fantastic start of keeping the components decoupled, although as of now they have taken the easy path for some components and coupled them (controller+view for instance).
Another counter argument is what happens when you decide you want to switch frameworks. Bye bye precious framework specific modules.
Posted: Fri Dec 14, 2007 10:42 pm
by aliasxneo
Jcart wrote:aliasxneo wrote:Maugrim_The_Reaper wrote:One counter-argument. If everything depends on A_Main - can you reuse them in other applications where A_Main does not exist?
For me, this is the primary argument explaining why encapsulation is a superior method of aggregating objects compared to inheritance.
True, but to counter that I can re-use them in ANY system which uses my framework. I can literally cut and paste a module from one of my applications into another and have it work flawlessly, and this is exactly what I have done. I have a directory of modules like "members" which contains functionality for implementing a basic member system (authentication, login, etc.).
This is a benefit of working in a restrictive atmosphere such as a company where the software is proprietary. However, for opensource projects I would certainly never pick up your code unless it had some form of decoupling from the framework. The Zend Framework had a fantastic start of keeping the components decoupled, although as of now they have taken the easy path for some components and coupled them (controller+view for instance).
Another counter argument is what happens when you decide you want to switch frameworks. Bye bye precious framework specific modules.
Indeed, but to be honest there's hardly anything that would need to be changed. There wouldn't be much more change than the standard changes scripts go under when switching environments. Assuming the PEAR MDB2 module is being used there would hardly be any changes at all. The few references to the system module might need to be changed, but besides that most things stay the same.
My framework is still under constant construction though so as of right now nothing is final. I personally don't like the idea of keeping my framework decoupled, makes it feel like less of a framework too me. The whole idea of a framework is to help make coding easier via tools, and taking that environment away means losing those tools which can make for a lot of changes.