Can a low-level programmer learn OOP?

[Dave Baum]

In article <f78et20h6h at news1.newsguy.com>,
 Chris Carlen <crcarleRemoveThis at BOGUSsandia.gov> wrote:

> Why would OOP be better?  Different is not better.  Popular is not 
> better.  What the academics say is not better.  Less lines of code might 
> be better, if the priority is ease of programming.  Or, less machine 
> execution time or memory usage might be better, if that is the priority.

Short answer: Increasing programmer productivity is better, and OO 
frequently accomplishes this.

Longer answer:

Consider OOP as one tool in the toolbox.  It isn't "best" for every 
conceivable problem, but neither is procedural programming, functional 
programming, table driven state machines, or any other style of design 
and/or programming.  Each works well in some situations and poorly in 
others.  Having a large number of tools at your disposal, and knowing 
which ones to use, is a big plus.

Let's talk about design versus implementation for a moment, since OO 
really applies to both, but in different ways.  You mentioned state 
machines, and that is a good example of a design technique.  You can 
look at a problem and convert it to a state machine (design), then 
implement the state machine in whatever language your computer 
understands.  Over the years, finite state machines have proven to be 
very effective models because:

1) there are plenty of real world problems that map cleanly to a state 
machine

2) state machines are easy to implement reliably in most computer 
languages

3) if you have already implemented a state machine for problem A, then 
implementing it for problem B is pretty easy - the real work is 
translating problem B into a state machine

OOD is similar.  There are a large number of problems for which an 
object oriented design is a good fit.  Once you have an OO design, you 
then need to implement it, and languages with good OO support make this 
a lot easier.

>From what I have seen, the advantages of OO tend to increase with the 
size of the project.  For example, polymorphism generally lets M clients 
work with N different kinds of objects by writing M+N chunks of code 
rather than M*N.  When M or N is small, this difference in minor, but as 
M and N increase, it becomes significant.

By combining state and function, objects provide a good means of 
encapsulating operations and keeping client code independent of lower 
level code.  This is a very big win since it allows for the evolution of 
the lower level code without breaking all of the client code.  As with 
polymorphism, the benefits of encapsulation tend to increase with the 
size of the project.

Even before OO languages were popular, it was quite common to use some 
basic OO design in order to increase encapsulation.  If you look at 
almost any GUI framework from the 80's or early 90's you'll find lots of 
C code with structs that the user is not supposed to mess with, and then 
functions that take pointers/handles/indexes to those "magic" structs as 
the first argument.  This is really OO design implemented in a 
procedural language.  In fact, GUI frameworks are an excellent example 
of a domain for which OO has established itself a very good way to model 
the problem.

I could probably spend a lot more time on the merits of OO, but I think 
if you really want to understand its benefits you need to work with it 
in a domain for which OO is useful.  It is possible that the specific 
projects you work on really wouldn't benefit much from OO, and that is 
why you haven't had the "a-ha!" moment.  Forcing an OO model onto a 
problem just for the sake of OO will only result in frustration.

Dave