Application component dependencies

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

One thing I forgot to add...

I have said OOP is more than pragmatisms, it's way of solving problems...so the use of OOP will vary depending on what it is your implementing...

For example, a framework, will likely not yield much code reuse, as it is the framework...

Anyways, I have to get back to work I've been doggin' it for way to long :P

I'll be back later to argue my point once I clear my head a little... :)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

OK, this in interesting. d11wtq and Jcart, I think you are touching on a couple different subjects here.

One is about how and when to build objects/modules that are VERY independent so that they can be used framework to framework. Obviously the fewer dependencies necessary, the more independent. So for example, an emailing class ususally drops in fairly easily because all it depends on is mail(). But something that depends on a database connection is a little more dependent. Finally something that deals directly with the Request and Response would probably be very dependent on the specifics of a framework.

A second subject is about a differenet aspect of independence. I think d11wtq originally stated "Now... take a module out of the application. There's a pretty good chance it wont work..." But I think the important aspect is: What happens if you change the interface of an class/module, or the interface that an class/module depends on changes -- how hard is it to manage that change? Do you have to rewrite everything? What kinds of designs allow for changes better than others?
(#10850)
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Post by John Cartwright »

Aborint to the rescue :lol:

I'm going to touch back on this at a later time, I got exams to study for :(
User avatar
Buddha443556
Forum Regular
Posts: 873
Joined: Fri Mar 19, 2004 1:51 pm

Post by Buddha443556 »

arborint wrote:A second subject is about a differenet aspect of independence. I think d11wtq originally stated "Now... take a module out of the application. There's a pretty good chance it wont work..." But I think the important aspect is: What happens if you change the interface of an class/module, or the interface that an class/module depends on changes -- how hard is it to manage that change? Do you have to rewrite everything? What kinds of designs allow for changes better than others?
NASA Software Engineering Lab (Selby?) has done some cost studies that show if you have to modify more than 20% of a module's code then your better off coding it from scratch. Not much leeway with a 20% break even point. Same study also showed reuse is not free and not linear when it comes to modification.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Buddha443556 wrote:NASA Software Engineering Lab (Selby?) has done some cost studies that show if you have to modify more than 20% of a module's code then your better off coding it from scratch. Not much leeway with a 20% break even point. Same study also showed reuse is not free and not linear when it comes to modification.
Again, interesting, but it leads to even more questions.

Are there things a programmer can do when designing/coding a class/module could increase that threshold of 20% to something higher? I wonder what all the Refactoring guys would say about this? Or conversely, might it be better to lower the percentage to 5%-10% which might make the code more brittle with regards to large changes (since you have to rewrite anyway), but easier to fix for common cases because it is cleaner/clearer?

In that 20%, can you make it work harder for you so you get more out of it? I know Lastcraft sometimes talks about choosing when and when not to build in "flex points" which I always took to mean a part of the code that is purposely built to allow for more changablity.

Also, can you elaborate on "reuse is not free and not linear when it comes to modification." I can see that reuse is not free because it will force design decisions. But what does "not linear when it comes to modification" mean?
(#10850)
User avatar
Buddha443556
Forum Regular
Posts: 873
Joined: Fri Mar 19, 2004 1:51 pm

Post by Buddha443556 »

arborint wrote:Also, can you elaborate on "reuse is not free and not linear when it comes to modification." I can see that reuse is not free because it will force design decisions. But what does "not linear when it comes to modification" mean?
Basically, small changes to the code cost a lot. [Found a reference to the non-linear graph: http://citeseer.ist.psu.edu/cachedpage/258439/13 ] The two major costs are understanding the code in order to modify it and testing it to make sure you didn't break it.
arborint wrote:Are there things a programmer can do when designing/coding a class/module could increase that threshold of 20% to something higher? I wonder what all the Refactoring guys would say about this? Or conversely, might it be better to lower the percentage to 5%-10% which might make the code more brittle with regards to large changes (since you have to rewrite anyway), but easier to fix for common cases because it is cleaner/clearer?
arborint wrote:In that 20%, can you make it work harder for you so you get more out of it? I know Lastcraft sometimes talks about choosing when and when not to build in "flex points" which I always took to mean a part of the code that is purposely built to allow for more changablity.
For me, the trick is to design for reuse. I use the word "design" because it really should be planned. Reuse requires more thought and effort, there's an initial investment to be made in time and resources.

I pointed out the types of reuse before but might be a good link to post again: http://www.ambysoft.com/essays/typesOfReuse.html
We talk a lot about code reuse but different types of reuse can be used together and to some extent can even complement each other.
The Secrets to Reuse Success

So how do you actually achieve object-oriented reuse? I wish I could say that all you need to do is go out and buy a few tools and a repository to store your reusable work to get a good start. Unfortunately, reuse is about far more than tools. In fact, many organizations have failed miserably because of their focus on tools and not on process. Here are some reuse tips:

* You can't call something reusable unless it's been reused at least three times on three separate projects by three separate teams. You can attempt to design for reuse, but you can't claim success until some element of the application has been reused at least three times. Reusability is in the eye of the beholder, not in the eye of the creator.

* Reusable items must be well-documented and have one or more real-world examples of how to use them. In addition, the documentation should indicate when and when not to reuse an item so developers can understand the context in which it is to be used.

* The only way you'll make reuse a reality is if you plan for it. You must allocate the time and resources necessary to make your work reusable. If you don't step back and take the time to generalize your work, then it will never happen-project pressures will motivate you to put that work aside until you have the time to do it. The bottom line is that if reuse management-the act of specifically reusing existing items and constantly adding to the store of reusable items-isn't part of your development process, then reuse won't happen.

* Reuse is an attitude. When you begin a project, the first thing you should do is determine what portions of your application can be reused from somewhere else. Perhaps someone else has built what you need, or perhaps you can purchase components or other reusable items. The other side of the coin is that you must be willing to share your work with other people so they can reuse it. A good team lead will constantly be on the lookout for opportunities for reuse and will promote and reward reuse within his or her team. An excellent approach is to look for reuse during inspections: during model walkthroughs, look for opportunities for inheritance and pattern reuse; during code walkthroughs, look for component and code reuse.

- http://www.ddj.com/dept/architect/184415594
[The original study I referred to was, Richard W. Selby, Empirically Analyzing Software Reuse in a Production Environment, in Will Tracz, editor, Software Reuse: Emerging Technology, IEEE Computer Society Press, 1988. Kind of old but still in good standing AFAIK. Can't find a free link though.]
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Buddha443556 wrote:For me, the trick is to design for reuse. I use the word "design" because it really should be planned. Reuse requires more thought and effort, there's an initial investment to be made in time and resources.
I think for everyone -- that is the trick. ;) And obviously there are places where reuse is intentionally build in. For example, you could choose remove a seldom used feature because it removed a dependency. It seems like reuse in general comes down to the number and type of dependencies, and how well designed and flexible the interface is.

For dependencies, there is often not much you can do about them, but there are a number of patterns to manage their effects and add a "flex point." Perhaps we could list some of those patterns here and show examples of how they add flexiblity to a dependency?

Designing better interfaces is kind of a life-long study course. Does anyone have any links to articles or first-hand experience on interface design?
(#10850)
Post Reply