Stéphane Ducasse 1 Elements of Design - Simple Smells.

Slides:



Advertisements
Similar presentations
Lecture 10: Part 1: OO Issues CS 540 George Mason University.
Advertisements

Stéphane Ducasse«ChapterNr».1 The Design in Question The Basic Idea behind Frameworks Subclassing vs SubTyping Design Heuristics Design Symptoms.
General OO Concepts and Principles CSE301 University of Sunderland Harry R. Erwin, PhD.
Stéphane Ducasse 1 Design Points - Subclassing vs Subtyping Stéphane Ducasse
Georgia Institute of Technology Workshop for CS-AP Teachers Chapter 3 Advanced Object-Oriented Concepts.
Stéphane Ducasse2.1 OOP? What is OOP? Why? OOP in a nutshell.
Stéphane Ducasse«ChapterNr».1 Selected Design Patterns Design Patterns are recurrent solutions to design problems They are pros and cons We already saw:
Component Patterns – Architecture and Applications with EJB copyright © 2001, MATHEMA AG Component Patterns Architecture and Applications with EJB JavaForum.
Software Engineering and Design Principles Chapter 1.
Stéphane Ducasse«ChapterNr».1 Arthur Riel Design Heuristics from Object-Oriented Design Heuristics by Arthur Riel Read the Heuristics… –Find reasons why.
Chapter 3 Data Abstraction: The Walls. © 2005 Pearson Addison-Wesley. All rights reserved3-2 Abstract Data Types Modularity –Keeps the complexity of a.
Stéphane Ducasse6.1 Essential Concepts Why OO? What is OO? What are the benefits? What are the KEY concepts? Basis for all the lectures.
Stéphane Ducasse 1 Objects to the Roots: Learning from beauty.
Object-Orientated Design Unit 3: Objects and Classes Jin Sa.
Algorithm Programming Coding Advices Bar-Ilan University תשס " ו by Moshe Fresko.
Abstraction: Polymorphism, pt. 1 Abstracting Objects.
Seven Habits of Effective Pattern Writers Facade Pattern PH pp GoF pp John Klacsmann.
S.Ducasse Stéphane Ducasse 1 Elements of Design.
Systems Analysis and Design in a Changing World, Fifth Edition
REFACTORING Lecture 4. Definition Refactoring is a process of changing the internal structure of the program, not affecting its external behavior and.
Design Patterns.
(C) 2010 Pearson Education, Inc. All rights reserved. Java™ How to Program, 8/e.
Lecture 9 Polymorphism Richard Gesick.
Sadegh Aliakbary Sharif University of Technology Fall 2011.
S.Ducasse Stéphane Ducasse 1 Classes and Metaclasses - an Analysis.
CSCI-383 Object-Oriented Programming & Design Lecture 13.
Refactoring Improving the structure of existing code Refactoring1.
S.Ducasse Stéphane Ducasse 1 Design Heuristics.
1 Computer Science 340 Software Design & Testing Inheritance.
Instructor: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department Object Oriented.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Design Patterns IX Interpreter, Mediator, Template Method recap.
Refactoring1 Improving the structure of existing code.
Refactoring Deciding what to make a superclass or interface is difficult. Some of these refactorings are helpful. Some research items include Inheritance.
Structural Design Patterns
S.Ducasse Stéphane Ducasse savoie.fr e/ e/ 1 Inheritance Semantics and Method Lookup.
Refactoring 2. Admin Blackboard Quiz Acknowledgements Material in this presentation was drawn from Martin Fowler, Refactoring: Improving the Design of.
Stéphane Ducasse 1 Elements of Design - Inheritance/Compositio n.
Session 18 Chapter 8: Understanding Inheritance. Recall Exercise 2 From Tuesday It’s very annoying to move a target from the pallet and drop it in the.
Stéphane Ducasse 1 Singleton.
Com S 362: Object-Oriented Analysis and Design Refactoring.
Salman Marvasti Sharif University of Technology Winter 2015.
 Objects versus Class  Three main concepts of OOP ◦ Encapsulation ◦ Inheritance ◦ Polymorphism  Method ◦ Parameterized ◦ Value-Returning.
