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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:212970 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
