Object-Oriented Design with Python.notes
Thursday, March 24, 2005
TITLE OF PAPER: Object-Oriented Design with Python
URL OF PRESENTATION: _URL_of_powerpoint_presentation_
PRESENTED BY: Bruce Eckel, www.mindview.net
REPRESENTING: Mindview, Inc.
CONFERENCE: PyCon 2005
DATE: March 23, 2005
LOCATION: GWU Cafritz Conference Center, Marvin Theatre
--------------------------------------------------------------------------
REAL-TIME NOTES / ANNOTATIONS OF THE PAPER:
{If you've contributed, add your name, e-mail & URL at the bottom}
YAY! Bruce is here.
OO Design is well understood?
Reasonably... from a certain point of view
Seem to discover something new every now and then
Kind of like learning about concurrency
Stories, scheduling, object discovery, design, feedback, iteration
Fairly similar regardless of implementation language
In the last few years, my hobby has been "Challenging accepted knowledge"
In the process I understand things better
Design techniques influenced by the host language and background of
programmer
Much of OO design is the same
What is different because we're using a dynamic language?
[Example: UML - does an object owns another object or not]
Embedded Objects, auto destructor in C++
Referenced counting objects are not 'owned' by superclass
Clearly the UML creators were thinking about this with a C++ mindset
[Example: Design Patterns]
The Gang of Four book was written primarily with pre-template C++ in mind
There was one Smalltalk programmer who had very limited influence
One pattern in particular was favorite of one author, least favorite of
another
Review of OO in Python
Static fields
Default arguments
Instance fields (created in an instance method (Doesn't this make it hard to track entropy--profusion of states? Puts more reliance on good docs.))
Destructors, called most of the time (hey, but not always timely!)
Reflection
Operator overloading
Very difficult in C++
Not available at all in Java
Easy in Python (and C# ?)
Automatically reflexive
Static methods
Inheritance
constructors automatically inherit in python (They do?! Not if I override __init__, they don't. Am I insane, anybody? Yep, then its explicit.)
* They inherit, but they're virtual <-- virtual is a C++ word :)
* Yes, but it describes your situation.. :-)
(they do by default is his point) Oh. Thx
Multiple Inheritance
Type-class unification
allows us to inherit from built in types
All types are classes. There are no "primitive" types as in Java.
Interface inheritance vs. Implementation inheritance
Why do we inherit?
Statically typed languages
You inherit to allow polymorphism by creating a common interface
Upcast to "forget" a specific type
Dynamic and Duck Typed languages
You inherit to reuse the implementation
Adding to it
Modifying the behavior
Much code vanishes when you can just "send messages to objects"
So it's really tough to get object-orientation right, especially when you
have all this additional complexity
Does Python need interfaces?
I've thought:
Interfaces are for static type checking
But from yesterday's conversation:
Python is dynamically typed, doesn't need adaptors for small - moderate
size programs, but interfaces buy you...
Interfaces allow you to find out more about the type before you call
the method. Interfaces are for semantics, classes for
implementation.
Can produce less coupling at the point of creation
Can be a helpful way to communicate /about/ design, ala design patterns
PEP 245 formalizes a straightforward way to create interfaces
Does Python need adapters?
No, Adapters are "just" a convenience
Concept: Connecting two incompatible objects
But adapters do make it easier, and interfaces visiable
Especially when working with larger systems like frameworks
Reduce the handwork to make classes work with a framework
Also make adaptation more commonplace and natural by formalizing ...
Delegation (structural)
...is midway between composition and inheritance
Inheritance: you get the whole interface
Composition: underlying object is hidden
Delegation: Some or all of the interface is exposed
"Fronting" for an object happens often in design patterns.
Example: A proxy. You can insert operations before/after the call
Generators
A special case of a factory
Still a pattern, but language support changes the sense of it
Iterator pattern also built into a number of places
Aspect-oriented programming
Are dynamic languages always better?
Tempting to say so
Not all programmers are at the same level
Sometimes you need the boundaries
Thinking in Python (book) as a wiki
--------------------------------------------------------------------------
REFERENCES: {as documents / sites are referenced add them below}
www.MindView.net
Bruce@EckelObjects.com
--------------------------------------------------------------------------
QUOTES:
--------------------------------------------------------------------------
CONTRIBUTORS: {add your name, e-mail address and URL below}
Andy Wright <waw@well.com>
Nick Bastin <nick.bastin@gmail.com> <http://www.nickbastin.com>
Abhay Saxena <ark3@email.com>
Linden Wright <lwright@mac.com>
Erik Rose <corp@grinchcentral.com>
--------------------------------------------------------------------------
E-MAIL BOUNCEBACK: {add your e-mail address separated by commas }
--------------------------------------------------------------------------
NOTES ON / KEY TO THIS TEMPLATE:
A headline (like a field in a database) will be CAPITALISED
This differentiates from the text that follows
A variable that you can change will be surrounded by _underscores_
Spaces in variables are also replaced with under_scores
This allows people to select the whole variable with a simple double-click
A tool-tip is lower case and surrounded by {curly brackets / parentheses}
These supply helpful contextual information.
--------------------------------------------------------------------------
Copyright shared between all the participants unless otherwise stated...