On 4/27/05, Chris Dempsey <[EMAIL PROTECTED]> wrote: > True, this could possibly done with composition. The only reason I > would prefer inheritance here is to prevent bad compositions. > > Abstract Room is extended by BallRoom and GuestRoom. Room has methods > like reserve(), checkAvailability(startDate, endDate). GuestRoom has > methods and attributes specific to things like beds and pay-per-view > movies and so on. BallRoom has methods and attributes dealing with > things like presentations and catering.
Since you can change the function of many rooms, you might be better off having a concrete Room object that had a RoomFunction data member where RoomFunction is an abstract class that the various specific functionalities extends (MeetingRoom is-a RoomFunction, BallRoom is-a RoomFunction). This keeps the Room model separate from what happens in it and allows you to easily change the function of a room. It's the Employee / Manager / Role example in a different problem space (Manager is-a Role, Employee has-a Role). In both cases, using composition allows for multiple roles / functionality. For example in most hotels the ballroom can actually serve several purposes (including being subdivided into multiple rooms, each with different functions!). -- Sean A Corfield -- http://corfield.org/ Team Fusebox -- http://fusebox.org/ Got Gmail? -- I have 50, yes 50, invites to give away! "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
