Bottom-Up or Top-Down
I know its a very general question but this is the reason why its difficult to find an answer in goolge. So as the title says what is the best approach when it comes to design an Object Oriented programm, Bottom-Up or Top-Down? In other words should i think first what are the smallest elements (objects) of the system and then see how to connect them, or think as the whole programm as a big object and then cut it down in smaller pieces?
Please donīt say it depends :)
Thanks for your help
Originally Posted by 3xpr1ment
Seriously it does. In OOP you will mostly be using Bottom up.
The dangers of bottom up design/development is that you stand the risk of solving a problem you don't have because you've been busy with all those gory details without realizing that your actual problem doesn't deal with those details.
Originally Posted by r035198x
The dangers of top down design/development is that you keep on forgetting or postponing solutions to those gory details (see above) with the risk of crossing deadlines.
I prefer a 'from the middle' approach.
Originally Posted by JosAH
... But the OP raises a valid point... and one which I think about, at least to some extent, at the beginning of each new programing exercise... And, also one to which I don't yet know the answer... if in fact there is a definitive answer...
someone sugested i read:
Design Patterns: Elements of Reusable Object-Oriented Software..
which I downloaded,
but after a few pages realised that although the book is not an advanced technical treatsie, it does the require the reader to be reasonably proficient in at least one object-oriented programming language... as do most books/blogs/media/and learning resources of this type
So I came to the conclusion of suck it and see.. have a go and see what happens..
I make loads of mistakes with my code and programming exercises, but usually get there in the end...
Then, flying in the face of the maxim "if it aint broke don't try to fix it.." I try to think of different or alternative solutions. hopefully i will learn from the mistakes...and the pointless hours spent trying to re-invent the wheel...
I have in fact, (with the kind assistance from other subscribers to this forum) definitely learned from both..
When i gain sufficient proficiency, and have some practical understanding of the concepts of things like polymorphism and abstraction.... then I'll read that book.
Well, I was sort of serious; in a full top down design you stand the risk that you have to solve problems with all the gory details in the end (when you've finally ended at up at the bottom) and worst case, those details tell you that you can't solve your problem the way you had in mind when you started your top down design.
Originally Posted by sonny
On the other end, when you've built your beautiful, elegant, oh-so-clever bottom up framework you stand the risk of beautifully, elegantly, oh-so-clever NOT solving your original problem.
That's why I prefer a 'from the middle' approach.
That's true, you have to know how to juggle with all those OO tricks and principles before you can appreciate all those patterns mentioned and explained in that book. It is a valuable book, keep it for a later reading. There is also common sense and rules of thumb, they also have their value. I happen to have a few rules of thumb myself (2353563452390983 or so) that have helped me more often than not. They are not laws carved in stone and there are exceptions to them but they are also part of commons sense.
Originally Posted by sonny
If you take design as the whole shebang, from requirements to development, then really, most cases are top down, with a bit of the aforementioned middle. That's how UML works, with it's concept of Use Cases (which map reasonably well to agile stories). And figuring out what the user wants to see, and how they want to interact with a system, is very much Top, I'd say.