ech@pegasus.ATT.COM (Edward C Horvath) (02/28/89)
In article <4343@enea.se>, sommar@enea.se (Erland Sommarskog) writes: >As for bottom-up vs. top-down, Meyer explains this very well in his >book, and it's certainly applicable to the recent discussion. From article <6127@medusa.cs.purdue.edu>, by rjh@cs.purdue.EDU (Bob Hathaway): > Could you elaborate on this, does he advocate top-down, bottom-up, ??? > I haven't read Meyer's book. The book is a GOOD read, and my summary can't hope to do it justice, but: Meyer makes a good case that your current programming assignment is NOT the "real" objective, since the goals and requirements of that program will change, and something else (the same but with *one more feature*; or a different program that deals with many of the same data) will be needed "soon." So: don't start by modeling "function" at all, start with modeling the objects in the problem domain. The objective isn't "new payroll system," it's "understand your enterprise," with a *current* emphasis on modeling employees, benefits, salaries, bonuses, tax situations, etc. Meyer recommends deferring the functional objective as long as possible. What emerges is more like bottom-up than top-down, but with important differences; to me, bottom-up always meant "build the utility libraries first." Once again, emphasis on function. Modeling "employee" requires deciding what data and operations capture the notion of employee. And you can defer things, much as you do in -- hmm -- top down design! Example: all employees get paid, but the algorithm is different for hourly v. salaried employees. OK, declare something you do to an employee -- "Pay" -- and defer the definition. Special cases of employee will instantiate the deferred method in different ways. The presumed benefits -- and again, I haven't made the case, but Meyer is quite convincing -- are that you emerge with a model of relevant entities in your environment, not "merely" a program. Thus the next program is already well on the way to being done: add more classes as needed, more methods as needed, and there it is. Here again, Meyer makes a strong case that already- defined classes should be both *open* and *closed* with respect to modification. "Open" is accomplished by letting older classes be members of or ancestors of new classes; in particular, inheritance allows you to redefine just those features of the new class that you need to change. "Closed" is just that a well-tested class can be cast in concrete: you needn't mess with it, because you can modify by inherit with override. He also makes a rather strong case for multiple inheritance, which is lacking in most O-O languages (but is in Eiffel and C++ 2.0). I don't have the slightest intention of starting a flame war by trying to summarize that issue here: but go read Meyer's treatment. Enough. Go get the book, it may change your life. =Ned Horvath=