!_I_Know_Kung_Fu_!
Originally posted by Andrew Shafer:
At what point do theoretical underpinnings detract from the task at hand?
/\ndy Hunt<br /> <a href="http://www.PragmaticProgrammer.com" target="_blank" rel="nofollow">www.PragmaticProgrammer.com</a>
Originally posted by Andrew Shafer:
At what point do theoretical underpinnings detract from the task at hand?
/\ndy Hunt<br /> <a href="http://www.PragmaticProgrammer.com" target="_blank" rel="nofollow">www.PragmaticProgrammer.com</a>
"Because following the Law of Demeter reduces the size of the response set in the calling class, it follows that classes designed in this way will also tend to have fewer errors."
--Pragmatic Programmer, pg. 141
"you must balance the pros and cons of your particular application... In fact, by reversing the Law of Demeter and tightly coupling several modules, you may realize an important performance gain. As long as it is well known and acceptable for those modules to be coupled, you design is fine."
Dave Thomas <br />Author of "<a href="http://www.amazon.com/exec/obidos/ASIN/020161622X/ref=ase_electricporkchop/002-7467239-7061602" target="_blank" rel="nofollow">The Pragmatic Programmer: From Journeyman to Master</a>
Dave Thomas <br />Author of "<a href="http://www.amazon.com/exec/obidos/ASIN/020161622X/ref=ase_electricporkchop/002-7467239-7061602" target="_blank" rel="nofollow">The Pragmatic Programmer: From Journeyman to Master</a>
Originally posted by Dave Thomas:
As I said, Demeter isn't really a law. But if you keep Demeter in the back of your mind as you code, you'll find yourself writing far tidier interfaces, and designing objects with far more delineated purposes. That that improves code clarity, reduces coupling, and greatly eases maintenance.
Dave
Originally posted by JUNILU LACAR:
So, I guess bottom line is (and we go back to the standard consultant's defense): "It depends." And I agree, you have to weigh the pros and cons and look at it in the context of your application.
Dave Thomas <br />Author of "<a href="http://www.amazon.com/exec/obidos/ASIN/020161622X/ref=ase_electricporkchop/002-7467239-7061602" target="_blank" rel="nofollow">The Pragmatic Programmer: From Journeyman to Master</a>
Originally posted by Dave Thomas:
You change the instance variable to a public function,
and guess what? Everyone's code that uses you class breaks.
Dave Thomas <br />Author of "<a href="http://www.amazon.com/exec/obidos/ASIN/020161622X/ref=ase_electricporkchop/002-7467239-7061602" target="_blank" rel="nofollow">The Pragmatic Programmer: From Journeyman to Master</a>
Originally posted by Dave Thomas:
Why do you need to get individual products out of the catalogue in the first place, and what do you plan to do with them over time?
Then there's your encapsulation question:
Also kindly let me know if we can say "low coupling leads to maintaining encapsulation" and "high coupling breaks encapsulation"
Dave Thomas <br />Author of "<a href="http://www.amazon.com/exec/obidos/ASIN/020161622X/ref=ase_electricporkchop/002-7467239-7061602" target="_blank" rel="nofollow">The Pragmatic Programmer: From Journeyman to Master</a>
Originally posted by Dave Thomas:
Designing your interfaces well will make them more decoupled.
Originally posted by Dave Thomas:
Using accessors for encapsulation as you describe will make your systems more flexible.
Originally posted by Desai Sandeep:
just give specific details to the Customer which Catlog exposes, not the Product object as a whole - Is that correct?
Am not very clear on this: How does getProducts() and getProduct(id) break encapsulation?
Dave Thomas <br />Author of "<a href="http://www.amazon.com/exec/obidos/ASIN/020161622X/ref=ase_electricporkchop/002-7467239-7061602" target="_blank" rel="nofollow">The Pragmatic Programmer: From Journeyman to Master</a>
Originally posted by Dave Thomas:
The original question has a third option: catalog.getproducts(). In light if the arguments above, I'm thinking that there are no circumstances in which this would be a good way to go.
But, this is all just me pontificating. Tell me what you think. What factors do you consider when making these kinds of decision? Have you experience of this kind of issue causing problems in real life systems?
Originally posted by Desai Sandeep:
Junilu, would be happy that I am leaning towards his answer B.I am equally happy that I am able to pin the answer down with some reasoning.I would be adding a last post to the Coupling Question to give a logical end to it.It will just contain a reference to this excellent post of yours.
From JavaWorld May 2001 - Encapsulation is not information hiding
[..] using append(Position) rather than setPosition(int,Position) further isolates design decision regarding the internal collection being used.
From JavaWorld May 2001 - Encapsulation is not information hiding
Information hiding rule 3 : Don't expose a class internal Structure
Clients should remain isolated from the design decisions driving the selection of internal class structure.For example, a client should not know whether a primitive array or an ArrayList is used to maintain an internal collection of objects.Internal structure is particularly apparent through the use of method names like getDataArray() or getTreeMap()
From JavaWorld May 2001 - Encapsulation is not information hiding
Information hiding rule 4 : Don't expose implementation details of the class
Don't allow clients to know or invisibly affect a class's implementation details.For example, a client should not be able to alter an internal calculation's result by changing the state of the objects used in that supposedly hidden calculation
Originally posted by Desai Sandeep:
If the method plays around with its own internal representation then encapsulation is maintained.On the other hand, if it delegates call to one of its helper classes (which may return a Product reference other than what the internal representation stores - Collection of Products!!), then encapsulation is broken.
After some pecan pie, you might want to cleanse your palatte with this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|