• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Disagreement with Encapsulation example of Head First OOAD

 
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
shukla raghav
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 208
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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

 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The "best" option would be:

 
shukla raghav
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

reply
    Bookmark Topic Watch Topic
  • New Topic