David Roberts - SCJP2,MCP
David Roberts - SCJP2,MCP
Considering the objects returned
David Roberts - SCJP2,MCP
As always, Expert should be the first pattern considered unless it is a controller or creation problem
[...]Coupling is probably not increased because the created class is likely already visible to the creator class,due to the existing associations that motivated its choice as creator.
David Roberts - SCJP2,MCP
Packaging (and thus protected nature of setter methods!!) should not be problem, because high related responsibilities are usually put in the same package.Hence it would be reasonable to assume Catalog and Product in the same package.
c) Design #1 breaks the encapsulation of the Catalog, adding brittle coupling. Design #2 maintains the encapsulation of the Catalog, making future design changes easier
David Roberts - SCJP2,MCP
David Roberts - SCJP2,MCP
Design #2 maintains the encapsulation
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Design #2 maintains the encapsulation
Design 2's getProductNumbered(anIdentifier) presumably returns a Product object,hence exposes as much information about the Product as design 1.
Originally posted by JUNILU LACAR:
Should Catalog really give out lists of Products? Again, shouldn't Product be responsible for giving out lists of itself? Of course, it could still collaborate with a Catalog, but still the main responsibility would be with Product.
Tight coupling between a ProductList and Product would still be appropriate, I think.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Originally posted by Peter den Haan:
Should a java.util.List really give out an Object? Shouldn't java.lang.Object be responsible for giving out Lists of itself?
Well, no, of course not -- even if it were our own class instead of a standard Java collection class.
Obviously, the Product class is responsible for creating Products in the narrow "new Product()" sense. It is equally fine for another class -- call it a Factory -- to be responsible for creating Products (using new Product()) or Product lists. To reject this is to reject the GoF, which surely counts as a heresy worthy of excommunication from the OO community.
To the contrary, it would be very bad design to give the Product class the responsibility of encapsulating product information and business logic and the management of product collections. Product collections are really a step up from a single Product. More so if you remember that there will probably be database access code and product list caching involved. These responsibilities are quite separate from that of the Product class itself, and tightly coupling them is a mistake.
To illustrate that in a very practical way, what if we introduce a new type of Product (a PremiumProduct) with extra state and behaviour? A Catalog could easily be modified to accomodate this. The same modification would sit rather uneasily in the Product class.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Any design that requires code changes to handle the introduction of a newly derived class is a bad design.
David Roberts - SCJP2,MCP
Originally posted by JUNILU LACAR
What business does Catalog have with creating Products? None, I think. Sure, you can have the Catalog.addProduct(Product) or Catalog.deleteProduct(Product) or even Catalog.searchProduct(Product), but Catalog.getProduct(aProductID) smells like feature envy to me. Mind you, the addProduct() and deleteProduct() methods in Catalog only did so regarding Products listed in the Catalog. No actual Products are created or deleted in those calls. searchProduct() will do a search for a listing of a particular Product in the Catalog. That knowledge and responsibility is appropriate to Catalog.
Originally posted by JUNILU LACAR
[..]However, coupling does not imply breaking of encapsulation. Nor does it imply tight coupling. You are still dealing with high level concepts and you still don't know the details either Product or Catalog and what happens inside Catalog when you hand it a Product.
Originally posted by JUNILU LACAR
When you pass in an identifier for a Product, there may be a little break in encapsulation there resulting in more brittle coupling. Reason: what if you change the way you identify Products? What if you change it from an int to a String or vice versa? You'd have to go into Catalog and do some massaging of the parameter type, perhaps overloading methods to take in the new type of ProductID.
Originally posted by JUNILU LACAR
As for the Catalog giving out a list of Products, I think that's more in the gray area: does it really break encapsulation? In a very strict sense, it does. But then again, if Catalog returns an Iterator or some kind of standard interface that can be used to go through the list, I think it is an acceptable design that would not be too hard to refactor if the need arose.
Originally posted by JUNILU LACAR
Last night, I finally found the results of the last two times I took the pre-assessment exam and I got 4 out of 4 in the Designs and Implementation section each time. I know that the coupling question came out in at least one of them and I answered B.
Originally posted by Desai Sandeep:
I think getters/setters should be looked at from the view-point of the object as a whole; not on its internal representation.If Catalog just has a key to the Product object, then I believe, encapsulation is maintained.However having full access (all the details) to a Product object should break encapsulation.Your views, please!!
Originally posted by Desai Sandeep:
On the other hand, Catalog.getProduct(aProductID), may be still be relying on the Product(or its helper class) to get its information (Since the Product Object itself is not passed as a parameter, it implies Catalog is not probably aware of the Product Object and hence it is trying to get the Product Object using a key - aProductID.In that case, it is reasonable to assume that this method would probably delegate the responsibility to some helper class to get the Product reference) - hence coupling is low and encapsulation (visibility) of Product object in the Catalog is maintained.
Originally posted by Junilu Lacar:
Which is more encapsulated: a Windows shortcut to JavaRanch or the actual IP address (204.144.141.266)? Isn't the Windows shortcut more abstract than the IP address?Well, isn't a reference to a Product more abstract than the actual ProductID? The higher the abstraction you have, the lower the coupling.
Originally posted by Junilu Lacar:
So you are wrong to think that Catalog would not be aware of a Product object if it were passed just a ProductID.
Originally posted by Junilu Lacar:
Again, remember what Allen Holub said: Don't ask the object for information that you need to do something; rather, ask the object that has the information to do something for you.
Originally posted by Junilu Lacar:
[..]As for ProductID, Catalog should never, not one little bit, ever have to be changed just because the implementation of a Product attribute (ProductID) changes.
[..]Holub hints at a solution: don't use primitive types as IDs; identifiers should themselves be Objects. That way, you encapsulate the identifier implementation and shield other classes from changes in the implementation with a contract for using the identifier.
Originally posted by Desai Sandeep:
In the Product and the Catalog case, if the Catalog object has access to the Product object, calling any(or all!) of the getter methods (which are always public!!) of the Product object would reveal all the information to the Catalog.
I would say, by passing the Product object in any of the Catalog methods, Product would be saying to the Catalog - "Hey,Catalog!, you are free to explore me as much as you want!!"
If I think terms of real objects, Catalog would have short description of the Product along with an ID.If the customer wants more information he would request for information from the Catalog by identifying the Product by the ProductID. This is what Design#2 is doing!!
Originally posted by Junilu Lacar:
If your design relied on allowing Catalog to access Product's attributes through getters, that is not an OO design! A design that relies on getters does indeed have Product saying "Hey, Catalog, you are free to explore me as much as you want!"
Originally posted by Junilu Lacar:
So, instead of Catalog having just one piece of information about Product, you want to add another piece? Now you are breaking Product's encapsulation two times! I'm sorry but that's just wrong.
Originally posted by Junilu Lacar:
Just think of objects as highly jealous and possessive things. If you said "Hey, Catalog, do you have a Product that has this ID?" Catalog says "Yeah, see, here it is" and holds it up for you to see. Then you grab it, run away, and start fooling around with Catalog's Product, leaving Catalog feeling very violated because you took his Product and did something (who knows what) with it. This is essentially what happens when you invoke Catalog.getProduct(anIdentifier).
My previous laptop never exploded like that. Read this tiny ad while I sweep up the shards.
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|