views:

85

answers:

1

I have been playing around with the concept of 'module' that some mvc frameworks implement and it seems like a good solution, and also with TDD, but I think there must be something more, like a design pattern I missed (I only know a few), that will let me build applications that can grow (in code) with no limits.

Any thoughts?

edit : Another good thing about modules is that they can be built in a way that they are application-independent, so they can be reused.

+3  A: 

In "Facts and Fallacies of Software Engineering," Robert L. Glass says:

Fact 15. Reuse-in-the-small is a well-solved problem.

Fact 16. Reuse-in-the-large remains a mostly unsolved problem.

Fact 17. Reuse-in-the-large works best in families of related systems.

In other words, you can reuse modules, but only between applications that work very similarly. Trying to make modules so versatile that you can resuse them in any application is too hard. You end up making modules that are so configurable that they're overly complex to use, and contain lots of code to handle scenarios that are of no use to a given application.

You'd be better off coding a custom module for each application, that does just what that each application needs, and no more. This is especially important for a language like PHP, where code is loaded on each request, so the volume of code has a significant impact on performance.

Reusing more fine-grained functionality is different. The uses of say, logging, is reasonably similar between applications no matter how different the applications are from one another. This is why most frameworks do really well with general-purpose service-style classes.


Re comment from @A_Var:

You can make a class reusable if you know the range of possible functionality in advance, and therefore the parts that need to be extensible. This is relatively easy for a simple class that's used similarly in every app. I mentioned the example of logging. This is what Glass refers to as reuse-in-the-small.

But we're not talking about simple classes. If you try to do the same thing with a complex module (think of multiple classes to handle multiple screens, forms, different database schema, etc.), it's too hard to write the code to be generic enough to cover all the specific needs for each application. You end up needing more code in the generic module than the sum total code you'd need to write separate modules for each app.

Also, testing becomes very costly, because any change you make to the base module requires that you re-test all the apps that use and extend it.

In the end, it's less work to write a new module for each app, and you can gain what efficiency you can by employing reusable components that are more fine-grained.

Bill Karwin
Thanks for your answer. I'll write down that title, sounds interesting
HappyDeveloper
@Bill Isn't it that we have abstract classes concept in OOP to address the issue of modularity here?. We use abstract class and implement more generic methods and leave out the implementation of the rest of methods for the classes that are derived from abstract class. In this way we can have appropriate module behavior.
A_Var