Object Oriented Programming
Design Patterns Software Engineering CS 561. Last Time Introduced design patterns Abstraction-Occurrence General Hierarchy Player-Role.
1 Software Maintenance and Evolution CSSE 575: Session 3, Part 3 Dealing with Generalization Steve Chenoweth Office Phone: (812) Cell: (937)
S.Ducasse Stéphane Ducasse 1 Essential OO Concepts Stéphane Ducasse.
Inheritance CSI 1101 Nour El Kadri. OOP  We have seen that object-oriented programming (OOP) helps organizing and maintaining large software systems.
Introduction to Object-Oriented Programming Lesson 2.
Stéphane Ducasse 1 Strategy.
Copyright © Craig Larman All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:
CSSE 375 Organizing Data – Part 2 Shawn and Steve Continue the same quiz!
Refactoring1 Improving the structure of existing code.
Inheritance and Class Hierarchies Chapter 3. Chapter 3: Inheritance and Class Hierarchies2 Chapter Objectives To understand inheritance and how it facilitates.
CSSE 375 Organizing Data – Part 1 Shawn and Steve Q1.
Software Construction and Evolution - CSSE 375 Dealing with Generalization Steve and Shawn Left – In the 1990 movie “The Freshman,” Matthew Broderick,
Stéphane Ducasse 1 Elements of Design - Unit of Reuse.
Module 9. Dealing with Generalization Course: Refactoring.
Stéphane Ducasse 1 Abstract Classes.
CSCE 240 – Intro to Software Engineering Lecture 3.
CLASSIFICATION OF DESIGN PATTERNS Hladchuk Maksym.
1 More About Derived Classes and Inheritance Chapter 9.
S.Ducasse 1 Instance Initialization How to ensure that an instance is well initialized? Automatic initialize Lazy initialization Proposing the right interface.
Object-Oriented Design
Design Points - Law of Demeter
Low Budget Productions, LLC
Week 4 Object-Oriented Programming (1): Inheritance
Lecture 23 Polymorphism Richard Gesick.
MSIS 670 Object-Oriented Software Engineering
Improving the structure of existing code
Fundaments of Game Design
Presentation transcript:

Stéphane Ducasse 1 Elements of Design - Simple Smells

S.Ducasse 2 A Simple Case... Introduce parametrization Avoid recompilation

S.Ducasse 3 Parametrization Advantages DialectStream>>initializeST80ColorTable "Initialize the colors that characterize the ST80 dialect" ST80ColorTable := IdentityDictionary new. #((temporaryVariable blue italic) (methodArgument blue normal) … (setOrReturn black bold)) do: [:aTriplet | ST80ColorTable at: aTriplet first put: aTriplet allButFirst] Problems: Color tables hardcoded in method Changes Require compilation Client responsible of initialize invocation No run-time changes

S.Ducasse 4 One Step DialectStream>>initializeST80ColorTable ST80ColorTable := IdentityDictionary new. self defaultDescription do: [:aTriplet | ST80ColorTable at: aTriplet first put: aTriplet allButFirst] DialectStream>>defaultDescription ^ #((temporaryVariable blue italic) (methodArgument blue normal) … (setOrReturn black bold)) Still requires subclassing and recompilation

S.Ducasse 5 Composition-based Solution DialectStream>>initializeST80ColorTableWith: anArray ST80ColorTable := IdentityDictionary new. anArray do: [:aTriplet | ST80ColorTable at: aTriplet first put: aTriplet allButFirst]. self initialize In a Client DialectStream initializeST80ColorTableWith: #(#(#temporaryVariable #blue #normal) … #(#prefixKeyword #veryDarkGray #bold) #(#setOrReturn #red #bold) )

S.Ducasse 6 Good Coding Practices Good coding practices promote good design Encapsulation Level of decomposition Factoring constants

S.Ducasse 7 Be lazy and be private Never do the job that you can delegate to another one Never let someone else plays with your private data The Object Manifesto

S.Ducasse 8 The Programmer Manifesto Say something only once Don’t ask, tell!

S.Ducasse 9 Designing Classes for Reuse Complete interface Responsibility of the instance creation Loose coupling between classes Methods are units of reuse (self send) Use polymorphism as much as possible to avoid type checking Behavior up and state down Use correct names for class Use correct names for methods

S.Ducasse 10 Behavior up State down Abstract class Concrete subclasses

S.Ducasse 11 Say once and only once No duplicated magic number Extract method Remove duplicated code

