[thelist] Object Oriented Programming
david at gigawatt.com
Thu Jun 2 08:23:10 CDT 2011
Despite the oft-cited "pillars", the best explanation I've ever heard of
OO was (not coincidentally) the simplest. I think it was in the second
paragraph of a text book and it was the person/employee classes example
which you've probably seen as well, where the developer codes a Person
class to instantiate Person objects with attributes like first_name,
last_name, date_of_birth, etc. and methods general to all people like
age(), and can then reuse that code by inheriting from Person to create
an Employee class, by simply adding employee-specific attributes and
methods such as salary, department and, of course, terminate().
When future needs arise, such as the need to treat hourly and salaried
Employees differently, it is easy to create classes for those, by
further subclassing Employee. The HourlyEmployee class might only need
to contain one method that overrides, say, compute_paycheck()
implemented one way, while SalariedEmployee has the same method
implemented a different way.
To me the example illustrates the (alleged) benefits of OO Abstraction,
Encapsulation and Inheritance much better than the definitions of those
concepts do, and may do so in fewer syllables! Bu then, for me,
information is like code: less is more :-)
I will add that: I do wish I'd been taught in school that, while this
type of class inheritance was *designed* to ease development and
maintenance of code with oodles of opportunities for code reuse, in the
real world it seldom works out that way. In my experience, the class
stack itself tends to add more complexity, inefficiency, and plain old
bugs than the developer would have had to contended with, had she just
reused code in other (non-hierarchical) ways.
On 5/30/2011 6:17 PM, Kipper Timmins wrote:
> Hi all,
> I was wondering if any of you could offer your opinion with regards
> to what Object Oriented Programming actually is. Most developers
> will know how to use it, however it seems defining it is full of a
> lot of different opinions.
> My current take on the foundations of OO (before we move further
> into the topic) is the following:
> 4 key pillars/concepts
> Encapsulation : The ability to logically group functionality
> together into a meaningful concept (object) without defining access
> rights to the information.
> Abstraction : The ability to remove irrelevant information for the
> task at hand. i.e. a bank not holding records of your favourite
> colour on your account records because the information has no
> purpose there.
> Inheritance : The ability to generalise concepts to improve
> Polymorphism : Early binding – Same method name with different
> argument signature (usually within the same class). Late binding –
> Same method name, same argument signature, different functionality
> (between inherited classes)
> I would really appreciate any of you sharing your thoughts on this.
> Many thanks,
> Kevin Timmins
More information about the thelist