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.

DATE: March 23, 2005
LOCATION: GWU Cafritz Conference Center, Marvin Theatre

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

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!)
    Operator overloading
        Very difficult in C++
        Not available at all in Java
        Easy in Python (and C# ?)
        Automatically reflexive
    Static methods
        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
        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

    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}



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 }

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