aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Disagreement with Encapsulation example of Head First OOAD Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Disagreement with Encapsulation example of Head First OOAD" Watch "Disagreement with Encapsulation example of Head First OOAD" New topic
Author

Disagreement with Encapsulation example of Head First OOAD

shukla raghav
Ranch Hand

Joined: Aug 03, 2008
Posts: 200
Well if you have read Head First OOAD in the first chapter they have explained the Guitar Application. Here are the members of the Guitar class in the application.

Guitar
- serialNumber : String
- price : double
- builder : Builder
- model : String
- type : Type
- backWood : Wood
- topWood : Wood

//associated getter/setter

here Builder,Type and Wood are enumerated types. There is an inventory class that has the List of guitars and has a search(Guitar) method, when passed with a guitar object it finds in the list and returns the appropriate guitar. Since the customer does not provide all the values for the guitar members i.e. never provides the serial number and price but the details for the rest of the members, the books tells that we must encapsulate the details provided by the customer in a class called GuitarSpec which is as follows.

GuitarSpec

- builder : Builder
- model : String
- type : Type
- backWood : Wood
- topWood : Wood

//associated setter/getter

and accordingly the Guitar class changes to the following


Guitar
- serialNumber : String
- price : double
- spec : GuitarSpec

//associated setter/getter

My Question

1. Doesnt the creation of a GuitarSpec Class out of the blue violate the basic fundamental of OOP in the sense. There is nothing like GuitarSpec in the real World. no one is dealing in a GuitarSpec, creation of such encapsulations out of the blue just for ease contradict to the real world paradigm that is the very essense of the Object oriented programming. In OOAD we identify the entities that participate in the system but can we create some magical class that does not justify its existence in the real world? The GuitarSpec can never be the part of any Use Case how can we create an object of that sort and consider it a part of a real world Object like a Guitar. Please throw some light on this because till now i have been performing identification of Classes only based on there one to one correspondence with Real World.
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1666
    
    7

Your assumption/understanding that an object oriƫnted design should only incorporate real world objects is false
Certain levels of abstract will simply break the real world analogy.


Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
shukla raghav
Ranch Hand

Joined: Aug 03, 2008
Posts: 200
you may be right but not a satisfactory response i feel. Here is my reason for the same. when you say

Guitar
- serialNumber : String
- price : double
- spec : GuitarSpec

//associated setter/getter

what we are doing is Aggregation (associating Guitar class with the GuitarSpec Class by means of a reference object). Aggregation can be deciphered as "is part of" in terms of OOP. By any means is the GuitarSpec a part of Guitar. In very vague sense it may be but you dont get a wooden board with a paper pasted on it that says GuitarSpec and lists all the specification. a Spec means specification in other words - set of information.

Whereas in following example i agree that aggregation is apropriately used

Employee

- empID
- empName

- empFlatNo
- empBuilding
- empStreet
- empArea
- empState
- empPhone

- empDOJ
- empDesig

//associated Setters/Getters

now we can use Aggregation for loose coupling

Address

- empFlatNo
- empBuilding
- empStreet
- empArea
- empState
- empPhone

//associated setters/getters


Employee

- empID
- empName

- empAddress : Address
- empDOJ
- empDesig

//associated Setters/Getters

here YES the Address exists and is a valid real world entity but GuitarSpec - when do we use a GuitarSpec ???





Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1666
    
    7

Sure, an OO-model usually contains classes that are an abstraction of some entity in the real world. These classes usually define a domain of some kind.
However, OO design is not in any way shape or form limited to "mimicking" the real world, as helpful an analogy as that might be.
It's actually a bit of a pitfall when starting out with OO design, as far as I'm concerned.
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
Characteristics or details or specifications of something are "real-world" concepts. In OO software design we are free to create classes and objects in any way, according to any possible design, that we, the designers, see as appropriate. This freedom of design is a key strength of the design methodology when compared to software design 40 or 50 years ago.

Keep in mind that having knowledge of something and having skills in something is not the same. One may completely understand how something is done, but still fail to be able to do it well, or even do it at all.
shukla raghav
Ranch Hand

Joined: Aug 03, 2008
Posts: 200
Thanks Jimmy for providing another angle to the discussion. I do not say that specification is not a rael world entity but my point is simple -

"Is Specification a valid attribute of a Guitar"

we can create a GuitarSpec class, no problem with it but to replace guitar attributes by its Specification is not a very good OO paradigm. rather having an extra constructor just for specification must solve the purpose. It is very obvious that while providing the specification for a guitar to be serched in the inventory, the user will not provide the serial num and price as search criteria so except these two rest form our specification.Let the user provide the specification and we can just have another constructor to identify the specifications provided

Mathieu Fortin
Greenhorn

Joined: Jan 29, 2011
Posts: 16
You "could" create a GuitarSpec class for the same reasons you created a Wood class or a Builder class in the first place. I say "could" because in the end this is all debatable. Instead of trying to match 1-to-1 object to its real world counterpart, just aim at providing a clean design which will be easily maintainable by the next developer. And personaly I better see this:than this:Makes you classes simpler, with less code, easier to read, and yes, more encapsulated.

Mathieu
http://simpleadn.blogspot.com
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
The "best" option would be:

shukla raghav
Ranch Hand

Joined: Aug 03, 2008
Posts: 200
Thanks Mr Fortin,

Your view is appreciable and i loved your small little article with the Joke about the developer thinking i have shared it on my Facebook, and Jimmy that is a more elegant solution thanks alot.

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Disagreement with Encapsulation example of Head First OOAD
 
Similar Threads
Create a class called Appliance
Key Class for Products
Help with overriding methods
MVC is not object oriented??
Comparator and Comparable