Actually, if you truly want software design skills, then you need to master how to cook Julienne fries perfectly every time. *grins*
This is a perfect example of a religious statement - something that is said through belief, not proof. While hakkr may (or may not) have some validity, s/he cannot prove any of it.
To tell you the truth, you have to know what you want to do and how much effort you want to put into it. Then, and only then, can you determine how you want to design it. For example, I'm working on two projects right now, both of them games. One, I'm designing on the fly. The other, I'm going through requirements-HL design-LL design-mockups-etc. The whole 9 yards. Why? The first game is tiny and I'm just playing. The second is huge and I want to market it.
What's the difference? Well, if I want to sell something for millions of dollars, I need to prove to the purchaser(s) that it works. The only way to do that is to document what I did. If I don't care about that, then who needs design docs!
As another disagreement with hakkr, software design is PERFECTLY in line with laziness. I'm lazy, so I don't want to do it over ten times. I want to do it once, only once, and be able to prove it. (That's where hubris comes in!) Impatience? Well, why design is in line with impatience is left as an exercise for the reader.
------
We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement. | [reply] |
I digress, you need to have OO programming skills in order to use the design methods. There is no point making a Class diagram if you don't know how to write a class. OO code is also easier to maintain. As for impatience the impatient programmer skips the design and gets straight on down to good ol' perl hacking. Also I'm an advocate for design especially whilst working on 'million dollar' projects i.e 'big projects' like I said. However you are indeed you are right, long term lazyness favours design short term lazyness favours none
| [reply] |
I strongly disagree.
While good design principles and techniques interact with object oriented programming, neither understanding or use of OO techniques is necessary to understand and use good design principles, and vice versa.
Furthermore OO design has characteristic traps and pitfalls which have to be worked around, and I remain to be convinced that the best design for any complex system is always OO. Quite the contrary in fact. There are many possible ways to design complex systems, and OO is merely one of the available tools for doing so.
In short, I agree with dragonchild. When someone stands up and says, "OO is good. OO is great. Everyone should be using OO." I think, "That is someone who has a religious point of view, I wonder if they have ever really thought about what they are saying?"
It is certainly true that you have stated your position without the inclusion of any supporting evidence. Certainly if your concept of how to go about designing software starts and ends with making Class diagrams, then you have a lot to learn...
| [reply] |
And I still don't agree with your original statement. While OO has a religous following among buzz-word enabled white collars. I don't believe that procedural design has become any less valid. From my experience they both have pros and con's like anything else in life.
| [reply] |