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 Nick Bastin Abhay Saxena Linden Wright Erik Rose -------------------------------------------------------------------------- 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...