|
|
Posted by Ben C on 10/07/07 15:40
On 2007-10-07, Jerry Stuckle <jstucklex@attglobal.net> wrote:
> Ben C wrote:
[...]
>> I can believe you in theory, but I've never actually seen any good OO
>> programming, and lot of bad OO programming. Where does this training
>> come from? Who has this experience?
>
> For one thing, I've been doing OO design for around 20 years, 17 of
> those as a consultant. I've been on some projects which have good
> designs, and managed OO projects. Also, I've taught several OOAD
> courses to various organizations.
>
> The experience is in some corporations. I have been brought in as a
> consultant when they don't have that experience, to help them along.
> Some I train, some already have been trained but no experience.
>
> You're not going to get it out of a library book. This is something you
> need to do hands on, with experienced designers.
No disrespect, but this kind of talk isn't winning me over.
[...]
>>>> OO can encourage people to make too many design decisions up-front,
>>>> before they really know what they want to do yet.
>>>>
>>> Good design (not just OO) dictates that your decisions MUST be made up
>>> front.
>>
>> For houses, yes, not for programs.
>>
>
> Nope, the same it true for programs. Otherwise those programs become a
> mess of fixes, half-assed patches and other such stuff.
Not true.
> It wastes programmers time and makes the code less reliable and harder
> to maintain and modify later.
No-one's arguing for spaghetti here. Everyone wants a well-structured
program at the end that does the right thing and is easy to maintain.
But how do you get there?
There are no easy answers. OO and design up-front have plenty of
problems too. The most obvious is committing to the wrong design too
early because at the time of making the design the problem was not
properly understood (however much everyone may have claimed they
understood it).
>>> Can you imagine creating the blueprints after the house is 1/2 built?
>>> But that's how a lot of people approach programming problems.
>>
>> Indeed, and many programming problems are better approached that way.
>>
>
> Nope. No programming problem is "better" approached that way. Only
> those who are either unable or don't want to plan ahead think that.
In my experience many people believe they are more able to plan ahead
than they actually are. Especially when they are put under pressure to
produce professional-looking designs and plans.
> Programmers want to write code. You have to drag them kicking and
> screaming to write *any* doc. And they will find every excuse they can
> to not do it. Including that it "isn't necessary".
Generalizations like that aren't helpful. If you insist on a doc, or a
design, or a plan, then most people will produce them in order to make
you shut up. They won't necessarily be any use though.
Navigation:
[Reply to this message]
|