SlideShare a Scribd company logo
Dependence Management Bob Martin says “Object-oriented programming is dependence management.” See his “Design Principles and Design Patterns” at http://www.objectmentor.com/resources/articles/Principles_and_Patterns.PDF
Dependence How can one package depend on another? Reuse a class By inheritance By instantiation (direct reference) Reuse a variable Reuse a method?
Dependence If package A depends on package B then you can’t run the tests for A unless you also have B. “A depends on B” means you can’t use A unless you have B. “Package A depends on package B” means that something in A depends on something in B.
Cycles of dependence If package A depends on package B then package B should NOT depend on package A. If classes C and D both depend on each other, put them in the same package.
Eliminating dependence The Observer pattern eliminates dependence. Suppose that “FBIAgent” is an observer of Mobster.  Mobster is a subclass of Model, so it can have observers.  Class FBIAgent probably depends on class Mobster, but Mobster does not depend on FBIAgent.
Observer Pattern Observer update: Subject addDependent: removeDependent: changed: Mobster robBank driveCar FBIAgent update: observer/ dependent model *
Smalltalk base library GUI library Application Application GUI SUnit tests
Abstract Server Bob Martin’s name for “depend on an interface, not on a concrete class”. Interface Client Server Creation script Consumer <<interface>> Resource Manager ResrcMgr1
Adapter Intent:  Convert the interface of a class into another interface clients expect.  Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. Adaptee Adapter Target
Adapter Target Request() Client Adapter Request() Adaptee
Adapter Allows client and adaptee to be unchanged Adapter is usually ugly Client Adaptee Adapter
Mediator Define an object that encapsulates how a set of objects interact.  Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. Example: Insurance policies must be approved before they are issued.  There is a procedure (which can change over time, and which is different for different kinds of policies) for approving a policy.  This procedure must interact with work queues of managers and with the history that is kept on the customer.  Instead of putting this procedure in the insurance policy, put it in a separate object that is easy to change.  (This is a “business process”)
Not Mediator CustomerHistory InsurancePolicy Worker
Mediator Procedure CustomerHistory InsurancePolicy Worker Mediator Colleagues If interaction is main thing that changes, then make the interaction be an object. Colleague classes become more reusable. Mediator is the non-reusable part.
Mediator Procedure CustomerHistory InsurancePolicy Worker Business Rule Domain Objects Mediator Colleagues
Application Model Mediator between widgets and domain model. PayrollSystemInterface ListView TextView Employee PayrollSystem
Façade Provide a unified interface to a set of interfaces in a subsystem.  Define a higher-level interface that makes the subsystem easier to use. Facade
The Compiler Scanner Return Expression SmalltalkExpression Compiler compile evaluate CompiledMethod AssignmentExpression Message Expression ... Parser
Creational Patterns Factory Method Factory Object Abstract Factory Builder Prototype Singleton
Factory Method Don't (call constructor / send message to class) directly. Make a separate function / method to create object. How to do it: Find every class name in “producer” Extract it (or perhaps “CN new”) into a method
Factory Method Results: Localizes dependencies Modules become less coupled Reduces coupling Can lead to parallel class hierarchies
Factory Method Producer doSomething ConcreteProducer createXX createXX  ^XX new doSomething  … self createXX ... XX
Factory Object Problem with factory method -- have to create subclass to parameterize. Often end up with parallel class hierarchies. Example: subclass of Tool for each figure you want to create Alternative: parameterize CreationTool with object that creates figure Smalltalk automatically creates a factory for every class, the Class! (Note: Factory Object is generalization of Abstract Factory,Builder, and Prototype.  It is not in the book.)
Applicability Use factory objects: when system creates them automatically when more than one class needs to have product specified when most subclasses only specialize to override factory method
FigureFactory new LineFigureFactory ElipseFigureFactory RectangleFigureFactory Figure LineFigure ElipseFigure RectangleFigure
Prototype Making a class hierarchy of factories seems wasteful. The parameters of an object can be as important as its class. Solution: Use any object as a factory by copying it to make a new instance. Advantages Don't need new factory hierarchy. Can make new &quot;class&quot; by parameterizing an object Disadvantages Requires robust copying
Making Prototype You have a design in which objects are parameterized by passing in classes.  You are making new classes just for their constructors, or you want to make “composite classes”. Make sure “copy” works.  Define “new” as an instance method that returns a copy.  Change client to pass in instances instead of classes.
Abstract Factory Sometimes a group of products are related -- if you change one, you might need to change them all. Solution: Make a single object that can make any of the products. ScrollBar MotifScrollBar PMScrollBar WidgitFactory CreateScrollBar CreateWindow MotifWidgetFactory CreateScrollBar CreateWindow PMWidgetFactory CreateScrollBar CreateWindow
Making Abstract Factory Give Producer a component called “Factory” Create class Factory Add instance variable “factory” to Producer Change constructor to have line factory:=Factory new Move factory methods to Factory Copy factory method to Factory Change sends of createFoo to “factory createFoo”
Builder Complex objects require a lot of work to make. Solution: Factory must keep track of partly built product. Client specifies product by performing series of operations on factory. Client WindowBuilder AddScrollBar AddButton GetWindow
Implementing Builder Builder can make components using Factory Method Abstract Factory, or Prototype WidgitFactory CreateScrollBar CreateWindow WindowBuilder AddScrollBar AddButton GetWindow PMWidgetFactory CreateScrollBar CreateWindow MotifWidgetFactory CreateScrollBar CreateWindow
Making Builder There are several places in your system where a complex object is built.  These places need to mention a lot of classes, unless you use a pattern like Abstract Factory. Constructors get complicated.  Perhaps there are a lot of class methods that deal with construction.  Construction needs temporary variables.  Make a class that builds the object for you.  It hides the concrete classes that are used and temporary variables used during construction. Result:  Producers not coupled with Product.  Builder is coupled with Product.
Summary of Factory Patterns Factory method -- use in simple cases so that you can change product Abstract factory -- use when there is a set of related products Builder -- use when product is complex  Prototype -- use when Factory Method is awkward and when classes are not objects, or when you want to specify new &quot;classes&quot; by composition
Singleton What if you want to make sure that a class has only one instance? One possibility is global variables.  Another is using class methods. Best solution:  store single instance in class variable.
Singleton The singleton class has a class variable “Instance” and a class method instance Instance isNil ifTrue: [Instance := super new]. ^Instance Alternative: make “Instance” a class instance variable.
Managing dependences Cost of eliminating dependences More abstract Harder to test Harder to understand It is OK to depend on stable packages. Stable = doesn’t change = has many dependents
Managing dependences Subsystem2 Application Library3 Library1 Library2 Subsystem1
Managing dependences Application2 Subsystem2 Subsystem1 Application1 Suppose Application2 depends on only a small part of Subsystem1, and that part doesn’t depend on Subsystem2
Managing dependences Application2 Subsystem2 Subsystem3 Application1 Subsystem1
Dependence management Determines Build times Difficulty of testing Frequency of rebuilding and retesting Ease of reuse Design patterns help control dependences
Design patterns and refactoring Patterns are most useful for complex systems. Add them later by refactoring Keep system simple – no unnecessary patterns Keep system flexible – all needed patterns
Next time More on Observer and creational patterns.

