Objects by Design Forums Here you can view your subscribed threads, work with private messages and edit your profile and preferences Registration is free! Calendar Find other members Frequently Asked Questions Search Home  
Objects by Design Forums : Powered by vBulletin version 2.3.5 Objects by Design Forums > Main Forums > UML Certification Review Questions > breaking encapsulation
  Last Thread   Next Thread
Author
Thread Post New Thread    Post A Reply
pfexa
Junior Member

Registered: Aug 2001
Location: Berlin / Germany
Posts: 16

breaking encapsulation

In design #1, the Catalog object has a getProducts() method, which returns a collection object, such as a Dictionary or array, containing all the Products the company sells. In design #2, the Catalog object has a getProductNumbered(anIdentifier) method, which returns the Product with the specified unique identifier. Considering the objects returned, which of the following BEST characterizes the two designs?

a) Both designs maintain the objects' encapsulation and reduce coupling by accessing state data via methods only and not directly.

b) Both designs break the objects' encapsulation, adding brittle coupling.

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.

One correct answer.

Which one? C?

Report this post to a moderator | IP: Logged

Old Post 08-29-2001 02:31 PM
pfexa is offline Click Here to See the Profile for pfexa Click here to Send pfexa a Private Message Find more posts by pfexa Add pfexa to your buddy list Edit/Delete Message Reply w/Quote
ESY
Junior Member

Registered: Aug 2001
Location:
Posts: 5

Hi

Excuse my ignorance but what is wrong with A? The usual purpose of get/set is for encapsulation. Why should a parameter ruin this?

Perplexed ESY

Report this post to a moderator | IP: Logged

Old Post 09-03-2001 04:47 PM
ESY is offline Click Here to See the Profile for ESY Find more posts by ESY Add ESY to your buddy list Edit/Delete Message Reply w/Quote
shreedev
Junior Member

Registered: May 2001
Location:
Posts: 24

Lightbulb breaking encapsulation

Hi,
Answer is c). Reason.
In general view encapsulation facilitate a object(catalog) to wrap the data(product information) by methods(getProductNumbered(Id)). There is no meaning we create class to show all the attributes(products) in one method call. Alternatively catalog can be a attribute(Vector) of a class Shop.

Thanks and regards,

__________________
sridhar

Report this post to a moderator | IP: Logged

Old Post 09-04-2001 09:21 AM
shreedev is offline Click Here to See the Profile for shreedev Click here to Send shreedev a Private Message Find more posts by shreedev Add shreedev to your buddy list Edit/Delete Message Reply w/Quote
Duchene
Junior Member

Registered: Oct 2001
Location:
Posts: 1

???

In my opinion...

C could not be correct. The only difference between the two designs is the fact that one returns a single object and one returns a collection of objects. How would returning n objects break encapsulation and add more brittle coupling more so than returning one object? I feel these are virtually equivalent operations.

The only possible solutions are 1 or 2.

The real question is. 'Is it bad to return objects from methods'. I would have to argue that it does increase coupling, but does it really _break_ encapsulation and add _brittle_ coupling. I don't think so.

Therefore, I would guess A.


Anyone have more insight?



Last edited by Duchene on 10-09-2001 at 06:34 PM

Report this post to a moderator | IP: Logged

Old Post 10-09-2001 04:44 PM
Duchene is offline Click Here to See the Profile for Duchene Click here to Send Duchene a Private Message Find more posts by Duchene Add Duchene to your buddy list Edit/Delete Message Reply w/Quote
hsrivatsa
Junior Member

Registered: Jul 2001
Location:
Posts: 10

This is a very tricky question and needs microscopic observation.
The "key part" lies in the phrase, "Considering the objects returned".

Design #1 : In this design a single method call would reveal the entire contents of the catalogue. In a broad perspective this defeats the very purpose of encapsulation. This is probably what we can call as breaking the encapsulation(hmm... maybe we can call this "brittle coupling").

Design #2 : Coupling is increased when compared to Design #1 because Product Code is required for accesing a particular product.

a) Design #1 defeats the purpose of encapsulation.

b) Design #2 maintains the encapsulation

c) Seems the most likely answer.

I would love to see, more replies to this thread.

Report this post to a moderator | IP: Logged

Old Post 10-31-2001 02:06 PM
hsrivatsa is offline Click Here to See the Profile for hsrivatsa Click here to Send hsrivatsa a Private Message Find more posts by hsrivatsa Add hsrivatsa to your buddy list Edit/Delete Message Reply w/Quote
REF
Junior Member

Registered: Nov 2001
Location: Washington
Posts: 9

First, as is common in this industry, I think the question confuses the design idea of "information hiding" and the implementation concept of "encapsulation." I've encountered pretty good agreement among my peers that there's a difference between the concepts. Check out this article: http://www.javaworld.com/javaworld/...psulation.html.

But, since the term used is "encapsulation", that's the term I'll use for clarity.

I think the question doesn't include enough information to really make a definitive answer.

Here's my take, first just from the encapsulation stand point:

Answer a) seems true, but without knowing the origin of the object's returned, it's hard to be sure. If design #1 returns a private collection of products for the client to access willy-nilly, THAT is definately a violation of encapsulation. It could, in fact, return a copy (clone) of a private collection. This would support encapsulation.

Answer b) seems false, but again, without knowing more about where the objects returned really come from it's hard to say for sure.

Answer c) seems possibly true or false, for the reason's I've stated above.

In short, I don't think much can be said about violating encapsulation without more details.

Now, on to coupling:

I believe design #1 has higher coupling that design #2 because clients have access to ALL products whether they need them or not, but that doesn't make #1 a bad design -- just a less desireable one. If it were me, I'd be more inclined to return an iterator rather than the entire collection IF I had to allow clients to access the entire product catalog (say, for displaying it in some UI). If, after more consideration, I found my clients were mostly getting the entire collection of products and then searching through it for one product, design #2 would be a worth-while, highly adviseable improvement.

Design #2 reduces coupling mainly because it narrows the information the client accesses in one call.

You could infer that design #1 and design #2 resulted from addressing the same design problem: access to the catalog's products, and if that's the case, design #2 would be a better choice. I guess if pressed, I'd have to pick c) because design #2 hides (encapsulates) more than #1, but I wouldn't be surprised if a) was also the answer. Frankly, I think the test author was looking for the answer c).

Report this post to a moderator | IP: Logged

Old Post 11-03-2001 04:19 PM
REF is offline Click Here to See the Profile for REF Click here to Send REF a Private Message Find more posts by REF Add REF to your buddy list Edit/Delete Message Reply w/Quote
SZ
Administrator

Registered: Apr 2001
Location: New York
Posts: 492

I would say that shreedev's answer was very to-the-point.

He basically answered that encapsulation is broken in design #1 because the implementation of the collection is exposed. If the author of the Catalog class decided to change the implementation, he would be prevented because user's of the class would already have written code dependant on the type of collection used (do not assume a universal interface here because the question doesn't give any information about this). Thus, shreedev's comment that the collection type could change is an accurate depiction of the problem with brittle coupling.

Brittle coupling means that the encapsulation is not sufficient to prevent user's of a class from being affected by changes to the underlying implementation details of the class. The result is that the client classes have to be modified when the class they use is changed in some fundamental way.

Nevertheless, I can easily see people getting tripped up by this question if they believe that collections all have uniform interfaces.

Report this post to a moderator | IP: Logged

Old Post 11-04-2001 05:15 AM
SZ is offline Click Here to See the Profile for SZ Click here to Send SZ a Private Message Visit SZ's homepage! Find more posts by SZ Add SZ to your buddy list Edit/Delete Message Reply w/Quote
REF
Junior Member

Registered: Nov 2001
Location: Washington
Posts: 9

If the point of this thread was just to come to agreement on the best answer to the question posed (obviously option C), then I apologize for dragging this discussion on. However, if we're trying to understand better why the design alternatives presented are better or worse, then bear with me a little longer please.

SZ, your response made me think a little harder about the design alternatives we're offered in this question:

quote:
...encapsulation is broken in design #1 because the implementation of the collection is exposed.

The collection's type (class) is certainly exposed (Dictionary, array, etc.), but not necessarily the collection's implementation (e.g. how the Dictionary is implemented). Perhaps you mean that the Catalog's implementation is exposed? Even that's not necessarily true: the Catalog's internal implementation of a Product collection could be a Dictionary, but the getProducts() method could return an array (the method copies each product from the Dictionary to a local array which it then returns to the client). This maintains the Catalog encapsulation. IMHO, this implementation would have a similar level of encapsulation as design #2, BUT it could lead to higher coupling (as I mentioned before).
quote:
If the author of the Catalog class decided to change the implementation, he would be prevented because user's of the class would already have written code dependant on the type of collection used (do not assume a universal interface here because the question doesn't give any information about this).

First, good point about not assuming a universal collection interface. I must admit my thinking was somewhat affected by that assumption initially; however, the Catalog author wouldn't be prevented from implementation changes, but he/she would be prevented from interface changes (I mean interface in the general sense, not language specific) like changing the type of collection returned. This constraint exists no matter which design alternative is chosen: the Catalog author that used design #2 would be prevented from changing the type of the "anIdentifier" parameter (as an example) if needed.

I reassert that we really can't say for certain whether design #1 breaks the Catalog encapsulation without being given more information about its implementation. What we can say is that design #2 hides more (is a stronger encapsulation) and results in lower coupling.

From a pragmatic stand point, we're often faced with returning a collection of things owned by some container. If, for some reason, you can't use an iterator, design #1, implemented such that maintains encapsulation, is a perfectly reasonable design.

Again, I apologize if I've beaten a dead horse. Please let me know if anyone found this helpful/informative. Or, just tell me to, "Shut up for goodness sake."

Report this post to a moderator | IP: Logged

Old Post 11-05-2001 02:19 AM
REF is offline Click Here to See the Profile for REF Click here to Send REF a Private Message Find more posts by REF Add REF to your buddy list Edit/Delete Message Reply w/Quote
sby
Junior Member

Registered: Nov 2001
Location:
Posts: 16

I think the answer is (c), no question about it.
Just read the (c) - makes future changes easier.

Product objects may be later mapped to database with lazy instantiation... This new requirement will break design immediately.

Regards

Report this post to a moderator | IP: Logged

Old Post 02-22-2002 05:49 PM
sby is offline Click Here to See the Profile for sby Click here to Send sby a Private Message Find more posts by sby Add sby to your buddy list Edit/Delete Message Reply w/Quote
All times are GMT. The time now is 07:33 PM. Post New Thread    Post A Reply
  Last Thread   Next Thread
Show Printable Version | Email this Page | Subscribe to this Thread

Forum Jump:
Rate This Thread:

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are ON
[IMG] code is OFF
 

< Contact Us - Objects by Design >

Powered by: vBulletin Version 2.3.5
Copyright ©2000 - 2017, Jelsoft Enterprises Limited.
Copyright 1999-2005, Objects by Design, Inc.