Re^7: Re-blessing || Re-constructing objects

The key concept you're not grasping is the fact that change is something that needs to be compartmentalized because it is the only safe way to build a large system. That system could be a piece of code or a bridge. You have to isolate change or that change will percolate throughout the entire system willy-nilly. In the case of a bridge, the bridge falls down. In the case of a piece of code, this means that every bugfix and/or enhancement might change the behavior of any part of the system, especially those which weren't touched.

What does this mean? Well, under your proposed system, it means that by fixing a bug in how User::Superman behaves, you might have changed the behavior of User::Anonymous. I'm pretty sure you would agree that this is undesirable.

The solution is to isolate the part that changes. Every user needs a set of authorizations, but that set (as a whole!) will change. So, isolate (or encapsulate) the bit that changes.

It is a tiny bit more upfront work. Yet, you will discover that you have more capabilities to the system than if you gone with your system. It's a bit of a leap of faith, but I hope you will trust me and be willing to make it, for your sake.

My criteria for good software:

Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Comment on Re^7: Re-blessing \|\| Re-constructing objects

Replies are listed 'Best First'.
Re^8: Re-blessing \|\| Re-constructing objects by blogical (Pilgrim) on Apr 18, 2006 at 14:28 UTC
This does seem to be sound advice, and I appreciate everyone for pointing it out. I think the key is recognizing what level of compartmentalization is appropriate for a particular situation. Public object methods are a widely recognized contract that, without warning well in advance, the effects of calling a method will not change. The safety of compartmentalizing comes from that contract alone, not the form of the compartment. If I take any space and give it the same contract, it becomes a compartment of just such strength. By doing so you make available compartments of different shapes and sizes, from a simple scalar to the most complicated data structure. The line of delineation is no longer what one might expect- until they read the documentation that details it. It is the compartmentalization, not how you effect the compartmentalization, that makes it useful. Does it make sense to re-use common, publicly acknowledged contracts to do so? Yes (see Creative Commons). Is it wise to follow that as a guideline unless you have good reason to do otherwise? Sure. But might there be uses that don't follow the guidelines? I believe so. Hence, this entire thread. "One is enough. If you are acquainted with the principle, what do you care for the myriad instances and applications?" - Henry David Thoreau, Walden	[reply]
Re^9: Re-blessing \|\| Re-constructing objects by dragonchild (Archbishop) on Apr 18, 2006 at 15:19 UTC
Yes, there are times when the common wisdom should not be followed. However, one must understand the common wisdom first before knowing when it doesn't apply. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]