Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Portability
Message
From
30/04/2004 06:22:51
Mike Yearwood
Toronto, Ontario, Canada
 
 
To
All
General information
Forum:
Visual FoxPro
Category:
Object Oriented Programming
Title:
Portability
Miscellaneous
Thread ID:
00899647
Message ID:
00899647
Views:
44
Hi all

In another thread we're discussing high cohesion and loose coupling. In that thread I described adding a chunk of code to a class. The chunk of code is to be used by methods of this class. However this chunk of code could also be used by other classes.

Adding the chunk of code makes it easier to share the class. This can be called portability. The dilemma is adding this chunk of code or keep it separate.

When I have a dilemma, I look at both extremes and try to decide between the two. For example, should I get a nose ring? The two extremes are no piercing/yes piercing. Another way to be extreme is no nose ring or a 10 inch long 1 inch think bar surgically piercing my neck. I think that suggests no piercing is better!

The extremes are I could have one class that needs this code or 100 classes that need this chunk of code. Each class is portable. However, my classes are now heavier. Changes can be made to this chunk of code in one method when one class exhibits a problem. The other classes now have the problem, but they are not exhibiting.

Question: Should portability ever outweigh high cohesion and loose coupling?

Changing one shared procedure affects all 100 classes, hopefully curing them all at once. Changing all 100 classes affects all 100, possibly taking huge amounts of time and possibly introducing new problems. I think the issue is to cure the entire patient as quickly as possible. Leaving known problems unresolved is like sweeping dust under the rug. Dealing with one symptom means the patient still has the disease!

Portability in the extreme implies all components are self-contained. BTW, that is not encapsulation, right?

Sharing a class means I'd have to provide its super-class. That is unavoidable. In order to make all components completly self-contained, I could have no super-classes. I could have no shared modules and I could have no decorator patterns or visitor patterns.

If portability in the extreme is wrong I think it should be avoided.
Next
Reply
Map
View

Click here to load this message in the networking platform