More Related Content

PDF
Factory Design Pattern
PPTX
Factory method pattern
PPT
Design Patterns
PDF
PPTX
Effective Java - Chapter 4: Classes and Interfaces
PPTX
Effective java
PPT
Abstract Factory Pattern
PPTX
Effective Java
Factory Design Pattern
Factory method pattern
Design Patterns
Effective Java - Chapter 4: Classes and Interfaces
Effective java
Abstract Factory Pattern
Effective Java

What's hot (19)

PPTX
Module 10 : creating and destroying objects
PPT
Factory Method Design Pattern
PDF
Large-Scale JavaScript Development
PPT
Jump Start To Ooad And Design Patterns
PPTX
Factory Method Pattern
PDF
Programmer testing
ODP
Design Patterns
PPTX
Desing pattern prototype-Factory Method, Prototype and Builder
PDF
Mage Titans 2016 - Object(ivly) Thinking
PPT
Ch. 3 classes and objects
PDF
jQquerysummit - Large-scale JavaScript Application Architecture
PPTX
Factory Design Pattern
PDF
J unit a starter guide
PDF
Creational Design Patterns
PPS
Jump start to OOP, OOAD, and Design Pattern
PPT
P Training Presentation
PPTX
Mockito vs JMockit, battle of the mocking frameworks
PDF
SAP Testing Training
PPT
JMockit
Module 10 : creating and destroying objects
Factory Method Design Pattern
Large-Scale JavaScript Development
Jump Start To Ooad And Design Patterns
Factory Method Pattern
Programmer testing
Design Patterns
Desing pattern prototype-Factory Method, Prototype and Builder
Mage Titans 2016 - Object(ivly) Thinking
Ch. 3 classes and objects
jQquerysummit - Large-scale JavaScript Application Architecture
Factory Design Pattern
J unit a starter guide
Creational Design Patterns
Jump start to OOP, OOAD, and Design Pattern
P Training Presentation
Mockito vs JMockit, battle of the mocking frameworks
SAP Testing Training
JMockit
Ad

