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.