Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #26490 > unrolled thread

[newbie] Looking for a good introduction to object oriented programming with Python

Back to article view | Back to comp.lang.python

Contents

  [newbie] Looking for a good introduction to object oriented programming with Python Jean Dubois <jeandubois314@gmail.com> - 2012-08-04 08:49 -0700
    Re: [newbie] Looking for a good introduction to object oriented programming with Python shearichard@gmail.com - 2012-08-04 17:11 -0700
      Re: Looking for a good introduction to object oriented programming with Python Jean Dubois <jeandubois314@gmail.com> - 2012-08-05 05:38 -0700
      Re: Looking for a good introduction to object oriented programming with Python Jean Dubois <jeandubois314@gmail.com> - 2012-08-05 11:04 -0700
        Re: Looking for a good introduction to object oriented programming with Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-05 19:28 +0100
          Re: Looking for a good introduction to object oriented programming with Python Jean Dubois <jeandubois314@gmail.com> - 2012-08-06 07:56 -0700
            Re: Looking for a good introduction to object oriented programming with Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-06 17:17 +0100
              Re: Looking for a good introduction to object oriented programming with Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-07 01:12 +0000
                Re: Looking for a good introduction to object oriented programming with Python Ben Finney <ben+python@benfinney.id.au> - 2012-08-07 11:23 +1000
                Re: Looking for a good introduction to object oriented programming with Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-07 08:49 +0100
        Re: Looking for a good introduction to object oriented programming with Python Roy Smith <roy@panix.com> - 2012-08-05 14:39 -0400
        Re: Looking for a good introduction to object oriented programming with Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-05 19:53 +0100
        Re: Looking for a good introduction to object oriented programming with Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-08-05 18:45 -0400
          Re: Looking for a good introduction to object oriented programming with Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-05 22:51 +0000
            Re: Looking for a good introduction to object oriented programming with Python Roy Smith <roy@panix.com> - 2012-08-05 19:12 -0400
              Re: Looking for a good introduction to object oriented programming with Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-06 00:30 +0100
              Re: Looking for a good introduction to object oriented programming with Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-06 00:27 +0000
                Re: Looking for a good introduction to object oriented programming with Python Dan Sommers <dan@tombstonezero.net> - 2012-08-05 17:50 -0700
                Re: Looking for a good introduction to object oriented programming with Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-06 08:48 +0100
                Re: Looking for a good introduction to object oriented programming with Python DJC <djc@news.invalid> - 2012-08-06 11:20 +0200
              Re: Looking for a good introduction to object oriented programming with Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-08-05 20:57 -0400
            Re: Looking for a good introduction to object oriented programming with Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-06 08:43 +0100
              Re: Looking for a good introduction to object oriented programming with Python Roy Smith <roy@panix.com> - 2012-08-06 09:16 -0400
          Re: Looking for a good introduction to object oriented programming with Python Wolfgang Strobl <news4@mystrobl.de> - 2012-08-06 08:18 +0200
    Re: [newbie] Looking for a good introduction to object oriented programming with Python dncarac@gmail.com - 2012-08-05 11:59 -0700
    Re: [newbie] Looking for a good introduction to object oriented programming with Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-05 20:46 +0100
      Re: [newbie] Looking for a good introduction to object oriented programming with Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-05 23:11 +0100
        Re: [newbie] Looking for a good introduction to object oriented programming with Python Roy Smith <roy@panix.com> - 2012-08-05 18:53 -0400
      Re: [newbie] Looking for a good introduction to object oriented programming with Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-06 00:22 +0000
        Re: [newbie] Looking for a good introduction to object oriented programming with Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-06 02:02 +0100
        Re: [newbie] Looking for a good introduction to object oriented programming with Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-08-05 21:14 -0400
          Re: [newbie] Looking for a good introduction to object oriented programming with Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-06 06:08 +0000
            Re: [newbie] Looking for a good introduction to object oriented programming with Python Paul Rubin <no.email@nospam.invalid> - 2012-08-06 00:25 -0700
        Re: Looking for a good introduction to object oriented programming with Python alex23 <wuwei23@gmail.com> - 2012-08-05 19:44 -0700
          Re: Looking for a good introduction to object oriented programming with Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-07 19:02 +0000
            Re: Looking for a good introduction to object oriented programming with Python Terry Reedy <tjreedy@udel.edu> - 2012-08-07 18:37 -0400
            Re: Looking for a good introduction to object oriented programming with Python alex23 <wuwei23@gmail.com> - 2012-08-07 17:07 -0700
              Re: Looking for a good introduction to object oriented programming with Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-08 02:14 +0000
                Re: Looking for a good introduction to object oriented programming with Python Chris Angelico <rosuav@gmail.com> - 2012-08-08 12:24 +1000
                Re: Looking for a good introduction to object oriented programming with Python alex23 <wuwei23@gmail.com> - 2012-08-07 20:20 -0700
        Re: [newbie] Looking for a good introduction to object oriented programming with Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-06 09:55 +0100
          Re: [newbie] Looking for a good introduction to object oriented programming with Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-06 10:24 +0100
            Re: [newbie] Looking for a good introduction to object oriented programming with Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-07 05:35 +0000
              Re: [newbie] Looking for a good introduction to object oriented programming with Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-07 09:16 +0100
          Re: [newbie] Looking for a good introduction to object oriented programming with Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-07 05:19 +0000
            Re: [newbie] Looking for a good introduction to object oriented programming with Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-07 10:19 +0100
              Re: [newbie] Looking for a good introduction to object oriented programming with Python Ben Finney <ben+python@benfinney.id.au> - 2012-08-07 23:12 +1000
                Re: [newbie] Looking for a good introduction to object oriented programming with Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-07 15:13 +0100
              Re: [newbie] Looking for a good introduction to object oriented programming with Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-07 14:14 +0000
                Re: [newbie] Looking for a good introduction to object oriented programming with Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-07 15:34 +0100
                  Re: Looking for a good introduction to object oriented programming with Python rusi <rustompmody@gmail.com> - 2012-08-07 08:04 -0700
                    Re: Looking for a good introduction to object oriented programming with Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-07 18:00 +0100
                      Re: Looking for a good introduction to object oriented programming with Python Chris Angelico <rosuav@gmail.com> - 2012-08-08 07:57 +1000
                        Re: Looking for a good introduction to object oriented programming with Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-08 10:51 +0100
                          Re: Looking for a good introduction to object oriented programming with Python rusi <rustompmody@gmail.com> - 2012-08-08 09:27 -0700
                            Re: Looking for a good introduction to object oriented programming with Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-08 17:28 +0000
                              Re: Looking for a good introduction to object oriented programming with Python Chris Angelico <rosuav@gmail.com> - 2012-08-09 11:32 +1000
                          Re: Looking for a good introduction to object oriented programming with Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-08-08 12:42 -0400
                            Re: Looking for a good introduction to object oriented programming with Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-08 20:31 +0100
                              Re: Looking for a good introduction to object oriented programming with Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-08-08 22:59 -0400
                                Re: Looking for a good introduction to object oriented programming with Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-09 08:29 +0100
                              Geneology Packages -- WAS: Looking for a good introduction to object oriented programming with Python Simon Cropper <simoncropper@fossworkflowguides.com> - 2012-08-09 13:51 +1000
                                Re: Geneology Packages Ben Finney <ben+python@benfinney.id.au> - 2012-08-09 14:00 +1000
      Re: Looking for a good introduction to object oriented programming with Python rusi <rustompmody@gmail.com> - 2012-08-06 05:19 -0700
        Re: Looking for a good introduction to object oriented programming with Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-06 15:27 +0100
          Re: Looking for a good introduction to object oriented programming with Python rusi <rustompmody@gmail.com> - 2012-08-06 09:34 -0700
            Re: Looking for a good introduction to object oriented programming with Python Chris Angelico <rosuav@gmail.com> - 2012-08-07 08:44 +1000
        OT probably but still relevant (was Re: Looking for a good introduction to object oriented programming with Python) lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-06 17:23 +0100
          Re: OT probably but still relevant (was Re: Looking for a good introduction to object oriented programming with Python) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-07 09:44 +0000
            Re: OT probably but still relevant (was Re: Looking for a good introduction to object oriented programming with Python) lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-07 11:23 +0100

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#26615