Similar to Layers of Smalltalk Application (20)

PPTX
Creating and destroying objects
PPTX
DOCX
Generic Repository Pattern in MVC3 Application with Entity Framework
PPTX
Software Patterns
PPTX
Gof design patterns
ODP
(An Extended) Beginners Guide to Object Orientation in PHP
PPTX
Prototype design patterns
DOCX
Patterns (contd)Software Development ProcessDesign patte.docx
PPTX
Design patterns
PPTX
UNIT IV DESIGN PATTERNS.pptx
PPTX
Effective Java - Chapter 2: Creating and Destroying Objects
PPTX
31 days Refactoring
PPTX
Cs 1023 lec 8 design pattern (week 2)
PDF
Java Design Patterns Interview Questions PDF By ScholarHat
PPT
Design pattern
PPTX
Factory Method Pattern
PPTX
Software System Architecture-Lecture 6.pptx
PDF
C# Advanced L07-Design Patterns
PPTX
Design pattern-presentation
PPT
Software Design Patterns
Creating and destroying objects
Generic Repository Pattern in MVC3 Application with Entity Framework
Software Patterns
Gof design patterns
(An Extended) Beginners Guide to Object Orientation in PHP
Prototype design patterns
Patterns (contd)Software Development ProcessDesign patte.docx
Design patterns
UNIT IV DESIGN PATTERNS.pptx
Effective Java - Chapter 2: Creating and Destroying Objects
31 days Refactoring
Cs 1023 lec 8 design pattern (week 2)
Java Design Patterns Interview Questions PDF By ScholarHat
Design pattern
Factory Method Pattern
Software System Architecture-Lecture 6.pptx
C# Advanced L07-Design Patterns
Design pattern-presentation
Software Design Patterns
Ad

Recently uploaded (20)

PDF
Architecting across the Boundaries of two Complex Domains - Healthcare & Tech...
PDF
cuic standard and advanced reporting.pdf
PDF
Approach and Philosophy of On baking technology
DOCX
The AUB Centre for AI in Media Proposal.docx
PDF
Mobile App Security Testing_ A Comprehensive Guide.pdf
PPTX
20250228 LYD VKU AI Blended-Learning.pptx
PDF
7 ChatGPT Prompts to Help You Define Your Ideal Customer Profile.pdf
PDF
Blue Purple Modern Animated Computer Science Presentation.pdf.pdf
PPTX
Spectroscopy.pptx food analysis technology
PPTX
Understanding_Digital_Forensics_Presentation.pptx
PPTX
ACSFv1EN-58255 AWS Academy Cloud Security Foundations.pptx
PPTX
VMware vSphere Foundation How to Sell Presentation-Ver1.4-2-14-2024.pptx
PDF
Machine learning based COVID-19 study performance prediction
PDF
MIND Revenue Release Quarter 2 2025 Press Release
PDF
Reach Out and Touch Someone: Haptics and Empathic Computing
PDF
Profit Center Accounting in SAP S/4HANA, S4F28 Col11
PPTX
KOM of Painting work and Equipment Insulation REV00 update 25-dec.pptx
PDF
Review of recent advances in non-invasive hemoglobin estimation
PDF
Advanced methodologies resolving dimensionality complications for autism neur...
PPTX
Big Data Technologies - Introduction.pptx
Architecting across the Boundaries of two Complex Domains - Healthcare & Tech...
cuic standard and advanced reporting.pdf
Approach and Philosophy of On baking technology
The AUB Centre for AI in Media Proposal.docx
Mobile App Security Testing_ A Comprehensive Guide.pdf
20250228 LYD VKU AI Blended-Learning.pptx
7 ChatGPT Prompts to Help You Define Your Ideal Customer Profile.pdf
Blue Purple Modern Animated Computer Science Presentation.pdf.pdf
Spectroscopy.pptx food analysis technology
Understanding_Digital_Forensics_Presentation.pptx
ACSFv1EN-58255 AWS Academy Cloud Security Foundations.pptx
VMware vSphere Foundation How to Sell Presentation-Ver1.4-2-14-2024.pptx
Machine learning based COVID-19 study performance prediction
MIND Revenue Release Quarter 2 2025 Press Release
Reach Out and Touch Someone: Haptics and Empathic Computing
Profit Center Accounting in SAP S/4HANA, S4F28 Col11
KOM of Painting work and Equipment Insulation REV00 update 25-dec.pptx
Review of recent advances in non-invasive hemoglobin estimation
Advanced methodologies resolving dimensionality complications for autism neur...
Big Data Technologies - Introduction.pptx

