Subj : Re: Change Patterns (was: Polymorphism sucks) To : comp.programming,comp.object From : rem642b Date : Sat Aug 20 2005 01:01 am > From: Chris Sonnack > ... programmers shouldn't design solutions that address a specific > problem in a specific way, but should abstract the problem and solve > it in the most general way possible. You present a false dichotomy between one extreme and the other. There's an optimum somewhere between solving only the test data already given to you and generalizing the problem so much that it costs ten times your totally budget for the next century. > *Conceptually*, which is the whole point of OOP, code and data are > bound, and there are languages that don't work that way. There are two possible conclusions to that: -1- Java isn't an object-oriented language at all, it's a class-oriented language, because you can't define arbitrarily different methods for each instance of a class which would be needed to satisfy the definition of OOP. -2- The definition of OOP is wrong. OOP doesn't match methods to instances, it matches methods to classes. You pick which. > > Um, Genetics are only *approximately* hierarchial. [...] > You're upside down. (-: > Think of a given animal as the root. Two parents, who have two > parents, each of whom have two parents, etc. That's valid only one level deep, because of incest whereby brother and sister mate and produce children so that there are only two grandparents instead of four because the trees merge already at that second level. *any* exception whatsoever, even one case of productive incest in the whole world, makes the tree model only approximate instead of exact, and you know as well as I do there are a lot more than one case of productive incest in the world, so pretending one of those cases doesn't exist doesn't even nearly fix the problem. > The fact that you can't fully spec out any non-trivial project DOES > NOT mean that you don't do as much analysis as possible up front. With that totally flexible (wishywashy, tautologically true) statement, we're in agreement on meaninglessness. Now for something more practical, there's a wide range of how much analysis is possible up front, from total design of every aspect, to just a vague idea whether the project can be done at all and how it might be accomplished by methods not yet even conceived. > > Here's a good mantra for all software people: REFACTOR > It's a great mantra and one I apply to my personal projects. In the > business world, things move too fast, so you need to get it as right > as possible up front. Odds are very much against you revisiting it > again (unless you really screwed it up the first time). If you were given a week (five workdays) to finish some module of a project, and you got a rough prototype finished and working in one day, but then you realized you could refactor it to be much better, would you spend the next day refactoring it, and turn it in three days early, or would you turn in the rough version at the end of the first day, four days early? I don't consider getting the first rough draft working in very short time, so that you then understand better what's going on, to be screwing it up. .