On 4/27/05, Kleanthis Economou <[EMAIL PROTECTED]> wrote: > An instance of a Hotel (holidayInnLA, holidayInnNY etc) as a building > structure anyway, is a composition of Floor instances (firstFloor, > secondFloor etc). A floor instance is a composition of rooms and > utilitiy areas
You know, a lot of this really depends on what you are modeling. If you're creating a model for a surveyor or architect, the floors are very important. If you're creating a model purely for guest booking systems, the floors are not important (beyond being able to tell a customer which floor their room is on). This goes back to what Micha said (omg I'm agreeing with Micha again!) - people tend to overthink this stuff! A hotel is mostly just a collection of guest rooms and facilities. Bear in mind that most booking systems require that you can search for rooms with a given set of criteria so for the most part rooms are just rooms but they have attributes that are searchable (I want a king-size non-smoking). If you're modeling the bigger picture, hotels themselves have their own basic attributes that again must be searchable (I want a pool, an American restaurant and a seaview). A catalog of hotels has different requirements again (number of rooms, prices, pictures, distances from local attractions). How you model something depends on the problem you are trying to solve so you must consider the context and not just focus on the model itself. > (by the way you may want to see a room as a special case > of a utility area for even greater flexibility but let's ignore that > for now). Don't forget KISS! Keep It Simple Stupid! Don't over-design things. XP talks about YAGNI - You Ain't Gonna Need It! - as a guideline for keeping your designs simple. Both Joshua Kerievsky and Martin Fowler talk about this in the context of refactoring (start simple, get it working, then get it 'right' as you need to touch the code to cater for enhancements etc). > There is no right or wrong at the end of the day. Right. Definitely no "one true way"... > The design patterns themselves are refactorings > in reverse order which is why most people understand a pattern once > they actually run into the problem it addresses instead of > understanding the pattern without having experienced the problem at > first hand. I'm not sure I'd characterize them as "refactorings in reverse order" but I think I get what you mean. You're certainly right about people not understanding patterns until they've encountered a situation that a design pattern applies to. -- 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]
