Encapsulation, inheritance and polymorphism

[Ethan Furman]

Lipska the Kat wrote:
> On 18/07/12 14:05, Steven D'Aprano wrote:
>> 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.

I must admit I have no idea how we went from discussing Single Exit 
functions to the One True Purpose of Object Oriented Programming;  are 
you saying that SE is one of the basic tenets of OO?


> 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.

And one of the many reasons I love Python is that it is so easy to write 
clear, readable, and sometimes concise code (nested list comps are still 
a challenge for me).

. . .

> 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.

Since *everything* in Python is an object, how can you /not/ call it an 
OO language?  Sure, you don't have to use everything as an object -- 
plain functions exist -- kinda ;)  Even functions live in some 
namespace: len() lives in __builtin__, any top level function lives in 
its module, etc.  Oh, and namespaces are objects.

It seems to me that Python is more about providing tools, and then 
staying out of your way.

That works for me.  Maybe it will work for you, too.

~Ethan~