OOP & Abstract Classes

[Ulrich Eckhardt]

Adam Gaskins wrote:
> Long story short, I'm tired of doing things in such a hackish manner
> and want to write applications that are cross platform (I'd like to
> get our production dept on linux eventually) and truely object
> oriented. 

Adam, there is one notion here that I seriously dislike: you sound as if OOP
was a goal by itself for you. The point is that OOP is a tool, not a goal.
So, if it helps you do the things you really want, go ahead and use it.
Otherwise, just don't.

> The way I understand abstract classes is that I could have a class that
> has all my abstract methods such as 'init', 'getMeasurement',
> 'setPressure', etc... then I could use this common interface to to control
> my different pieces of hardware (after I write a library for each of
> them).
> 
> Is this a valid application for abstract classes? Or am I making life more
> complicated than it need be?

I think that the term is rather "abstract base class" (ABC,
a.k.a. "interface"). Note that in Python, where you don't have to use
prototypes or declaration, you often don't do that. Instead you use "duck
typing", i.e. you simply create different classes for the different
hardware and if all of them support 'init' and 'setPressure' instances are
interchangeable ("Liskov substitution principle", IIRC) without knowing
anything about each other.

> This makes me suspect I am making things more comlicated than they need to
> be. Could someone help me understand the proper way to impliment a set
> classes/methods to deal with several peices of similar and not so similar
> hardware?

Just write a class for each piece and adhere to a common interface and
you're done.

;)

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932