The question is will people write OO code?

[Eric]

While I did do compiler courses and database courses in school, as a engineering
major I "missed" the software engineering courses. Also they weren't that
important in the early 80s! I tried to kick the procedural habit a few times
but I wrote really bad OO code. The OO way of thinking is harder then I thought.
So as much as I would like to go OO, I wonder if I can.

Eric


"Mark" <mknuttall@nospam.yahoo.com> wrote:
>
>I agree that vb.net will be different and will involve learning. Also that
>good OOD is a steep curve for those with years of procedural coding. On
>the other hand procedural code can still be written in a "more" OO language.
> The question is will people write OO code?
>
>Mark
>

[Mark]

Eric,
From the sound of it you should be able to learn OO. We have old (not
age - time) procedural people learning OO. What you probably need is a mentor.
That is helping the people I work with. The wierd thing is that OO is the
way we naturally think. Or so I've been told. OO takes more design up front
and a RAD approach is much better than the traditional Analysis/Design/Implement
(or is that "here is the business problem now start coding!"). Don't worry
about writing bad OO code. Good OO comes with practice. And as usual we
can always make our code better the second time. The thing to remember is
to write to interfaces (Standard interfaces, abstract classes and super classes)
and to pick a tool that helps you do this and one that helps you make changes
easier.

Mark

"Eric" <cael@pc.jaring.my> wrote:
>
>
>While I did do compiler courses and database courses in school, as a engineering
>major I "missed" the software engineering courses. Also they weren't that
>important in the early 80s! I tried to kick the procedural habit a few times
>but I wrote really bad OO code. The OO way of thinking is harder then I
thought.
>So as much as I would like to go OO, I wonder if I can.
>
>Eric
>
>
>"Mark" <mknuttall@nospam.yahoo.com> wrote:
>>
>>I agree that vb.net will be different and will involve learning. Also
that
>>good OOD is a steep curve for those with years of procedural coding. On
>>the other hand procedural code can still be written in a "more" OO language.
>> The question is will people write OO code?
>>
>>Mark
>>
>

[Tom Barnaby]

"Mark" <mknuttall@nospam.yahoo.com> wrote:
>
>The wierd thing is that OO is the way we naturally think. Or so I've >been
told.

Yes that is indeed the conventional wisdom. Having done my share of programming
in both procedural and OO, and having taught my share of lessons on both
models, I think this is a drastic oversimplification. It also tends discourage
students when they are not understanding this new "simpler" or "more natural"
programming style.

It is true that the physical world is composed of objects. These objects
exhibit attribute and behaviors. We interact with high tech objects all the
time without worrying about the internals (encapsulation). We categorize
objects into generic types that share common attributes and behaviors. For
example a dog is a type of canine which is a type of mammal which is a type
animal. (inheritance).

The simplicity and "naturalness" of OO ends here. Because this is where we
stop dealing with static objects and start moving into the dynamic realm.
Things get exponentially more complicated when, instead of coding against
fixed static objects, we are coding against an object whose exact behavior
is determined an runtime. Debugging code paths becomes more complicated because
we need to deal with the possibility that the program might not branch to
that CAnimal.Eat() call, but to one in a derived class: CDog.Eat() for example.

Don't get me wrong, I believe OO programming is great. But I think we do
people who are new to OO a disservice when we make any sort of claim that
OO is easy.

Tom Barnaby
www.intertech-inc.com

[Mark]

Agreed Tom. I was really stating what others have said. I am mostly self
taught. I feel for me OO is pretty easy (still have much to learn - it never
ends). I have a procedural background but not that many years. For most
people I don't think it is that easy though. But with a good mentor, the
learning curve is not so steep. The only people I know who are doing OO
are long time procedural and it seems to be tough on them. But they can
learn. Although some can't or don't want to. It is tough to read people's
minds. I wonder if anyone has experience with people who have no previous
experience in programming and are learning a more OO language (Smalltalk,
Java, C++, etc - from other discussions I know these are by definition not
true OO) for the first time. How are they doing given that programming itself
is not easy for most people?

Mark

"Tom Barnaby" <tbarnaby@intertech-inc.com> wrote:
>
>"Mark" <mknuttall@nospam.yahoo.com> wrote:
>>
>>The wierd thing is that OO is the way we naturally think. Or so I've >been
>told.
>
>Yes that is indeed the conventional wisdom. Having done my share of programming
>in both procedural and OO, and having taught my share of lessons on both
>models, I think this is a drastic oversimplification. It also tends discourage
>students when they are not understanding this new "simpler" or "more natural"
>programming style.
>
>It is true that the physical world is composed of objects. These objects
>exhibit attribute and behaviors. We interact with high tech objects all
the
>time without worrying about the internals (encapsulation). We categorize
>objects into generic types that share common attributes and behaviors. For
>example a dog is a type of canine which is a type of mammal which is a type
>animal. (inheritance).
>
>The simplicity and "naturalness" of OO ends here. Because this is where
we
>stop dealing with static objects and start moving into the dynamic realm.
>Things get exponentially more complicated when, instead of coding against
>fixed static objects, we are coding against an object whose exact behavior
>is determined an runtime. Debugging code paths becomes more complicated
because
>we need to deal with the possibility that the program might not branch to
>that CAnimal.Eat() call, but to one in a derived class: CDog.Eat() for example.
>
>Don't get me wrong, I believe OO programming is great. But I think we do
>people who are new to OO a disservice when we make any sort of claim that
>OO is easy.
>
>Tom Barnaby
>www.intertech-inc.com
>
>