Encapsulation, inheritance and polymorphism

[Lipska the Kat]

On 18/07/12 14:05, Steven D'Aprano wrote:
> On Wed, 18 Jul 2012 01:46:31 +0100, Andrew Cooper wrote:
>
>> Take for example a Linux system call handler.  The general form looks a
>> little like (substituting C for python style pseudocode)
>>
>> if not (you are permitted to do this):
>>      return -EPERM
>> if not (you've given me some valid data):
>>      return -EFAULT
>> if not (you've given me some sensible data):
>>      return -EINVAL
>> return actually_try_to_do_something_with(data)
>>I’m feeling a bit fed uI’m feeling a bit fed uI’m feeling a bit fed u
>> How would you program this sort of logic with a single return statement?
>
> That's not terribly hard.
>
> if not (you are permitted to do this):
>      result = -EPERM
> elif not (you've given me some valid data):
>      result = -EFAULT
> elif not (you've given me some sensible data):
>      result = -EINVAL
> else:
>      result = actually_try_to_do_something_with(data)
> return result
>
>
> A better example would involve loops. I used to hate programming in some
> versions of Pascal without a break statement: I needed a guard variable
> to decide whether or not to do anything in the loop!
>
> # pseudo-code
> for i in 1 to 100:
>      if not condition:
>          do_something_useful()
>
>
> Even with a break, why bother continuing through the body of the function
> when you already have the result? When your calculation is done, it's
> done, just return for goodness sake. You wouldn't write a search that
> keeps going after you've found the value that you want, out of some
> misplaced sense that you have to look at every value. Why write code with
> unnecessary guard values and temporary variables out of a misplaced sense
> that functions must only have one exit?

Object Oriented programming is all about encapsulating human concepts in 
a way that makes sense to human beings. Make no mistake, it is NEVER the 
case that a software system is written for any other reason than to 
serve human beings. OO is more than just the mechanics of writing code, 
it's a state of mind.

OO was 'invented' to address the many problems that beset increasingly 
complex software systems. The main problem was maintainability. 
Encapsulating a concept in a clear and concise way makes the code easier 
to understand. Sometimes this means writing code that is not 'optimal' 
for the machine. Good code should be readable as well as efficient but I 
contend that it is better to write something that is clear, concise and 
well encapsulated than always go for the 'meanest dog in the scrapyard' 
approach where a developer is determined to write unreadable code that 
shows how jolly clever he is. More often than not he is forced to admit 
six months down the line that he has no idea what his code does as he 
'forgot' to comment it.

I speak from bitter experience. This approach works for me. I have 
thousands of lines of code operating every day 'in the wild', everything 
from flight booking systems to real time odds arbitrage. Any developer 
who 'gets' OO can read and modify my code and I am very proud of this 
fact ... and I have never been forced to admit that I don't know what I 
wrote six months ago.

If you are writing embedded systems that must have a very limited memory 
footprint then there is a case for conciseness over readability but even 
then it has to be maintainable

Python looks like an interesting language and I will certainly spend 
time getting to know it but at the moment it seems to me that calling it 
an Object Oriented language is just plain misleading.

There, I've said it, trolls and flamers beware, I take no prisoners.

Lipska

-- 
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.