S.Ducasse 12 Factorize Magic Numbers Ideally you should be able to change your constants without having any impact on the code! For that define a constant only once via accessor provide testing method (hasNextNode) default value using the constant accessor

S.Ducasse 13 Factoring Out Constants We want to encapsulate the way “no next node” is coded. Instead of writing: Node>>nextNode ^ nextNode NodeClient>>transmitTo: aNode aNode nextNode = ‘no next node’...

S.Ducasse 14 Factoring Out Constants Write: NodeClient>>transmitTo: aNode aNode hasNextNode.... Node>>hasNextNode ^ (self nextNode = self class noNextNode) not Node class>>noNextNode ^ ‘no next node’

S.Ducasse 15 Default value between class and instance If we want to encapsulate the way “no next node” is coded and shared this knowledge between class and instances. Instead of writing: aNode nextNode isNil not Write: Node>>hasNextNode ^ self nextNode = self noNextNode Node>>noNextNode ^self class noNextNode Node class>>noNextNode ^ #noNode

S.Ducasse 16 Initializing without Duplicating Node>>initialize accessType := ‘local’... Node>>isLocal ^ accessType = ‘local’ It’s better to write Node>>initialize accessType := self localAccessType Node>>isLocal ^ accessType = self localAccessType Node>>localAccessType ^ ‘local’

S.Ducasse 17 Good Signs of OO Thinking Short methods No dense methods No super-intelligent objects No manager objects Objects with clear responsibilities State the purpose of the class in one sentence Not too many instance variables

S.Ducasse 18 How do you divide a program into methods? Messages take time Flow of control is difficult with small methods But: Reading is improved Performance tuning is simpler (Cache...) Easier to maintain / inheritance impact Composed Methods

S.Ducasse 19 Composed Methods Divide your program into methods that perform one identifiable task. Keep all of the operations in a method at the same level of abstraction. Controller>>controlActivity self controlInitialize. self controlLoop. self controlTerminate

S.Ducasse 20 Do you See the Problem? initializeToStandAlone super initializeToStandAlone. self borderWidth: 2. self borderColor: Color black. self color: Color blue muchLighter. self extent: self class defaultTileSize * (self self rowNumber). self initializeBots. self running. area := Matrix rows: self rowNumber columns: self columnNumber. area indicesDo: [:row :column | area at: row at: column put: OrderedCollection new]. self fillWorldWithGround. self firstArea. self installCurrentArea

S.Ducasse 21 Do you See the Problem? initializeToStandAlone super initializeToStandAlone. self initializeBoardLayout. self initializeBots. self running. self initializeArea. self fillWorldWithGround. self firstArea. self installCurrentArea

S.Ducasse 22 With code reuse… initializeArea area := self matrixClass rows: self rowNumber columns: self columnNumber. area indicesDo: [:row :column | area at: row at: column put: OrderedCollection new] initializeArea can be invoke several times

S.Ducasse 23 About Methods Avoid long methods A method: one task Avoid duplicated code Reuse Logic

S.Ducasse 24 Class Design

S.Ducasse 25 Behavior Up and State Down Define classes by behavior, not state Implement behavior with abstract state: if you need state do it indirectly via messages. Do not reference the state variables directly Identify message layers: implement class’s behavior through a small set of kernel method

S.Ducasse 26 Example Collection>>removeAll: aCollection aCollection do: [:each | self remove: each] ^ aCollection Collection>>remove: oldObject self remove: oldObject ifAbsent: [self notFoundError] Collection>>remove: anObject ifAbsent: anExceptionBlock self subclassResponsibility

S.Ducasse 27 Behavior-Defined Class When creating a new class, define its public protocol and specify its behavior without regard to data structure (such as instance variables, class variables, and so on). For example: Rectangle Protocol: area intersects: contains: perimeter width height insetBy:

S.Ducasse 28 Implement Behavior with Abstract State If state is needed to complete the implementation Identify the state by defining a message that returns that state instead of defining a variable. For example, use Circle>>area ^self radius squared * self pi not Circle>>area ^radius squared * pi.

S.Ducasse 29 Identify Message Layers How can methods be factored to make the class both efficient and simple to subclass? Identify a small subset of the abstract state and behavior methods which all other methods can rely on as kernel methods. Circle>>radius Circle>>pi Circle>>center Circle>>diameter ^self radius * 2 Circle>>area ^self radius squared * self pi