On 06/08/12 01:22, Steven D'Aprano wrote:
> On Sun, 05 Aug 2012 20:46:23 +0100, lipska the kat wrote:
>
>> <rant>
>> Object Oriented programming is a mindset, a way of looking at that
>> particular part of our world that you are trying to encapsulate in
>> computer language. The language you use is (should be) irrelevant.
>
> That depends on how you define OOP, and in particular, which aspects of
> OOP your language supports.

The clue is in the name 'Object Oriented' ... anything else is (or 
should be) implementation detail.

[large snip]

>
> In particularly, terminology varies -- I personally despise with the heat
> of a thousand suns the terms "instance variable" and "class variable" for
> attributes or members.

This is an implementation detail and describes the difference between 
certain types of attributes. A class variable is static and can be 
accessed without instantiation an instance variable is accessed via an 
instance ... again the clue is in the name.

> Since a "string variable" is a variable holding a
> string, and a "float variable" is a variable holding a float, an instance
> variable should be a variable holding an instance, and a class variable
> should be a variable holding a class.

Class variable and instance variable are higher level abstractions.

>> The ONLY concept that you should never try to encapsulate is/are human
>> beings or their aliases.

snip

> Is this some sort of mystical "humans aren't objects, they're SPECIAL!!!"
> rubbish? Because it sure sounds like it.
>
> Can you give some non-religious reasons why you should not implement
> human beings or aliases as objects?

You have answered your own question.... I would be glad to debate my 
assertion at length with you however the 'moderators' are listening.

> If not, let me just say that I reject your prohibition and leave it at
> that.
>
>
>> Actually it should really be called Class Oriented programming as
>> classes are the units of encapsulation.
>
> Incorrect. You don't even need classes to have objects. You can have
> class-based OOP, and prototype-based OOP, as in Javascript, Actionscript,
> Io, and the language which invented the term, Self.
 >
> http://en.wikipedia.org/wiki/Prototype-based_programming

Interesting article, I withdraw my 'classed based' assertion however the 
concept of a unit of encapsulation still exists. Where unit of 
encapsulation is different from a unit of function or method.

>> I really don't think python is a
>> good language to learn OO programming, the problem is that Python
>> doesn't enforce OO so you are never going to learn what is 'OO' and what
>> isn't.
>
> I think that's exactly why Python *is* a good language to learn OOP,
> because you can be productive even while learning. You can start off by
> just adding a little bit of OOP syntax to your programs:

Well I'm afraid I can't agree with this. OO is a state if mind (again) 
you can't successfully be a 'little bit OO' IMHO

> response = raw_input("What do you want to do? ")
> response = response.lower()  # Look ma, I'm using OOP!

Infantile but funny

snip

>> I've already managed to write meaningful code but I haven't
>> invented a single class yet.
>
> And why do you think this is a problem?

A problem? I wasn't aware that I'd stated it was a problem it just 
underlines my belief that Python, however useful it is, is not the ideal 
language to learn about Object Oriented software development.

> Classes are one possible solution to problems that actually matter. What
> matters is the solution, not the mechanism of the solution. "Writing
> classes" is just a means to an end (the solution), not the end itself.

I couldn't agree more, the point is that they are a good solution. I 
learned very early on that there is more than one way to skin a cat. I 
have never said that Python is a bad language, I LIKE Python. I 
certainly prefer it to Java for on the fly development and it sure is 
more fun at times.

>> There is a book you could try, it's a bit dry and I read it when I can't
>> sleep, about 30 mins usually does it :-) It's called Design Patterns

snippety snip

>
> In my not-so-humble opinion, the popularity of Design Patterns has a lot
> to do with the fact that they are so abstract and jargon-ridden that they
> have become a badge of membership into an elite.

Hmm, I feel a rant coming on about elitism ...

snip

and a Facade is just an interface layer.

