BETA - An Example (of Failure)
The BETA project started in 1976, briefly escaped into the real world and was quickly beaten to death only to have its corpse revived in academia. It's one of quite a few languages which seems destined to never catch on. It's kind of a shame as it's an interesting language, but I'm certainly in no position to change this and, in any event, am not certain I would want to.
Yesterday I posted an example of OO in BETA. Prior to that, I posted an interesting quote from the BETA researchers. In the quote, they talked about how BETA was for modelling and they didn't like inheritance for code reuse. BETA is all about modelling things properly. They talk about this a lot.
That's interesting because in yesterday's example, they have an employee pattern (class) which must have subpatterns (subclasses) for instantiation. Those subpatterns are "worker" and "salesman". That allows us to present a dilemma many OO design books include: what happens if you're a boss and one of your workers loves your products and wants to sell part-time to prove they can do it? Do you tell them "no" because your software won't model it? Of course not! You might tell them "no", but not because of software. The software is there for you, not the other way around (curiously, many businesses I've worked at seem to have overlooked this point).
So your challenge — the same one that many beginning OO design students pull their hair out over — is to decide how would you design employee objects which allow an employee to be both a worker and a salesman? Or a programmer and a manager? What about any arbitrary combinations?
Hint: roles make this much, much easier.
Freelance Perl/Testing/Agile consultant and trainer. See http://www.allaroundtheworld.fr/ for our services. If you have a problem with Perl, we will solve it for you.
And don't forget to buy my book! http://www.amazon.com/Beginning-Perl-Curtis-Poe/dp/1118013840/
I've been looking for any good model used as an inheritance example in any language, and I have yet to find one. Excluding all of the toy models that we authors use to show the syntax and fundamental concepts, I usually find that people fail when it comes to making their language actually do things the way that we do it in the real world. Part of that is a lack of imagination, but part of it is also a lack of skill.
I'll try not to rant, though.
In Head First Java, there was a chapter about decorators, using an order of coffee as an example. There as so many types of coffee (with sugar, with milk and sugar, and infinite combinations of other things) that you can't possibly make an instance that handles them all, right? Instead, you decorate the instance to override its price() method (which is not adding unique behavior at all, but we'll let that slide).
Well, the decorator is perhaps the first pattern that should be taken away from anyone. The pattern tries to solve the problem of instances having unique behavior, which is all fine and good, but I find that people get all excited about the decorator pattern (having had direct experience trying to explain to a group at a Python users group meeting that there's almost always a better, easier way).
How do we really order coffee? You tell the barista what you want and they type it into a cash register somehow. They don't have a button for every combination of unique ingredients, so why would you ever model the world like that? Well, you model the world like that because some language tells you too. A lot of people sift around in their language's toolbox until they find something that just might work. If they can even coerce UML out of it, it must be right because hey, look at the diagram. Decorators make that way too complicated, and it's not how real people deal with the real problem.
It's not that people aren't smart though. Look at the diasters of buildings that architects design. If you were at YAPC 2006 in Chicago, you experience a Mies van der Rohe building that was impossible to climatically regulate, making it either to hot in some places or too cold in others. You might like Frank Lloyd Wright, but his flat roofs collect water and snow, and thus have major leakage problems. Frank Gehry might make fantastic façades, but the interiors are awful. All of them share the same problem we have with inheritance, decorators, and whatever. They were in love with a "pretty" solution in search of a problem, which is how most people tend to program computers (and it gets worse when they only know one language).
I've been thinking about how I would explain all this to someone though. We don't get into design in Intermediate Perl, but I figure we'd have to break it down to what you are modeling first. Is it something:
Instead of focusing on the language feature, which usually gives readers the idea that they need to use that feature, focus much more on the intent. Anyone know of any good books, for any programming language, that do that?