Stéphane Ducasse 1 Elements of Design - Inheritance/Compositio n.

Slides:



Advertisements
Similar presentations
Stéphane Ducasse«ChapterNr».1 The Design in Question The Basic Idea behind Frameworks Subclassing vs SubTyping Design Heuristics Design Symptoms.
Advertisements

Stéphane Ducasse 1 Design Points - Subclassing vs Subtyping Stéphane Ducasse
SWE 4743 Strategy Patterns Richard Gesick. CSE Strategy Pattern the strategy pattern (also known as the policy pattern) is a software design.
Stéphane Ducasse«ChapterNr».1 Selected Design Patterns Design Patterns are recurrent solutions to design problems They are pros and cons We already saw:
Stéphane Ducasse«ChapterNr».1 Abstract Classes Should not be instantiated (abstract in Java) But can defined complete methods Defines a protocol common.
Stéphane Ducasse9.1 Inheritance Semantics and Lookup.
Stéphane Ducasse8.1 Syntax and Messages The syntax of Smalltalk is simple and uniform, but it can look strange at first sight! Literals: numbers, strings,
CAHE Technology Help Desk ● (505) ● ● Intermediate Word – Part III Mail Merge.
Stéphane Ducasse 1 The Taste of Smalltalk.
PZ06BX Programming Language design and Implementation -4th Edition Copyright©Prentice Hall, PZ06BX - Introduction to Smalltalk Programming Language.
Some Basic Points on Classes
S.Ducasse Stéphane Ducasse 1 A Taste of Smalltalk.
Object-Oriented Databases
Software Engineering, COMP201 Slide 1 Protocol Engineering Protocol Specification using CFSM model Lecture 30.
Stéphane Ducasse«ChapterNr».1 Elements of Design Instance initialization Enforcing the instance creation Instance / Class methods Instance variables /
Stéphane Ducasse 1 Objects to the Roots: Learning from beauty.
Reuse Activities Selecting Design Patterns and Components
Stéphane Ducasse5.1 Smalltalk in a Nutshell OO Model in a Nutshell Syntax in a Nutshell.
Stéphane Ducasse 1 Smalltalk in a Nutshell.
S.Ducasse Stéphane Ducasse 1 The Taste of Smalltalk.
S.Ducasse Stéphane Ducasse 1 Elements of Design.
REFACTORING Lecture 4. Definition Refactoring is a process of changing the internal structure of the program, not affecting its external behavior and.
Design Patterns.
Chapter 1: Introduction to Design Patterns. SimUDuck Example.
T Network Application Frameworks and XML Web Services and WSDL Sasu Tarkoma Based on slides by Pekka Nikander.
Chapter 5 Design Principles II: Flexibility, Reusability, and Efficiency.
©Fraser Hutchinson & Cliff Green C++ Certificate Program C++ Intermediate Decorator, Strategy, State Patterns.
WORD PROCESSING Definition: A word processor (more formally known as document preparation system) is a computer application (Program) used for the production.
(Business) Process Centric Exchanges
Stéphane Ducasse 1 Elements of Design - Simple Smells.
OUTLOOK RULES AND ALERTS TOOLS FOR EFFECTIVE MANAGEMENT PMI Honolulu September 16, 2009.
Centralized vs. Decentralized Interpreter Pattern Visitor Pattern.
Lexi case study (Part 2) Presentation by Matt Deckard.
Stéphane Ducasse 1 Visitor.
Marine Biology Simulation Part II: Assignment, Milestone 1 Dung “Zung” Nguyen Mathias Ricken Stephen Wong TeachJava 2004! June 25, 2004.
Object Oriented Design David Talby. Welcome! n Introduction n UML u Use Case Diagrams u Interaction Diagrams u Class Diagrams n Design Patterns u Composite.
S.Ducasse Stéphane Ducasse savoie.fr e/ e/ 1 Inheritance Semantics and Method Lookup.
STAR Extended Pre-ID Data Corrections March 28, 2012 START TIME 9 a.m. Presenters: Michael McDaniel and Mark Hansen Extended Pre-ID Data Corrections.
Stéphane Ducasse 1 Singleton.
S.Ducasse Stéphane Ducasse 1 Essential OO Concepts Stéphane Ducasse.
S.Ducasse Stéphane Ducasse 1 Common Mistakes and Debugging in VW.
PRESENTATION DAY Group ID: gp09-cmg Speaker: Matthew Albers RFID APPLICATION DEVELOPMENT SUITE.
Nathanael Schärli (SCG, University of Bern) and Andrew P. Black (CSE, Oregon Health & Science University) Nathanael Schärli (SCG, University of Bern) and.
Stéphane Ducasse 1 Some Advanced Points on Classes.
Stéphane Ducasse 1 Run-Time...
Stéphane Ducasse 1 Strategy.
Stéphane Ducasse7.1 Let’s Play Objects Simulate a LAN physically Set up a context for –future chapters –Exercises Some forward references to intriguate.
S.Ducasse Stéphane Ducasse 1 Decorator.
Stéphane Ducasse 1 Some Points on Classes.
1 SMWG Service Management Book Refactoring Report Anthony Crowson Colin Haddow October 2009, ESTEC October 15, 2008.
Session 7 Introduction to Inheritance. Accumulator Example a simple calculator app classes needed: –AdderApp - contains main –AddingFrame - GUI –CloseableFrame.
S.Ducasse Stéphane Ducasse 1 Smalltalk in a Nutshell.
S.Ducasse Stéphane Ducasse savoie.fr e/ e/ 1 Smalltalk in a Nutshell.
S.Ducasse Stéphane Ducasse 1 Some Principles Stéphane Ducasse ---
Stéphane Ducasse 1 A Little Journey in the Smalltalk Syntax.
Stéphane Ducasse 1 Elements of Design - Unit of Reuse.
Module 9. Dealing with Generalization Course: Refactoring.
Stéphane Ducasse 1 Abstract Classes.
Patterns Protect from Change Rule: if something is going to change, make it an object. Strategy: make algorithm an object so it can change State: make.
S.Ducasse 1 Instance Initialization How to ensure that an instance is well initialized? Automatic initialize Lazy initialization Proposing the right interface.
Sections Inheritance and Abstract Classes
Let’s Play Objects.
Jonathan Rosenberg Volker Hilt Daryl Malas
Design Points - Law of Demeter
2.2 Framework Techniques.
2.3 Collaboration Contracts
Compass Navigation Support for Back-in-Time Debugging
Object Oriented Analysis and Design
Object Oriented Design
Introduction to Smalltalk
Presentation transcript:

Stéphane Ducasse 1 Elements of Design - Inheritance/Compositio n

S.Ducasse 2 A Formating Text Editor With several possible algorithms formatWithTex formatFastColoring formatSlowButPreciseColoring

S.Ducasse 3 Code Smells Composition>>repair formatting == #Simple ifTrue: [ self formatWithSimpleAlgo] ifFalse: [ formatting == #Tex ifTrue: [self formatWithTex]....]

S.Ducasse 4 Inheritance? May not be the solution since: - you have to create objects of the right class - it is difficult to change the policy at run-time - you can get an explosion of classes bloated with the use of a functionality and the functionalities. - no clear identification of responsibility

S.Ducasse 5 Inheritance vs. Composition Inheritance is not a panacea Require class definition Require method definition Extension should be prepared in advance No run-time changes Ex: editor with spell-checkerS, colorizerS, mail- readerS…. No clear responsibility Code bloated Cannot load a new colorizers

S.Ducasse 6 Delegating to other Objects myEditor setColorizer: FastColorizer new. myEditor setColorizer: AdvancedColorizer new. Strategy design pattern

S.Ducasse 7 Composition Analysis Pros Possibility to change at run-time Clear responsibility No blob Clear interaction protocol Cons New class Delegation New classes

S.Ducasse 8 Another example

S.Ducasse 9 Delegation of Responsibilities New requirement: A document can be printed on different printers for example lw100s or lw200s depending on which printer is first encountered.

S.Ducasse 10 Ad-hoc Solution LanPrinter>>accept: aPacket (thePacket addressee = #*lw*) ifTrue: [ self print: thePacket] ifFalse: [ (thePacket isAddressedTo: self) ifTrue: [self print: thePacket] ifFalse: [super accept: thePacket]] Limits: not general brittle because based on a convention adding a new kind of address behavior requires editing the class Printer

S.Ducasse 11 Create Object and Delegate An alternative solution: isAddressedTo: could be sent directly to the address With the current solution, the packet can still control the process if needed

S.Ducasse 12 NodeAddress NodeAddress is responsible for identifying the packet receivers Packet>>isAddressedTo: aNode ^ self address isAddressedTo: aNode address “was name” Object subclass: #NodeAddress instanceVariableNames: ‘id‘ NodeAddress>>isAddressedTo: aNodeAddress ^ self id = aNodeAddress id Refactoring Remark: name was not a good name anyway, and now it has become an address -> we should rename it.

S.Ducasse 13 Matching Address For packets with matchable addresses Packet send: ‘lulu’ to: (MatchingAddress with: #*lw*) Address subclass: #MatchingAddress instanceVariableNames: ‘’ MatchingAddress>>isAddressedTo: aNodeAddress ^ self id match: aNodeAddress id

S.Ducasse 14 Addresses Object subclass: #Address instanceVariableNames: ‘id‘ Address>>isAddressedTo: anAddress ^self subclassResponsibility Address subclass: #NodeAddress instanceVariableNames: ‘‘ Address subclass: #MatchingAddress instanceVariableNames: ‘‘

S.Ducasse 15 Trade-Off Delegation Pros No blob class: one class one responsibility Variation possibility Pluggable behavior without inheritance extension Runtime pluggability Delegation Cons Difficult to follow responsibilities and message flow Adding new classes = adding complexities (more names) New object