I think the point that he was trying to make was that it's easy to get caught up in the "OO is _always_ the best way to get the job done" mindset, when in fact, it may not be. Or even further the "it _needs_ a framework" mindset when it may not.
I always laugh when framework documentation includes a chapter on how to write a "Hello world" screen ;) Roland -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Rinehart Sent: Wednesday, July 27, 2005 9:56 AM To: [email protected] Subject: Re: [CFCDev] The Parable of the OOP and Breakfast Well, that was a weird post to read while eating breakfast. I think it's fairly misguided, as it contrasts a good procedural design (the engineer's perspective) with really lousy OO design. > The second advisor, a ColdFusion developer, highly skilled in Mach-II, > Model-Glue and java, immediately recognized the danger of such > short-sighted thinking. He said, "Toasters don't just turn bread into > toast, they are also used to warm frozen waffles. What you see before > you is really a breakfast food cooker. As the subjects of your kingdom > become more sophisticated, they will demand more capabilities. They > will need a breakfast food cooker that can also cook sausage, fry > bacon, and make scrambled eggs. A toaster that only makes toast will > soon be obsolete. If we don't look to the future, we will have to > completely redesign the toaster in just a few years." I'll go a stretch and call myself skilled in OO - my reply would be "It's a toaster. It needs to be able to cook frozen bread products *made for the interface of a toaster*. Asking it to cook eggs, bacon, and etc. is just plain silly. If you want something that makes eggs, go spec a frying pan." This paragraph is a nice example of a naive, unbalanced approach to OO where you think one master object can be extended to do everything from make toast to fly to Mars. > "With this in mind, we can formulate a more intelligent solution to > the problem. First, create a class of breakfast foods. Specialize this > class into subclasses: grains, pork, and poultry. The specialization > process should be repeated with grains divided into toast, muffins, > pancakes, and waffles; pork divided into sausage, links, and bacon; > and poultry divided into scrambled eggs, hard-boiled eggs, poached > eggs, fried eggs, and various omelet classes." No right-minded OO designer would do this. That's an inheritance tree that exists for no real reason. > "The ham and cheese omelet class is worth special attention because it > must inherit characteristics from the pork, dairy, and poultry > classes. Thus, we see that the problem cannot be properly solved > without multiple inheritance. At run time, the program must create the > proper object and send a message to the object that says, `Cook > yourself.' The semantics of this message depend, of course, on the > kind of object, so they have a different meaning to a piece of toast > than to scrambled eggs." Neither CF nor Java nor .NET support multiple interfaces. That's largely because it's a much better idea to program to interfaces instead of implementations - and anytime you inherit, you're carting around your entire implementation tree. Composition could also be used here - an omelette is not an egg, nor is it a pork. It's made up of ingrediants, it isn't extensions of the ingrediants themselves. But I would not, not matter how good the omelette design, try pouring it into a toaster. > "Reviewing the process so far, we see that the analysis phase has > revealed that the primary requirement is to cook any kind of breakfast > food. In the design phase, we have discovered some derived > requirements. Specifically, we need an object-oriented language with > multiple inheritance. Of course, users don't want the eggs to get cold > while the bacon is frying, so concurrent processing is required, too." But that's a crock! The requirements are to make toast, and trying to do anything more is silly! If its intention is to show precedural vs. OO, this whole parable is a farce. > "We must not forget the user interface. The lever that lowers the food > lacks versatility, and the darkness knob is confusing. Users won't buy > the product unless it has a user-friendly, graphical interface. When > the breakfast cooker is plugged in, users should see a cowboy boot on > the screen. Users click on it, and the message `Booting Application > Breakfast v1.2' appears on the screen. (Breakfast v1.2 should be out > by the time the product gets to the market.) Users can pull down a > menu and click on the foods they want to cook." An OO designer probably wouldn't give a rats ass about the UI. They'd specifically work to separate the application from the UI, letting it be anything it wants: a simple analog knob, a digital GUI, or an automated telephone system where you can call in to start your toaster. It's about interface again, not implementation. > The king had the computer scientist thrown in the moat, and they all > lived happily ever after. Well, yeah, if that's the best guy the king could hire, I'd throw him in the moat, too. -- Get Glued! The Model-Glue ColdFusion Framework http://www.model-glue.com ---------------------------------------------------------- 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ---------------------------------------------------------- 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