Layers of Smalltalk Application

  • 1. Dependence Management Bob Martin says “Object-oriented programming is dependence management.” See his “Design Principles and Design Patterns” at http://www.objectmentor.com/resources/articles/Principles_and_Patterns.PDF
  • 2. Dependence How can one package depend on another? Reuse a class By inheritance By instantiation (direct reference) Reuse a variable Reuse a method?
  • 3. Dependence If package A depends on package B then you can’t run the tests for A unless you also have B. “A depends on B” means you can’t use A unless you have B. “Package A depends on package B” means that something in A depends on something in B.
  • 4. Cycles of dependence If package A depends on package B then package B should NOT depend on package A. If classes C and D both depend on each other, put them in the same package.
  • 5. Eliminating dependence The Observer pattern eliminates dependence. Suppose that “FBIAgent” is an observer of Mobster. Mobster is a subclass of Model, so it can have observers. Class FBIAgent probably depends on class Mobster, but Mobster does not depend on FBIAgent.
  • 6. Observer Pattern Observer update: Subject addDependent: removeDependent: changed: Mobster robBank driveCar FBIAgent update: observer/ dependent model *
  • 7. Smalltalk base library GUI library Application Application GUI SUnit tests
  • 8. Abstract Server Bob Martin’s name for “depend on an interface, not on a concrete class”. Interface Client Server Creation script Consumer <<interface>> Resource Manager ResrcMgr1
  • 9. Adapter Intent: Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. Adaptee Adapter Target
  • 10. Adapter Target Request() Client Adapter Request() Adaptee
  • 11. Adapter Allows client and adaptee to be unchanged Adapter is usually ugly Client Adaptee Adapter
  • 12. Mediator Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. Example: Insurance policies must be approved before they are issued. There is a procedure (which can change over time, and which is different for different kinds of policies) for approving a policy. This procedure must interact with work queues of managers and with the history that is kept on the customer. Instead of putting this procedure in the insurance policy, put it in a separate object that is easy to change. (This is a “business process”)
  • 13. Not Mediator CustomerHistory InsurancePolicy Worker
  • 14. Mediator Procedure CustomerHistory InsurancePolicy Worker Mediator Colleagues If interaction is main thing that changes, then make the interaction be an object. Colleague classes become more reusable. Mediator is the non-reusable part.
  • 15. Mediator Procedure CustomerHistory InsurancePolicy Worker Business Rule Domain Objects Mediator Colleagues
  • 16. Application Model Mediator between widgets and domain model. PayrollSystemInterface ListView TextView Employee PayrollSystem
  • 17. Façade Provide a unified interface to a set of interfaces in a subsystem. Define a higher-level interface that makes the subsystem easier to use. Facade
  • 18. The Compiler Scanner Return Expression SmalltalkExpression Compiler compile evaluate CompiledMethod AssignmentExpression Message Expression ... Parser
  • 19. Creational Patterns Factory Method Factory Object Abstract Factory Builder Prototype Singleton
  • 20. Factory Method Don't (call constructor / send message to class) directly. Make a separate function / method to create object. How to do it: Find every class name in “producer” Extract it (or perhaps “CN new”) into a method
  • 21. Factory Method Results: Localizes dependencies Modules become less coupled Reduces coupling Can lead to parallel class hierarchies
  • 22. Factory Method Producer doSomething ConcreteProducer createXX createXX ^XX new doSomething … self createXX ... XX
  • 23. Factory Object Problem with factory method -- have to create subclass to parameterize. Often end up with parallel class hierarchies. Example: subclass of Tool for each figure you want to create Alternative: parameterize CreationTool with object that creates figure Smalltalk automatically creates a factory for every class, the Class! (Note: Factory Object is generalization of Abstract Factory,Builder, and Prototype. It is not in the book.)
  • 24. Applicability Use factory objects: when system creates them automatically when more than one class needs to have product specified when most subclasses only specialize to override factory method
  • 25. FigureFactory new LineFigureFactory ElipseFigureFactory RectangleFigureFactory Figure LineFigure ElipseFigure RectangleFigure
  • 26. Prototype Making a class hierarchy of factories seems wasteful. The parameters of an object can be as important as its class. Solution: Use any object as a factory by copying it to make a new instance. Advantages Don't need new factory hierarchy. Can make new &quot;class&quot; by parameterizing an object Disadvantages Requires robust copying
  • 27. Making Prototype You have a design in which objects are parameterized by passing in classes. You are making new classes just for their constructors, or you want to make “composite classes”. Make sure “copy” works. Define “new” as an instance method that returns a copy. Change client to pass in instances instead of classes.
  • 28. Abstract Factory Sometimes a group of products are related -- if you change one, you might need to change them all. Solution: Make a single object that can make any of the products. ScrollBar MotifScrollBar PMScrollBar WidgitFactory CreateScrollBar CreateWindow MotifWidgetFactory CreateScrollBar CreateWindow PMWidgetFactory CreateScrollBar CreateWindow
  • 29. Making Abstract Factory Give Producer a component called “Factory” Create class Factory Add instance variable “factory” to Producer Change constructor to have line factory:=Factory new Move factory methods to Factory Copy factory method to Factory Change sends of createFoo to “factory createFoo”
  • 30. Builder Complex objects require a lot of work to make. Solution: Factory must keep track of partly built product. Client specifies product by performing series of operations on factory. Client WindowBuilder AddScrollBar AddButton GetWindow
  • 31. Implementing Builder Builder can make components using Factory Method Abstract Factory, or Prototype WidgitFactory CreateScrollBar CreateWindow WindowBuilder AddScrollBar AddButton GetWindow PMWidgetFactory CreateScrollBar CreateWindow MotifWidgetFactory CreateScrollBar CreateWindow
  • 32. Making Builder There are several places in your system where a complex object is built. These places need to mention a lot of classes, unless you use a pattern like Abstract Factory. Constructors get complicated. Perhaps there are a lot of class methods that deal with construction. Construction needs temporary variables. Make a class that builds the object for you. It hides the concrete classes that are used and temporary variables used during construction. Result: Producers not coupled with Product. Builder is coupled with Product.
  • 33. Summary of Factory Patterns Factory method -- use in simple cases so that you can change product Abstract factory -- use when there is a set of related products Builder -- use when product is complex Prototype -- use when Factory Method is awkward and when classes are not objects, or when you want to specify new &quot;classes&quot; by composition
  • 34. Singleton What if you want to make sure that a class has only one instance? One possibility is global variables. Another is using class methods. Best solution: store single instance in class variable.
  • 35. Singleton The singleton class has a class variable “Instance” and a class method instance Instance isNil ifTrue: [Instance := super new]. ^Instance Alternative: make “Instance” a class instance variable.
  • 36. Managing dependences Cost of eliminating dependences More abstract Harder to test Harder to understand It is OK to depend on stable packages. Stable = doesn’t change = has many dependents
  • 37. Managing dependences Subsystem2 Application Library3 Library1 Library2 Subsystem1
  • 38. Managing dependences Application2 Subsystem2 Subsystem1 Application1 Suppose Application2 depends on only a small part of Subsystem1, and that part doesn’t depend on Subsystem2
  • 39. Managing dependences Application2 Subsystem2 Subsystem3 Application1 Subsystem1
  • 40. Dependence management Determines Build times Difficulty of testing Frequency of rebuilding and retesting Ease of reuse Design patterns help control dependences
  • 41. Design patterns and refactoring Patterns are most useful for complex systems. Add them later by refactoring Keep system simple – no unnecessary patterns Keep system flexible – all needed patterns
  • 42. Next time More on Observer and creational patterns.