Well as you seem to be so concerned with terminology I'd have to 
disagree with you here. An interface (in computing) has any number of 
meanings, hardware interfaces, software interfaces the HCI etc etc. In 
some languages an interface is a non functional unit of compilation that 
describes the methods an implementing class must provide. A facade on 
the other hand aggregates a number of fine grained operations that often 
implement the business logic of an application into coarser grained 
methods that can be called further up the implementation stack.
More importantly, what goes on behind a facade can be completely changed 
without affecting anything that uses the facade thereby enhancing 
maintainability. (I'm trying really hard not to use buzzwords here).

I could go on but there seems little point.


>> Learn Python by all means, the interactive mode is particularly fun,just
>> try and get a good idea of what OO is all about before you start.
>
> As far as I am concerned, any language without an interactive interpreter
> is incomplete.

Well possibly.

lipska

-- 
Lipska the Kat: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#26617

On 06/08/12 09:55, lipska the kat wrote:
> On 06/08/12 01:22, Steven D'Aprano wrote:
>> On Sun, 05 Aug 2012 20:46:23 +0100, lipska the kat wrote:
>>
>>> <rant>

snip

> Well as you seem to be so concerned with terminology I'd have to
> disagree with you here. An interface (in computing) has any number of
> meanings, hardware interfaces, software interfaces the HCI etc etc. In
> some languages an interface is a non functional unit of compilation that
> describes the methods an implementing class must provide. A facade on
> the other hand aggregates a number of fine grained operations that often
> implement the business logic of an application into coarser grained
> methods that can be called further up the implementation stack.
> More importantly, what goes on behind a facade can be completely changed
> without affecting anything that uses the facade thereby enhancing
> maintainability. (I'm trying really hard not to use buzzwords here).

er, the point I was trying to make is that when you say 'interface' it 
could mean so many things. If you say 'facade' everyone knows exactly 
what you are talking about. And that is EXACTLY the point.

lipska

-- 
Lipska the Kat: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#26683

On Mon, 06 Aug 2012 10:24:10 +0100, lipska the kat wrote:

> er, the point I was trying to make is that when you say 'interface' it
> could mean so many things. If you say 'facade' everyone knows exactly
> what you are talking about. And that is EXACTLY the point.

The whole point of design patterns is to avoid getting stuck in 
incidental implementation details of a particular library or class and 
look for higher-level design patterns.

The same applies to facade -- it's just a special case of the interface 
pattern. Why get stuck in incidental implementation details of the 
particular *kind* of interface layer you need?

Obviously the person writing the interface/facade/adaptor/whatever needs 
to understand the implementation details. But the people using the 
interface don't.

Why waste brain CPUs trying to decide whether a particular interface is a 
facade, an adaptor, a bridge, a proxy, ... ? Especially since in real-
life code, any such interface is going to include elements of all of the 
above. Take this example from Wikipedia's article on Facade pattern:

=========  ========
Pattern    Intent
=========  ========
Adapter    Converts one interface to another so that it matches 
           what the client is expecting
Decorator  Adds responsibility to the interface without altering it
Facade     Provides a simplified interface
=========  ========

It's rare that the intent is as pure as that. Normally it will be:

"Simplify the interface, oh and also change the API of these three 
methods to match this other library, and add a couple of helper methods, 
and while you're at it, this method has a bug that upstream refuses to 
patch, do something about that."

So is that a facade or an adaptor, or something else?




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#26692

On 07/08/12 06:35, Steven D'Aprano wrote:
> On Mon, 06 Aug 2012 10:24:10 +0100, lipska the kat wrote:
>
>> er, the point I was trying to make is that when you say 'interface' it
>> could mean so many things. If you say 'facade' everyone knows exactly
>> what you are talking about. And that is EXACTLY the point.
>
> The whole point of design patterns is to avoid getting stuck in
> incidental implementation details of a particular library or class and
> look for higher-level design patterns.
>
> The same applies to facade -- it's just a special case of the interface
> pattern.

So you AGREE with me, fantastic, what are we arguing about then (it's 
great fun though isn't it) facade is a SPECIAL case of interface.
You seem to be missing this point.

I may not be as smart or experienced as you but in my fairly wide 
experience of software projects of all sizes the biggest problem is one 
of communication. Design patterns, in my experience help with communication.

I have designed and implemented many facades, I have also designed many 
interfaces. I do not think Java is the be all and end all of programming 
languages but it has paid off my mortgage and provided me with a good 
living. Python interests me because it is different. As far as I can see 
if I'm talking with a Pythonista or a Java developer or a hardware 
engineer (possibly) or a C++ guru or a university lecturer or an Eiffel 
developer and I say 'interface' they will all visualise something 
slightly different, if I say 'facade' they will all (hopefully) know 
EXACTLY what I am talking about.

lipska

-- 
Lipska the Kat: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#26682

On Mon, 06 Aug 2012 09:55:24 +0100, lipska the kat wrote:

> On 06/08/12 01:22, Steven D'Aprano wrote:
>> On Sun, 05 Aug 2012 20:46:23 +0100, lipska the kat wrote:
>>
>>> <rant>
>>> Object Oriented programming is a mindset, a way of looking at that
>>> particular part of our world that you are trying to encapsulate in
>>> computer language. The language you use is (should be) irrelevant.
>>
>> That depends on how you define OOP, and in particular, which aspects of
>> OOP your language supports.
> 
> The clue is in the name 'Object Oriented' ... anything else is (or
> should be) implementation detail.

So your argument is that any programming which is "oriented" (meaning 
what?) towards "objects" (which are...?) is OOP, and everything else is 
"implementation detail".

Well now I'm enlightened. That certainly clears that up for me.


> [large snip]
> 
> 
>> In particularly, terminology varies -- I personally despise with the
>> heat of a thousand suns the terms "instance variable" and "class
>> variable" for attributes or members.
> 
> This is an implementation detail and describes the difference between
> certain types of attributes. 

Not everything is an "implementation detail". The difference between a so-
called "class variable" (what Python calls a class attribute) and a 
"instance variable" (instance attribute) is not an implementation detail, 
it is a difference in semantics and function.


As you go on to explain:

> A class variable is static and can be
> accessed without instantiation an instance variable is accessed via an
> instance

which are semantic differences, differences in meaning and function. 


>> Since a "string variable" is a variable holding a string, and a "float
>> variable" is a variable holding a float, an instance variable should be
>> a variable holding an instance, and a class variable should be a
>> variable holding a class.
> 
> Class variable and instance variable are higher level abstractions.

Of what? Of variables? "Class variables are an abstraction of 
variables"... even if true, that's a crappy way to speak. Why should you 
use the same word for higher level abstractions that is already used for 
lower level abstractions?

I understand that in Java, classes are not first-class (no pun intended) 
objects. You can't say:

x = MyClass

and hence talk about x being a variable that holds a class, hence "class 
variable". But that's no excuse to overload the term "variable" for 
something where there are at least three good names:

attribute
member
property

none of which clash with the normal use of the word "variable".

(Smalltalk gets a pass here -- it was very early days in OOP, and the 
terminology wasn't available. But by the time that Java came along, there 
was no longer any good justification for overloading a perfectly good 
word like variable to mean something different.)

Simply put, the choice of terminology is crap -- attributes of a class/
instance have subtle but real semantic differences from local/global 
variables. Attributes belong to an entity (an instance, or a class); 
variables do not.

If they were just implementation differences ("local variables live on 
the stack, attributes live in the instance struct") it wouldn't matter. 
But the semantics are different, and the "instance variable" terminology 
is misleading.

But what *really* gets me is not the existence of poor terminology. I 
couldn't care less what terminology Java programmers use among 
themselves. What gets me is that the ubiquity of them means that 
substandard terminology spreads into other languages, like dryrot.


>>> The ONLY concept that you should never try to encapsulate is/are human
>>> beings or their aliases.
> 
> snip
> 
>> Is this some sort of mystical "humans aren't objects, they're
>> SPECIAL!!!" rubbish? Because it sure sounds like it.
>>
>> Can you give some non-religious reasons why you should not implement
>> human beings or aliases as objects?
> 
> You have answered your own question.... 

I'm afraid I have no idea what you mean here. Do you mean that you 
*don't* have any non-religious reasons for avoiding Person and User 
objects?

How do you feel about Person and User structs, records or fields?


> I would be glad to debate my
> assertion at length with you however the 'moderators' are listening.

There are no moderators on this list. People are free to try using peer 
pressure to discourage off-topic discussion, but they can't enforce it.



>>> I've already managed to write meaningful code but I haven't invented a
>>> single class yet.
>>
>> And why do you think this is a problem?
> 
> A problem? I wasn't aware that I'd stated it was a problem it just

You said "BUT [emphasis added] I haven't invented a single class yet", 
which implies that this is a bad thing in contrast to the good thing that 
you became productive in Python very quickly.


> underlines my belief that Python, however useful it is, is not the ideal
> language to learn about Object Oriented software development.

I guess that depends on whether you learn best from a gentle learning 
curve with incremental gains in knowledge, or by immersing yourself in an 
entirely unfamiliar environment with a steep learning curve to "sink or 
swim".


> > and a Facade is just an interface layer.
> 
> Well as you seem to be so concerned with terminology I'd have to
> disagree with you here. An interface (in computing) has any number of
> meanings, hardware interfaces, software interfaces the HCI etc etc.

All of which have in common that they are a layer (hardware, software, or 
something else) between two entities (objects, hardware components, 
people, substances, environments, etc.).

Which is exactly what a facade is.


> In
> some languages an interface is a non functional unit of compilation that
> describes the methods an implementing class must provide.

And even in those languages (Pascal, for example) an interface is also an 
interface, not just an instruction to the compiler stating what interface 
elements are required.


> A facade on
> the other hand aggregates a number of fine grained operations that often
> implement the business logic of an application into coarser grained
> methods that can be called further up the implementation stack.

Which makes it an interface to those fine-grained operations.

Just because the word "interface" is a reserved word in Pascal with a 
specific technical meaning and "facade" is not does not mean that the 
general term "interface" does not also apply to facades.


> More
> importantly, what goes on behind a facade can be completely changed
> without affecting anything that uses the facade thereby enhancing
> maintainability. (I'm trying really hard not to use buzzwords here).

Which is exactly the point of an interface. You can change the 
implementation behind the interface (the fine-grained operations) without 
needing to change the higher-level facade operations.

I'm not arguing against the usefulness of "facades". I am questioning why 
they need to be singled out as a named "design pattern" instead of just 
one mere example of a more general, less specific technique of building 
an interface to another system.

You have a complicated, fine-grained system which is difficult to use? 
Write an interface, then talk to the interface.

You have a simple, but buggy, system, and need a layer of code to work 
around the bugs? Write an interface, then talk to the interface.

You have a system which changes rapidly? Write an interface, and talk to 
the interface.

There's no need to teach multiple different design patterns in isolation: 
"facade", "adaptor", "bridge", "connector", "proxy"... They're all the 
same pattern. If you learn the general idea of an interface, the rest are 
obvious. Or at least more clear and less jargon.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#26695

On 07/08/12 06:19, Steven D'Aprano wrote:
> On Mon, 06 Aug 2012 09:55:24 +0100, lipska the kat wrote:
>
>> On 06/08/12 01:22, Steven D'Aprano wrote:
>>> On Sun, 05 Aug 2012 20:46:23 +0100, lipska the kat wrote:
>>>

[snip]

>>
>> The clue is in the name 'Object Oriented' ... anything else is (or
>> should be) implementation detail.
>
> So your argument is that any programming which is "oriented" (meaning
> what?) towards "objects" (which are...?) is OOP, and everything else is
> "implementation detail".
>
> Well now I'm enlightened. That certainly clears that up for me.

Glad I could help :-)

[snip]

>
> As you go on to explain:
>
>> A class variable is static and can be
>> accessed without instantiation an instance variable is accessed via an
>> instance
>
> which are semantic differences, differences in meaning and function.

Yes but when we TALK about these things a String variable is a String 
variable is a String variable. The words 'Class variable' and 'instance 
variable' are 'abstractions'. It saves us saying,

'this is a variable that can only be accessed from an instance and may 
hold values of the type Integer or String or Weak Reference ... (and so 
on ad nauseum) ... but only of one type unless you count runtime 
polymorphism in which case the runtime type may be different from the 
compile time type ... etc etc'

or 'this is a variable that can be accessed without instantiating a 
class (see above)'

If you don't like the term abstraction then perhaps we can agree on 
something else.

>>> Since a "string variable" is a variable holding a string, and a "float
>>> variable" is a variable holding a float, an instance variable should be
>>> a variable holding an instance, and a class variable should be a
>>> variable holding a class.

See above

>> Class variable and instance variable are higher level abstractions.
>
> Of what? Of variables?

Exactly, now you're getting the hang of it

[snip]

> Simply put, the choice of terminology is crap --

possibly but it's the best we've got.

> But what *really* gets me is not the existence of poor terminology. I
> couldn't care less what terminology Java programmers use among
> themselves.

I'd be most grateful if you could park the whole 'This person is a 'Java 
developer so must be a moron thing' it's getting a bit wearing.
As I said in a previous post, Java has indeed been good to me but my 
brain IS capable of dealing with more than one language.

> What gets me is that the ubiquity of them means that
> substandard terminology spreads into other languages, like dryrot.

Yea well welcome to the world of spin, if you can't fight it then learn 
to roll with it.

>>>> The ONLY concept that you should never try to encapsulate is/are human
>>>> beings or their aliases.
>>
>> snip
>>
>>> Is this some sort of mystical "humans aren't objects, they're
>>> SPECIAL!!!" rubbish? Because it sure sounds like it.

[snip]

Well now this is a personal thing born of bitter experience. In my 
experience, when you have an entity called 'Person' or some such in your 
Class model it soon becomes what we 'in the trade' call a 'God Object' 
The name should be self explanatory but hold tight, here comes some more 
jargon.

Objects can have a 'has a' relationship with other Objects or an 'is a' 
relationship with other objects

The 'has a' relationship means that an Object 'owns' another object, the 
'is a' relationship means that an Object 'is of a particular type'
Of course in an 'Object Oriented' language such as Java an Object 
reference can have a different type at runtime than it does at compile 
time. In Python too.

Anyway, this Person thing soon ends up with a 'has a' relationship with 
everything in sight. a Person 'has a[n]' Address, a Person 'has a[n]' 
account, a Person 'has a' Doughnut etc etc etc

Also, inevitably a Person 'is a' Customer, a Person 'is a' Contact, a 
Person 'is a' security risk, well you get the idea.

Of course this is a problem with the actual design process itself and 
yes, the identification of the 'nouns in the language of the domain' is 
an important part of the process. Sorry, but it just works when it's 
done properly, I know it works as I used this technique to turn around 
this 'Person as God' design from a failing money pit into a working 
system that delivered (almost) on time. The very first thing I did was 
to exorcise Person from the design.

>>>> I've already managed to write meaningful code but I haven't invented a
>>>> single class yet.
>>>
>>> And why do you think this is a problem?
>>
>> A problem? I wasn't ware that I'd stated it was a problem it just
>
> You said "BUT [emphasis added] I haven't invented a single class yet",
> which implies that this is a bad thing

[snip]

No it implies that I noticed it was possible to do meaningful work in 
Python without writing a class.


Well this HAS been fun, I look forward to your reply but at the moment I 
have to go and pick some runner beans as it's been a fantastic year for 
beans and the freezer awaits.

lipska

-- 
Lipska the Kat: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#26702

lipska the kat <lipskathekat@yahoo.co.uk> writes:

> >>>> The ONLY concept that you should never try to encapsulate is/are
> >>>> human beings or their aliases.

You stated this in absolute, dogmatic terms. I thought at first you were
being hyperbolic for effect, but the situation that you present to
support this dogma is one where I can't see anyone rationally concluding
the dogma applies.

> Well now this is a personal thing born of bitter experience. In my
> experience, when you have an entity called 'Person' or some such in
> your Class model it soon becomes what we 'in the trade' call a 'God
> Object' The name should be self explanatory but hold tight, here comes
> some more jargon.

God objects are a code smell (another term of art, meaning a symptom in
the code that tends to indicate poor design or some other fundamental
flaw). But what you're describing below doesn't fit.

> Objects can have a 'has a' relationship with other Objects or an 'is a'
> relationship with other objects
>
> The 'has a' relationship means that an Object 'owns' another object,
> the is a' relationship means that an Object 'is of a particular type'
> Of course in an 'Object Oriented' language such as Java an Object
> reference can have a different type at runtime than it does at compile
> time. In Python too.
>
> Anyway, this Person thing soon ends up with a 'has a' relationship
> with everything in sight. a Person 'has a[n]' Address, a Person 'has
> a[n]' account, a Person 'has a' Doughnut etc etc etc
>
> Also, inevitably a Person 'is a' Customer, a Person 'is a' Contact, a
> Person 'is a' security risk, well you get the idea.

This accurately reflects the reality that “person” is a real-world
entity very frequently involved in just about anything a typical system
needs to model.

> Of course this is a problem with the actual design process itself

What problem? If the real-world entity really exists and the “has-a” and
“is-a” relationships really exist, then it's *good* design to model
whatever ones of those are significant to the operation of the program.

Indeed, it would be *bad* design to avoid modelling the real world
merely because of dogma against modelling persons and their
relationships to other entities.

If there were entities or relationships that were needlessly cumbersome
– if indeed the object was trying to encapsulate the majority of the
whole world in itself – then those should be removed from the object,
and perhaps even from the design.

But that's not what you describe. A Person entity in inheritance or
composition relationships with other classes and objects is not a god
object, since it is sensibly delegating specific jobs to places other
than itself. That's very good, modular design.

And when the real domain to be modelled almost certainly has people as a
central entity in complex interactions, removing Person from the design
entirely is poor work grounded in irrationality.

-- 
 \       “I am amazed, O Wall, that you have not collapsed and fallen, |
  `\            since you must bear the tedious stupidities of so many |
_o__)                  scrawlers.” —anonymous graffiti, Pompeii, 79 CE |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#26711

On 07/08/12 14:12, Ben Finney wrote:
> lipska the kat<lipskathekat@yahoo.co.uk>  writes:
>
>>>>>> The ONLY concept that you should never try to encapsulate is/are
>>>>>> human beings or their aliases.
>
> You stated this in absolute, dogmatic terms. I thought at first you were
> being hyperbolic for effect, but the situation that you present to
> support this dogma is one where I can't see anyone rationally concluding
> the dogma applies.

Ah, you mean you don't agree.

>> Well now this is a personal thing born of bitter experience.

[snip]

>> Also, inevitably a Person 'is a' Customer, a Person 'is a' Contact, a
>> Person 'is a' security risk, well you get the idea.
>
> This accurately reflects the reality that “person” is a real-world
> entity very frequently involved in just about anything a typical system
> needs to model.

No, you are wrong. Having a Person class is profoundly and fundamentally 
wrong. If we follow this argument then every system ever modelled would 
have a Person at it's heart.

I think you are missing the point here. You say.

 > This accurately reflects the reality that “person” is a real-world
 > entity very frequently involved in just about anything a typical stem
 > needs to model. that a "person" is a real-world entity very >frequently

Have asserted that you are profoundly wrong I now have to say that I 
couldn't agree more BUT with the crucial modifier that a person is an 
"actor" I don't care if you like or dislike the terminology, you get the 
general idea. An actor exists outside the system. Having a Person in the 
Class model tends to blur the boundaries between system and users. I 
know it does, I've seen it happen so many times.

It's all about how we think about a system in the early stages of design
The moment we introduce a Person (or alias for a Person) we confuse our 
thinking, are we thinking about Person as actor or are we thinking about 
Person as entity in our system. This is not some nebulous flight of 
fancy, this is born of real world, stand at the whiteboard and thrash 
out a design experience. I have been ridiculed before, strangely enough, 
once the Person has been expunged from the system mind things go a whole 
lot more smoothly.

>> Of course this is a problem with the actual design process itself
>
> What problem? If the real-world entity really exists and the “has-a” and
> “is-a” relationships really exist, then it's *good* design to model
> whatever ones of those are significant to the operation of the program.
>
> Indeed, it would be *bad* design to avoid modelling the real world
> merely because of dogma against modelling persons and their
> relationships to other entities.

Dogma is an emotive word that you are using to belittle the idea. That's 
fine, you asked me to explain myself and I have done so.

[snip]

> And when the real domain to be modelled almost certainly has people as a
> central entity in complex interactions, removing Person from the design
> entirely is poor work grounded in irrationality.

Well I say it's sound judgment grounded in experience and most if not 
all my employers seem to agree. I have thousands of lines of code 'in 
the wild' operating without fault day after week after year and not one 
single line refers to, implies or otherwise represents a "Person" in any 
way whatsoever.

Just one tiny point, I NEVER have to 'remove' a Person from my designs 
as they never get through the door in the first place.

The only time I have ever had to agree that a "Person" belongs in a 
computer is when I saw Tron.

lipska

-- 
Lipska the Kat: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#26712

On Tue, 07 Aug 2012 10:19:31 +0100, lipska the kat wrote:

> On 07/08/12 06:19, Steven D'Aprano wrote:
[...]
>> But what *really* gets me is not the existence of poor terminology. I
>> couldn't care less what terminology Java programmers use among
>> themselves.
> 
> I'd be most grateful if you could park the whole 'This person is a 'Java
> developer so must be a moron thing' it's getting a bit wearing.

Lipska, it's not always about you.

I've been hanging around this forum for, oh, at least six years now. 
Trust me, you're not the first Java developer brave enough to poke their 
head up :)

Java coders who come here tend to talk about "instance variables". C++ 
coders tend to talk about "members". Haskell people don't tend to talk 
much about objects at all. And PHP coders tend to talk about how they saw 
Spot run.

(I kid. Sorry PHP coders, I couldn't resist.)

It's not about being a moron. Anyone new to a language is going to carry 
across preconceptions from their previous language, and use the 
terminology they're used to. I've seen more than one Lisper assume that 
Python lists are linked lists and wonder how to call car and cdr, and 
nobody is accusing Lispers of being dumb. And I'm not going to even try 
to describe the misconceptions I had learning Python, coming from a 
background of Pascal, RPN and Hypertalk -- the first two languages 
weren't OOP, and Hypertalk's OOP model was *very* different from Python's.

Don't think that every time I mention Java it's a dig at you.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#26714

On 07/08/12 15:14, Steven D'Aprano wrote:
> On Tue, 07 Aug 2012 10:19:31 +0100, lipska the kat wrote:
>
>> On 07/08/12 06:19, Steven D'Aprano wrote:
> [...]
>>> But what *really* gets me is not the existence of poor terminology. I
>>> couldn't care less what terminology Java programmers use among
>>> themselves.
>>
>> I'd be most grateful if you could park the whole 'This person is a 'Java
>> developer so must be a moron thing' it's getting a bit wearing.
>
> Lipska, it's not always about you.

Never thought so for a moment, good to know you can be reasonable as 
well as misguided ;-)

lipska

-- 
Lipska the Kat: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#26718 — Re: Looking for a good introduction to object oriented programming with Python

On Aug 7, 7:34 pm, lipska the kat <lipskathe...@yahoo.co.uk> wrote:
>
> Never thought so for a moment, good to know you can be reasonable as
> well as misguided ;-)

Well Lipska I must say that I find something resonant about the 'no-
person' thing, though I am not sure what.

You also said something about 'user' being more acceptable.  From a
different (opposite?) angle Dijkstra seems to be saying the same
thing, here:
http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD618.html

Wonder what you make of it?

[toc] | [prev] | [next] | [standalone]

#26729 — Re: Looking for a good introduction to object oriented programming with Python

On 07/08/12 16:04, rusi wrote:
> On Aug 7, 7:34 pm, lipska the kat<lipskathe...@yahoo.co.uk>  wrote:
>>
>> Never thought so for a moment, good to know you can be reasonable as
>> well as misguided ;-)
>
> Well Lipska I must say that I find something resonant about the 'no-
> person' thing, though I am not sure what.
>
> You also said something about 'user' being more acceptable.  From a
> different (opposite?) angle Dijkstra seems to be saying the same
> thing, here:
> http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD618.html
>
> Wonder what you make of it?

This text is often quoted in discussions I have had on this subject on 
Usenet and other forums.

Professor Dijkstra is far more eloquent that I could ever hope to be.
I don't profess to be an academic nor do I have the rhetorical ability 
of some of the people in this group, having said that I think the 
professor may be equally as indignant about the word elbowing it's way 
into his native language as he is about the way the word is used in the 
computing industry but here is my rationale for thinking that there is a 
case for a class called User.

A 'User' of a computer system can be another computer system, equally a 
Person can be a user of a computer system. Denying the use of the 
concept User may inhibit certain thought processes. At the very least 
'User' can be used as a place holder indicating that we are aware that 
we are dealing with something that will eventually need to communicate 
outside of it's boundaries. Abstracting away an entire 'class' of 
concepts into a single 4 letter word can be wonderfully liberating. When 
you tell a group of struggling software developers to ignore external 
influences but be aware that there is this thing called 'User' that will 
eventually have to communicate with the thing we are inventing they 
breath a huge sigh of relief and start to focus on what is important, 
namely the business logic of the entity that is employing them. Once a 
basic design has been thrashed out we can start thinking about how 
external systems (and 'People') interface with the representation of the 
business we have invented. We then iterate and re-iterate as external 
influences invariably affect our design, however the core design remains 
and acts as an anchor to our thinking. In the past, when we have got 
confused and frustrated with these external influences we have gone back 
to our original design to ground ourselves again.

Having said all this it has never been my experience that we actually 
end up with a User Class in any design I have been involved in. 
Eventually we just find ourselves in a place where the 'User' has 
transmogrified into a collection of facades and interfaces that present 
a view of the system to the outside world.

I'm still undecided over the whole 'User' thing actually, I don't think 
I can see a time when I will have a User Class in one of my systems but 
as I don't want to get 'dogmatic' about this I remain open to any ideas 
that might include such a Class.

Person however is an entirely different matter and will never appear in 
my systems in any way shape or form ...this is not dogma, it's a fact.

lipska

-- 
Lipska the Kat: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#26740 — Re: Looking for a good introduction to object oriented programming with Python

On Wed, Aug 8, 2012 at 3:00 AM, lipska the kat <lipskathekat@yahoo.co.uk> wrote:
> I'm still undecided over the whole 'User' thing actually, I don't think I
> can see a time when I will have a User Class in one of my systems but as I
> don't want to get 'dogmatic' about this I remain open to any ideas that
> might include such a Class.
>
> Person however is an entirely different matter and will never appear in my
> systems in any way shape or form ...this is not dogma, it's a fact.

This makes little sense to my mind. If you can have a "class User:",
why can you not have a "class Person:" ?

Now, that said, I can't remember the last time I actually had a class
called "Person" in anything other than a demo. But that's merely
because of terminology; I've had classes representing human beings,
but named according to what part these people play in the system
(Customer, Employee (haven't done that one, actually, but there's no
reason not to), User, Etcetera, Etcetera, Etcetera... is an Etceterer
someone who practices Etcetery?), and these classes are as
well-defined as any others.

Perhaps it would help to think about these things not as turning a
person into an entity, but as "retaining the data related to a
Person". The Person class details what data you store about a person,
a Person instance stores that data about one particular person. This
works for other things; a QueueEntry isn't actually standing in queue,
but it holds the data you store about the thing that is.

Or maybe that doesn't help, in which case just ignore it.

ChrisA

[toc] | [prev] | [next] | [standalone]

#26754 — Re: Looking for a good introduction to object oriented programming with Python

On 07/08/12 22:57, Chris Angelico wrote:
> On Wed, Aug 8, 2012 at 3:00 AM, lipska the kat<lipskathekat@yahoo.co.uk>  wrote:
>> I'm still undecided over the whole 'User' thing actually,

[snip]

> This makes little sense to my mind. If you can have a "class User:",
> why can you not have a "class Person:" ?

User and Person are entirely different concepts, surely you can see that.
A User can be anything that interacts with our system, not necessarily a 
Person.

> Now, that said, I can't remember the last time I actually had a class
> called "Person" in anything other than a demo. But that's merely
> because of terminology; I've had classes representing human beings,
> but named according to what part these people play in the system
> (Customer, Employee (haven't done that one, actually, but there's no
> reason not to),

Customer is a 'business Class'. Businesses without Customers don't 
exist, at least I don't know of any. A Customer however can be many 
things, Organisations can be customers of other organisations. Is a 
LampPost a Customer of the Electricity company that supplies it with 
power ? possibly, it depends on your business model. A LampPost sure 
isn't a Person though. Limiting the Customer class to representing human 
beings is exactly that, limiting.

[snip]

> The Person class details what data you store about a person,
> a Person instance stores that data about one particular person. This
> works for other things;
> a QueueEntry isn't actually standing in queue,

Ah but it is, that's exactly what we are doing when we encapsulate a 
Human concept, where do you think the idea comes from, why is it called 
a queue, because it's analogous to what we do when we go to the cinema, 
go to the bank, do queuing type things. In fact it's a very precise, 
well defined encapsulation, First in, First out. We enforce our ideas of 
what it means to stand in a queue by writing the code in such a way that 
is impossible for anything other than thing at the head of the queue to 
get out first. If we change the concept we change the name, 
PriorityQueue ? Highest priority out first regardless of position. This 
is an extension of the original concept that exists in the real world, 
the casualty department for example, triage sorts the urgent cases from 
the non urgent, you get seen depending on the urgency of your case not 
depending on when you arrived at the hospital.

The point I'm obviously struggling to make is that words convey concepts
The word Person conveys a whole lifetime of experience of People and as 
imperfect human beings many of us are unable to tease out 'bits of being 
a person' that are relevant to the system we are developing. Inevitably 
other seemingly irreversibly entwined bits keep popping up to cloud our 
thinking. This is my experience, not an isolated case but one that has 
popped up again and again.

> but it holds the data you store about the thing that is.
>
> Or maybe that doesn't help, in which case just ignore it.

I don't need any help with this but thank you for contributing

lipska

-- 
Lipska the Kat: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#26762 — Re: Looking for a good introduction to object oriented programming with Python

On Aug 8, 2:51 pm, lipska the kat <lipskathe...@yahoo.co.uk> wrote:

> The point I'm obviously struggling to make is that words convey concepts
> The word Person conveys a whole lifetime of experience of People and as
> imperfect human beings many of us are unable to tease out 'bits of being
> a person' that are relevant to the system we are developing. Inevitably
> other seemingly irreversibly entwined bits keep popping up to cloud our
> thinking. This is my experience, not an isolated case but one that has
> popped up again and again.

I once sat for a presentation of a wannabe university teacher.
The subject she chose was object-orientation.

She spent some time on the usual dope about employee, manager etc.
Finally she reached the base-class: Person.

Or so we thought...

Then suddenly she started 'extending' the bases:
Person inherits from mammal inherits from vertebrate inherits from
animal

Now in principle one could perhaps find an app where this whole
inheritance hierarchy makes sense.
But I cannot think of one.  (Maybe something from Orwell??)

In any case this is the incident that makes me side with your "NO
PERSON" dictum.

[toc] | [prev] | [next] | [standalone]

#26764 — Re: Looking for a good introduction to object oriented programming with Python

On Wed, 08 Aug 2012 09:27:40 -0700, rusi wrote:

> I once sat for a presentation of a wannabe university teacher. The
> subject she chose was object-orientation.
> 
> She spent some time on the usual dope about employee, manager etc.
> Finally she reached the base-class: Person.
> 
> Or so we thought...
> 
> Then suddenly she started 'extending' the bases: Person inherits from
> mammal inherits from vertebrate inherits from animal
> 
> Now in principle one could perhaps find an app where this whole
> inheritance hierarchy makes sense.

Presumably female managers who breast-feed their children inherit that 
method from Mammal.

And if you were modelling a futuristic space station with both human and 
non-human beings (perhaps for a game?), then distinguishing between those 
that inherit a breathe_oxygen() method from Animal versus those that 
inherit absorb_magnetic_energy() from Acturian_Magnevore might be useful.

I wasn't at this talk, but I would be willing to bet that she wasn't 
suggesting that any specific application needs to encompass the entire 
inheritance hierarchy from Animal to Junior Manager Of Pencil Sharpeners, 
only that the Inheritance design pattern was capable of doing so. 


> But I cannot think of one.  (Maybe something from Orwell??)
> 
> In any case this is the incident that makes me side with your "NO
> PERSON" dictum.

The problem with this dictum is that while it recognises that (e.g.) a 
Customer is not necessarily a person (it can be another business unit or 
a company), that's more the exception than the rule. A Student is always 
a person. So is an Employee or Employer, a Surgeon or Patient, or the 
subject of birth, death and marriage records.

(As they say: I'll believe that corporations are people when Texas 
executes one.)

You can, of course, ban the name "Person" from your classes and 
databases. But that's a mere cosmetic quirk -- you're still modelling 
people as objects and/or database records, whether you use the word or 
not.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#26773 — Re: Looking for a good introduction to object oriented programming with Python

On Thu, Aug 9, 2012 at 3:28 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> (As they say: I'll believe that corporations are people when Texas
> executes one.)

If proper excuse you can trump any,
You may wind up a Limited Company
You cannot conveniently blow it up!

-- WS Gilbert, "Utopia, Ltd"

But not every "is-a" relationship needs to be represented as class
inheritance. So what if all your Customers are Persons? Do you
_really_ need a Person base class? In a lot of systems, you don't. If
anything, you might have a generic base class for every entity that
has an Address (which would include corporations), but that's more
likely to want to be composition than inheritance (the customer Has-An
Address rather than the customer Is-An AddressibleEntity). Flat is
better than nested.

Of course, if you don't need an actual use-case, I could invent
several ridiculous base classes. Why not have one for Body, which
would be subclassed by Person and Corporation (after all, a
corporation is a body, that's where the name comes from), but not
Ghost. And then you could have a mixin called Intelligence which is
used by Corporation and Army (everyone knows what Business
Intelligence and Military Intelligence are), sometimes used by Person,
but never used by ClassDesign.

ChrisA

[toc] | [prev] | [next] | [standalone]

#26763 — Re: Looking for a good introduction to object oriented programming with Python

On Wed, 08 Aug 2012 10:51:45 +0100, lipska the kat
<lipskathekat@yahoo.co.uk> declaimed the following in
gmane.comp.python.general:

> 
> The point I'm obviously struggling to make is that words convey concepts
> The word Person conveys a whole lifetime of experience of People and as 
> imperfect human beings many of us are unable to tease out 'bits of being 
> a person' that are relevant to the system we are developing. Inevitably 
> other seemingly irreversibly entwined bits keep popping up to cloud our 
> thinking. This is my experience, not an isolated case but one that has 
> popped up again and again.
>
	You've never considered writing a genealogy program, have you? One
that never acknowledges "Person"?

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#26766 — Re: Looking for a good introduction to object oriented programming with Python

On 08/08/12 17:42, Dennis Lee Bieber wrote:
> On Wed, 08 Aug 2012 10:51:45 +0100, lipska the kat
> <lipskathekat@yahoo.co.uk>  declaimed the following in
> gmane.comp.python.general:
>
>>
>> The point I'm obviously struggling to make is that words convey concepts
>> The word Person conveys a whole lifetime of experience of People and as
>> imperfect human beings many of us are unable to tease out 'bits of being
>> a person' that are relevant to the system we are developing. Inevitably
>> other seemingly irreversibly entwined bits keep popping up to cloud our
>> thinking. This is my experience, not an isolated case but one that has
>> popped up again and again.
>>
> 	You've never considered writing a genealogy program, have you? One
> that never acknowledges "Person"?
>
Before I start let me say that this thread really has been the most 
enormous fun and I can take any amount of ridicule so don't hold back.

Normally when I have a bath I think of the best way to stop the mice 
from feasting on my herb patch without killing them. This evening I lay 
there thinking about this outwardly tricky problem when I realised that 
what we have here, at it's most basic, is a Tree.

I am not a genealogy expert, the nearest I've been to a family tree is 
the ones my old mum thrusts under my nose at Christmas, Sunday lunch, 
birthdays,funerals etc etc . They are increasing large, beautifully hand 
drawn and most definitely a Tree

So here is my off the cuff, in the bath design for a genealogy system

A Tree consists of Node(s) and Leaf(s), relationships are modelled by 
following the Line(s) in the Tree diagram and that is it. Line may be a 
class as in 'the patriarchal line' I'm not sure, it would come out in 
the iterative wash.

We can infer whatever we want from this simple model. A Leaf is a child, 
until it becomes a parent when it becomes a Node. To anthropomorphize a 
bit more (I love that word) and introduce non species specific words and 
concepts, a Node can be a father or mother (simple to implement by 
virtue of an enumeration e.g enum Gender{MALE, FEMALE, HERMAPHRODITE, 
NON_GENDER_SPECIFIC_CHIMERA, ...}) A male sibling of a parent is an 
uncle, a female an aunt and a cousin is ...I  have no idea but hopefully 
you can see where I'm going with this. Furthermore our system can work 
for Horses and Dogs and Zoomorphs and Epiphytes, Parasites and 
Zygomorphs and Fungi and Parrots and anything else you can possibly 
think of ...

But what of all the ephemeral data that goes with a sentient existance 
on this planet such as birth certificates, newspaper articles, 
christenings, death certificates, photographs etc etc, what about 
pegigree certificates, innoculation records and any other trivia, 
information and flotsam that goes with a pedigree Dog or Horse or indeed 
Parrot.

Well you don't need me to answer this one do you, we could have a class 
called Ephemera ... but then I prefer the Just In Time concept to 
loading data, I'd store the gubbins in a 'database' (don't get me 
started on databases) or I may decide to pickle the data out to disk and 
pull it out when someone requests it and probably charge them a small 
fortune for the privilige of looking at their own families historical 
information.

And not a 'Person' in sight

Of course you may be a genealogy expert and just waiting to shoot me 
down in flames, go ahead, I'll have a good smile about it next time I'm 
in the bath.

lipska

-- 
Lipska the Kat: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#26775 — Re: Looking for a good introduction to object oriented programming with Python

On Wed, 08 Aug 2012 20:31:57 +0100, lipska the kat
<lipskathekat@yahoo.co.uk> declaimed the following in
gmane.comp.python.general:

> A Tree consists of Node(s) and Leaf(s), relationships are modelled by 
> following the Line(s) in the Tree diagram and that is it. Line may be a 
> class as in 'the patriarchal line' I'm not sure, it would come out in 
> the iterative wash.
> 
> We can infer whatever we want from this simple model. A Leaf is a child, 
> until it becomes a parent when it becomes a Node. To anthropomorphize a 
> bit more (I love that word) and introduce non species specific words and 
> concepts, a Node can be a father or mother (simple to implement by 

	If a "node" is a father or mother, and it takes one of each to
produce a "leaf", your "tree" has just collapsed.

	In genealogy, a "tree" is merely the representation -- in one
direction -- of relationships from a single Person to either all
ancestors, or to all descendents.

	"Father", "mother", "son", "daughter" (or to simplify, "parent",
"child") are merely roles taken on by a person in relationship to
another person. A Person can exist even if we do not know who the
parents were, nor if there are any children.

> But what of all the ephemeral data that goes with a sentient existance 
> on this planet such as birth certificates, newspaper articles, 
> christenings, death certificates, photographs etc etc, what about 
> pegigree certificates, innoculation records and any other trivia, 
> information and flotsam that goes with a pedigree Dog or Horse or indeed 
> Parrot.
>
	Those documents are the /evidence/ used to prove the linkages of the
Person.

	Granted, the most popular genealogy program tends to be the least
capable -- it won't let one add a person without creating a "family"
first; and most all evidence is recorded as just a text memo.

	In contrast, TMG, provides for "Sources" (the documents),
"Citations" (references to sources, used in the events in the person's
life), "Repositories" (where the source can be found). Events cover
things like "Birth", "Marriage", "Death", "Graduation", etc. [one can
create custom events too]. Events have a date, a location, and can have
multiple citations to the source the provides evidence that the event
took place and involved the person to which it is linked. In TMG, there
is no "family" as such -- only the linkages from relationship events (a
"birth" event does not link a child to its parents; that is done via a
pair of parent-child relationships [father-relationship,
mother-relationship] and TMG supports having multiples -- only the pair
marked a "primary" is used to produce "tree-like" reports, but the
system supports having birth-parents and adoptive-parents at the same
time in the data). It even supports having multiple "Birth" events too,
if one finds conflicting evidence and can not determine if some is
invalid.

	I'm not going to go into depth, but the TMG (v8) database consists
of 29 tables, and the user interface centers on displaying a list of
events for a person. Oh, and the person can have more than one name too,
though only one can be listed as primary (shows at the top of the page)
-- the others appear as name events.

	The absolute minimum to define a person in TMG is an ID number (the
internal primary key) and preferably a "primary" name (and the name
could be all blanks -- though having multiple people with no names, just
ID numbers, makes for difficulty when later adding relationships: does
this person connect to "(---unknown---)(---unknown---)" #2718 or to
"(---unknown---)(---unknown---)" #3145 <G>)
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web