SlideShare une entreprise Scribd logo
1  sur  142
Object Oriented Design Sudarsun S.,  M.Tech Director – R & D Checktronix India Pvt Ltd Chennai 600010
Objectives ,[object Object],[object Object],[object Object]
What is an OBJECT ,[object Object],[object Object],[object Object],[object Object],[object Object]
A little Quiz… ,[object Object],Dog is a generalization of Scooby-Doo Dog Scooby-Doo
A little Quiz (cont’d)… ,[object Object],The concept of  subclass ! Dog is a subclass of the Animal class Animal is a generalization of Dog Dog Scooby-Doo Animal
A little Quiz (cont’d)… ,[object Object],The concept of  polymorphism ! Animal Dog Bird
Characteristics of OOD ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Interacting objects
Advantages of OOD ,[object Object],[object Object],[object Object]
Object-oriented development ,[object Object],[object Object],[object Object],[object Object]
Objects and object classes  ,[object Object],[object Object],[object Object],[object Object]
Object communication ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Message examples ,[object Object],[object Object],[object Object],[object Object]
Generalisation and inheritance ,[object Object],[object Object],[object Object],[object Object],[object Object]
A generalisation hierarchy
Object Relationships ,[object Object],[object Object],[object Object]
Object identification ,[object Object],[object Object],[object Object],[object Object],[object Object]
Approaches to identification ,[object Object],[object Object],[object Object],[object Object]
Object interface specification ,[object Object],[object Object],[object Object]
Examples of design models ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Weather station subsystems
Weather station - data collection sequence
State charts ,[object Object],[object Object]
OO Design Process –  Access Layer ,[object Object],[object Object],[object Object],[object Object]
Object Oriented Design Process ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Example: Invoice
Example: Invoice ,[object Object],[object Object],[object Object],[object Object]
Finding Classes ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
CRC Card ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
CRC Card
Self Check ,[object Object],[object Object],[object Object]
Answers ,[object Object],[object Object],[object Object]
Relationships Between Classes ,[object Object],[object Object],[object Object]
Inheritance ,[object Object],[object Object],[object Object],Continued…
Inheritance ,[object Object],[object Object],[object Object],[object Object]
Aggregation ,[object Object],[object Object],[object Object],[object Object],[object Object],class Tire {   . . .   private String rating;   private Circle boundary; }
Example class Car extends Vehicle {   . . .   private Tire[] tires; }
Example UML Notation for Inheritance and Aggregation
Dependency ,[object Object],[object Object],[object Object],[object Object]
UML Relationship Symbols Open Dotted  Dependency Diamond Solid Aggregation Triangle Dotted Interface Implementation Triangle Solid Inheritance Arrow Tip Line Style Symbol Relationship
Self Check ,[object Object],[object Object],[object Object]
Answers ,[object Object],[object Object],[object Object]
Attributes and Methods in UML Attributes and Methods in a Class Diagram
Multiplicities ,[object Object],[object Object],[object Object],[object Object],An Aggregation Relationship with Multiplicities
Aggregation and Association ,[object Object],[object Object],[object Object],[object Object],Continued…
Aggregation and Association An Association Relationship
Five-Part Development Process ,[object Object],[object Object],[object Object],[object Object],[object Object]
Printing an Invoice – Requirements ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Continued…
Sample Invoice
CRC Cards ,[object Object],[object Object],Invoice Address LineItem Product Description Price Quantity Total Amount Due
CRC Cards ,[object Object],Invoice Address LineItem  // Records the product and the quantity Product Description // Field of the Product class Price  // Field of the Product class Quantity  // Not an attribute of a Product Total  // Computed–not stored anywhere Amount Due  // Computed–not stored anywhere  Continued…
CRC Cards ,[object Object],Invoice Address LineItem Product
CRC Cards for Printing Invoice ,[object Object]
CRC Cards for Printing Invoice ,[object Object]
CRC Cards for Printing Invoice ,[object Object]
CRC Cards for Printing Invoice ,[object Object]
Printing an Invoice – UML Diagrams The Relationships Between the Invoice Classes
Method Documentation ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Method Documentation –  Invoice  class  /**   Describes an invoice for a set of purchased products. */ public class Invoice {   /**   Adds a charge for a product to this invoice.   @param aProduct the product that the customer ordered   @param quantity the quantity of the product   */   public void add(Product aProduct, int quantity)   {   }   /**   Formats the invoice.   @return the formatted invoice   */   public String format()   {   } }
Method Documentation –  LineItem  class  /**   Describes a quantity of an article to purchase and its price. */ public class LineItem {   /**   Computes the total cost of this line item.   @return the total price   */   public double getTotalPrice()   {   }   /**   Formats this item.   @return a formatted string of this line item   */   public String format()   {   } }
Method Documentation –  Product  class  /**   Describes a product with a description and a price. */ public class Product {   /**   Gets the product description.   @return the description   */   public String getDescription()   {   }   /**   Gets the product price.   @return the unit price   */   public double getPrice()   {   } }
Method Documentation –  Address  class  /**   Describes a mailing address. */ public class Address {   /**   Formats the address.   @return the address as a string with three lines   */   public String format()   {   } }
Implementation ,[object Object],[object Object],[object Object],public class Invoice {   . . .   private Address billingAddress;   private ArrayList<LineItem> items; }
Implementation ,[object Object],public class LineItem {   . . .   private int quantity;   private Product theProduct; }
Implementation ,[object Object],[object Object],[object Object],/**   Computes the total cost of this line item.   @return the total price */ public double getTotalPrice() {   return theProduct.getPrice() * quantity; }
Self Check ,[object Object],[object Object]
Answers ,[object Object],[object Object]
Suh’s Axioms of OOD ,[object Object],[object Object]
Occum’s Razor rule of simplicity ,[object Object],[object Object],[object Object]
Some Corollaries… ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Uncoupled Design ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Cohesion ,[object Object],[object Object],[object Object],[object Object],[object Object]
Corollary 2:  Single Purpose  ,[object Object],[object Object],[object Object],[object Object],[object Object]
Achieving Multiple Inheritance ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Class Visibility ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Design patterns ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Pattern elements ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Types of Patterns ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Patterns by Example: Multiple displays enabled by Observer A=10% B=40% C=30% D=20% Application data A B C D A D C B Relative Percentages Y 10  40  30 20 X 15  35  35 15 Z 10  40  30 20 A  B  C  D Change notification Requests, modifications
The Observer pattern ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
The Observer pattern observerState= subject     getState(); Subject attach (Observer) detach (Observer) Notify () Observer Update() Concrete Observer Update() observerState Concrete Subject GetState() SetState() subjectState observers subject For all x in observers{ x     Update(); }
The Mediator Pattern ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
The Mediator Pattern
The Façade Pattern ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Facade   Pattern: Problem Subsystem classes Client Classes Need to communicate with
Facade   Pattern: Solution Subsystem classes Fac ade Client Classes
The Façade Pattern
The Proxy Pattern ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
The Proxy Pattern
The Adapter Pattern ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
The Adapter Pattern
The Abstract Factory Pattern ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
The Abstract Factory Pattern AbstractFactory CreateProductA() CreateProductB() ConcreteFactory1 Client ProductA1 ProductA2 AbstractProductA ProductB2 ProductB1 AbstractProductB ConcreteFactory2 CreateProductA() CreateProductB()
Abstract Factory Example WidgetFactory CreateScrollbar() CreateWindow() Window ScrollBar WWidgetFactory MacWidgetFactory Client WWindow MacWindow MacScrollBar WScrollBar One for each standard.
[object Object],[object Object],[object Object],[object Object],Dependency Management
What is dependency management? ,[object Object],[object Object]
What bearing does DM have on software? ,[object Object],[object Object]
What is the penalty for practicing poor DM? ,[object Object],[object Object],[object Object],[object Object],A system with poor dependency structure will typically exhibit these four negative traits:
It is Rigid ,[object Object],[object Object],[object Object],[object Object],[object Object],Rigidity is the inability  to be changed
Changes with Rigidity The System Officially Rigid Area Where the change should be made Where the change must be made now Are we containing risk, or spreading rot?
It is Fragile ,[object Object],[object Object],[object Object],[object Object],Software changes seem to exhibit non-local effects
Increasing Risk Defects v. Cumulative Modifications Systems tend to become increasingly fragile over time. Intentional, planned partial rewrites may be necessary to sustain growth and maintenance. Changes Probability of  introducing a bug 1.0
It is not reusable ,[object Object],[object Object]
The Trailer The Trailer
It has high viscosity ,[object Object],[object Object],Viscosity is resistance to fluid motion.
What is the benefit  of good DM? Interdependencies are managed, with firewalls separating aspects that need to vary independently. Fewer Trailers Slow the rot More Flexible Less fragile, the bugs are boxed in Easier to reuse Easier to make the right change
What causes “Code Rot”? ,[object Object],It’s been blamed on stupidity, lack of discipline, and phases of the moon, but...
First Version All designs start well The program is an overnight success! How could it be more simple, elegant, and maintainable? void copy(void) { int ch; while( (ch=ReadKeyboard()) != EOF) WritePrinter(ch); }
Second Version ,[object Object],[object Object],[object Object],Oh, no! Nobody said the requirements might change!
Second Version Design bool GtapeReader = false; // remember to clear void copy(void) { int ch; while( (ch=GtapeReader ? ReadTape() : ReadKeyboard()) != EOF) WritePrinter(ch); }
Third Version How unexpected! Requirements changed again! bool GtapeReader = false;  Bool GtapePunch = false;  // remember to clear void copy(void) { int ch; while( (ch=GtapeReader ? ReadTape() : ReadKeyboard()) != EOF) GtapePunch ? WritePunch(ch) : WritePrinter(ch); } It seems that sometimes we need to write to a paper tape punch. We’ve had this problem before, and just added a flag. Looks like it should work again.
Example of a Good Design First and only version. void Copy() { int c; while( (c=getchar()) != EOF) putchar(c); } But wait! Aren’t we supposed to be learning OO design? This isn’t OO is it?
… is it? ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],It is a small program based on abstractions! FILE is a class, just implemented differently.
Rephrased in OO interface Reader { char read(); } interface Writer { void write(char c); } public class Copy { Copy(Reader r, Writer w) { itsReader = r; itsWriter = w; } public void copy() { int c; while( (c==itsReader.read()) != EOF ) itsWriter.write(c); } private Reader itsReader; private Writer  itsWriter; }
Class Design Principles ,[object Object],[object Object],[object Object],[object Object],[object Object],From: Agile Software Development: Principles, Patterns, and Practices. Robert C. Martin, Prentice Hall, 2002.
The Single Responsibility Principle ,[object Object]
Open/Closed Principle ,[object Object],[object Object],[object Object],“ Modules should be open for extension, but closed for modification” -Bertrand Meyer
Abstraction is Key ,[object Object],[object Object],[object Object],Abstraction is  the most important   word in OOD
The Shape Example ,[object Object],[object Object]
Procedural (open) version enum ShapeType {circle, square}; struct Shape  {enum ShapeType itsType;}; struct Circle  { enum ShapeType itsType; double itsRadius; Point itsCenter; }; void DrawCircle(struct Circle*) struct Square  { enum ShapeType itsType; double itsSide; Point itsTopLeft; }; void DrawSquare(struct Square*) #include <Shape.h> #include <Circle.h> #include <Square.h> typedef struct Shape* ShapePtr; void  DrawAllShapes(ShapePtr list[], int n) { int i; for( i=0; i< n, i++ ) { ShapePtr s = list[i]; switch ( s->itsType ) { case square: DrawSquare((struct Square*)s); break; case circle: DrawCircle((struct Circle*)s); break; } } } Shape.h Circle.h Square.h DrawAllShapes.c
What is wrong with the code? ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],It can be demonstrated to work. Isn’t that the important thing?
A Closed Implementation Class Shape { public: virtual void Draw() const =0; }; #include <Shape.h> void  DrawAllShapes(Shape* list[],int n) { for(int i=0; i< n; i++) list[i]->draw(); } Shape.h DrawAllShapes.cpp Circle.h Square.h Class Square: public Shape { public: virtual void Draw() const; }; Class Circle: public Shape { public: virtual void Draw() const; };
Strategic Closure ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],No program is 100% closed.
Liskov Substitution Principle ,[object Object],[object Object],Derived classes must be usable through the base class interface, without the need for the user to know the difference.
Square/Rectangle A square is-a rectangle, right? So lets consider Square as a subtype of Rectangle. void Square::SetWidth(double w) { width = w; height = w; } void Square::SetHeight(double h) { width = h; height = h; } We can  make  it work: Uh, oh. This doesn’t quite seem to fit
Substitution… denied! ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Liskov Substitution Principle ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Liskov Substitution Principle ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Design by Contract ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],int Base::f(int x); // REQUIRE: x is odd // PROMISE: return even int int Derived::f(int x); // REQUIRE: x is int // PROMISE: return 8
LSP is about Semantics and Replacement ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Dependency Inversion Principle Details should depend on abstractions. Abstractions should not depend on details. V.
Dependency Inversion Principle I.  High-level modules should  not   depend on low-level modules.  Both should depend on abstractions. II. Abstractions should not depend on details.  Details should depend on abstractions R. Martin , 1996  ,[object Object],[object Object],[object Object]
Procedural vs. OO Architecture Procedural  Architecture Object-Oriented  Architecture
DIP Applied on Example Copy Reader Writer Keyboard Reader Printer Writer class Reader { public:  virtual int read()=0; }; class Writer { public:  virtual void write(int)=0; }; void Copy(Reader& r, Writer& w){ int c; while((c = r.read()) != EOF) w.write(c); } Disk Writer
Interface Segregation Principle ,[object Object],[object Object],[object Object],[object Object],[object Object],Helps deal with “fat” or inappropriate interfaces
Interface Pollution by “collection” Distinct clients of our class have distinct interface needs.
A Segregated Example
ATM UI Example
A Segregated ATM UI Example
Logger Example
Four Class Design Principles - Review ,[object Object],[object Object],[object Object],[object Object]
Thank you ,[object Object],[object Object],[object Object]

Contenu connexe

Tendances

Formal Specification in Software Engineering SE9
Formal Specification in Software Engineering SE9Formal Specification in Software Engineering SE9
Formal Specification in Software Engineering SE9
koolkampus
 
Software Requirements in Software Engineering SE5
Software Requirements in Software Engineering SE5Software Requirements in Software Engineering SE5
Software Requirements in Software Engineering SE5
koolkampus
 
5.state diagrams
5.state diagrams5.state diagrams
5.state diagrams
APU
 

Tendances (20)

UNIFIED MODELING LANGUAGE
UNIFIED MODELING LANGUAGEUNIFIED MODELING LANGUAGE
UNIFIED MODELING LANGUAGE
 
Formal Specification in Software Engineering SE9
Formal Specification in Software Engineering SE9Formal Specification in Software Engineering SE9
Formal Specification in Software Engineering SE9
 
Architecture design in software engineering
Architecture design in software engineeringArchitecture design in software engineering
Architecture design in software engineering
 
UML Diagrams
UML DiagramsUML Diagrams
UML Diagrams
 
Uml in software engineering
Uml in software engineeringUml in software engineering
Uml in software engineering
 
Introduction to UML
Introduction to UMLIntroduction to UML
Introduction to UML
 
Uml class-diagram
Uml class-diagramUml class-diagram
Uml class-diagram
 
Software Requirements in Software Engineering SE5
Software Requirements in Software Engineering SE5Software Requirements in Software Engineering SE5
Software Requirements in Software Engineering SE5
 
Software Engineering by Pankaj Jalote
Software Engineering by Pankaj JaloteSoftware Engineering by Pankaj Jalote
Software Engineering by Pankaj Jalote
 
Design engineering
Design engineeringDesign engineering
Design engineering
 
Uml Common Mechanism
Uml Common MechanismUml Common Mechanism
Uml Common Mechanism
 
Object Oriented Analysis Design using UML
Object Oriented Analysis Design using UMLObject Oriented Analysis Design using UML
Object Oriented Analysis Design using UML
 
Ooad ppt
Ooad pptOoad ppt
Ooad ppt
 
Object oriented modeling and design
Object oriented modeling and designObject oriented modeling and design
Object oriented modeling and design
 
Incremental model
Incremental modelIncremental model
Incremental model
 
Software process
Software processSoftware process
Software process
 
Object Oriented Relationships
Object Oriented RelationshipsObject Oriented Relationships
Object Oriented Relationships
 
5.state diagrams
5.state diagrams5.state diagrams
5.state diagrams
 
Software design
Software designSoftware design
Software design
 
Spiral model presentation
Spiral model presentationSpiral model presentation
Spiral model presentation
 

Similaire à Object Oriented Design

Object oriented software engineering
Object oriented software engineeringObject oriented software engineering
Object oriented software engineering
Varsha Ajith
 
08 class and sequence diagrams
08   class and sequence diagrams08   class and sequence diagrams
08 class and sequence diagrams
kebsterz
 

Similaire à Object Oriented Design (20)

UNIT II STATIC UML DIAGRAMS.pptx
UNIT II STATIC UML DIAGRAMS.pptxUNIT II STATIC UML DIAGRAMS.pptx
UNIT II STATIC UML DIAGRAMS.pptx
 
Object oriented software engineering
Object oriented software engineeringObject oriented software engineering
Object oriented software engineering
 
ObjectOrientedSystems.ppt
ObjectOrientedSystems.pptObjectOrientedSystems.ppt
ObjectOrientedSystems.ppt
 
3_ObjectOrientedSystems.pptx
3_ObjectOrientedSystems.pptx3_ObjectOrientedSystems.pptx
3_ObjectOrientedSystems.pptx
 
SE18_Lec 06_Object Oriented Analysis and Design
SE18_Lec 06_Object Oriented Analysis and DesignSE18_Lec 06_Object Oriented Analysis and Design
SE18_Lec 06_Object Oriented Analysis and Design
 
SE_Lec 06_Object Oriented Analysis and Design
SE_Lec 06_Object Oriented Analysis and DesignSE_Lec 06_Object Oriented Analysis and Design
SE_Lec 06_Object Oriented Analysis and Design
 
08 class and sequence diagrams
08   class and sequence diagrams08   class and sequence diagrams
08 class and sequence diagrams
 
Uml - An Overview
Uml - An OverviewUml - An Overview
Uml - An Overview
 
Sda 7
Sda   7Sda   7
Sda 7
 
Object Oriented Programming In .Net
Object Oriented Programming In .NetObject Oriented Programming In .Net
Object Oriented Programming In .Net
 
Ooad 2
Ooad 2Ooad 2
Ooad 2
 
Ooad
OoadOoad
Ooad
 
OOP_Module 2.pptx
OOP_Module 2.pptxOOP_Module 2.pptx
OOP_Module 2.pptx
 
CS8592-OOAD-UNIT II-STATIC UML DIAGRAMS PPT
CS8592-OOAD-UNIT II-STATIC UML DIAGRAMS PPTCS8592-OOAD-UNIT II-STATIC UML DIAGRAMS PPT
CS8592-OOAD-UNIT II-STATIC UML DIAGRAMS PPT
 
Intro Uml
Intro UmlIntro Uml
Intro Uml
 
Ooad
OoadOoad
Ooad
 
Ch06
Ch06Ch06
Ch06
 
Jar chapter 2
Jar chapter 2Jar chapter 2
Jar chapter 2
 
Introduction to UML
Introduction to UMLIntroduction to UML
Introduction to UML
 
Bt8901 objective oriented systems1
Bt8901 objective oriented systems1Bt8901 objective oriented systems1
Bt8901 objective oriented systems1
 

Plus de Sudarsun Santhiappan

Essentials for a Budding IT professional
Essentials for a Budding IT professionalEssentials for a Budding IT professional
Essentials for a Budding IT professional
Sudarsun Santhiappan
 

Plus de Sudarsun Santhiappan (13)

Challenges in Large Scale Machine Learning
Challenges in Large Scale  Machine LearningChallenges in Large Scale  Machine Learning
Challenges in Large Scale Machine Learning
 
Software Patterns
Software PatternsSoftware Patterns
Software Patterns
 
Search Engine Demystified
Search Engine DemystifiedSearch Engine Demystified
Search Engine Demystified
 
Distributed Computing
Distributed ComputingDistributed Computing
Distributed Computing
 
Essentials for a Budding IT professional
Essentials for a Budding IT professionalEssentials for a Budding IT professional
Essentials for a Budding IT professional
 
What it takes to be the Best IT Trainer
What it takes to be the Best IT TrainerWhat it takes to be the Best IT Trainer
What it takes to be the Best IT Trainer
 
Using Behavioral Patterns In Treating Autistic
Using Behavioral Patterns In Treating AutisticUsing Behavioral Patterns In Treating Autistic
Using Behavioral Patterns In Treating Autistic
 
Topic Models Based Personalized Spam Filter
Topic Models Based Personalized Spam FilterTopic Models Based Personalized Spam Filter
Topic Models Based Personalized Spam Filter
 
Latent Semantic Indexing For Information Retrieval
Latent Semantic Indexing For Information RetrievalLatent Semantic Indexing For Information Retrieval
Latent Semantic Indexing For Information Retrieval
 
Audio And Video Over Internet
Audio And Video Over InternetAudio And Video Over Internet
Audio And Video Over Internet
 
Practical Network Security
Practical Network SecurityPractical Network Security
Practical Network Security
 
How To Do A Project
How To Do A ProjectHow To Do A Project
How To Do A Project
 
Ontology
OntologyOntology
Ontology
 

Dernier

Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Finding Java's Hidden Performance Traps @ DevoxxUK 2024Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Victor Rentea
 
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers:  A Deep Dive into Serverless Spatial Data and FMECloud Frontiers:  A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Safe Software
 
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers:  A Deep Dive into Serverless Spatial Data and FMECloud Frontiers:  A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Safe Software
 
Architecting Cloud Native Applications
Architecting Cloud Native ApplicationsArchitecting Cloud Native Applications
Architecting Cloud Native Applications
WSO2
 

Dernier (20)

Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Finding Java's Hidden Performance Traps @ DevoxxUK 2024Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Finding Java's Hidden Performance Traps @ DevoxxUK 2024
 
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers:  A Deep Dive into Serverless Spatial Data and FMECloud Frontiers:  A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
 
Navigating the Deluge_ Dubai Floods and the Resilience of Dubai International...
Navigating the Deluge_ Dubai Floods and the Resilience of Dubai International...Navigating the Deluge_ Dubai Floods and the Resilience of Dubai International...
Navigating the Deluge_ Dubai Floods and the Resilience of Dubai International...
 
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers:  A Deep Dive into Serverless Spatial Data and FMECloud Frontiers:  A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
 
CNIC Information System with Pakdata Cf In Pakistan
CNIC Information System with Pakdata Cf In PakistanCNIC Information System with Pakdata Cf In Pakistan
CNIC Information System with Pakdata Cf In Pakistan
 
JohnPollard-hybrid-app-RailsConf2024.pptx
JohnPollard-hybrid-app-RailsConf2024.pptxJohnPollard-hybrid-app-RailsConf2024.pptx
JohnPollard-hybrid-app-RailsConf2024.pptx
 
Architecting Cloud Native Applications
Architecting Cloud Native ApplicationsArchitecting Cloud Native Applications
Architecting Cloud Native Applications
 
DBX First Quarter 2024 Investor Presentation
DBX First Quarter 2024 Investor PresentationDBX First Quarter 2024 Investor Presentation
DBX First Quarter 2024 Investor Presentation
 
Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...
Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...
Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...
 
Rising Above_ Dubai Floods and the Fortitude of Dubai International Airport.pdf
Rising Above_ Dubai Floods and the Fortitude of Dubai International Airport.pdfRising Above_ Dubai Floods and the Fortitude of Dubai International Airport.pdf
Rising Above_ Dubai Floods and the Fortitude of Dubai International Airport.pdf
 
FWD Group - Insurer Innovation Award 2024
FWD Group - Insurer Innovation Award 2024FWD Group - Insurer Innovation Award 2024
FWD Group - Insurer Innovation Award 2024
 
Introduction to Multilingual Retrieval Augmented Generation (RAG)
Introduction to Multilingual Retrieval Augmented Generation (RAG)Introduction to Multilingual Retrieval Augmented Generation (RAG)
Introduction to Multilingual Retrieval Augmented Generation (RAG)
 
Apidays New York 2024 - The value of a flexible API Management solution for O...
Apidays New York 2024 - The value of a flexible API Management solution for O...Apidays New York 2024 - The value of a flexible API Management solution for O...
Apidays New York 2024 - The value of a flexible API Management solution for O...
 
TrustArc Webinar - Unlock the Power of AI-Driven Data Discovery
TrustArc Webinar - Unlock the Power of AI-Driven Data DiscoveryTrustArc Webinar - Unlock the Power of AI-Driven Data Discovery
TrustArc Webinar - Unlock the Power of AI-Driven Data Discovery
 
Introduction to use of FHIR Documents in ABDM
Introduction to use of FHIR Documents in ABDMIntroduction to use of FHIR Documents in ABDM
Introduction to use of FHIR Documents in ABDM
 
"I see eyes in my soup": How Delivery Hero implemented the safety system for ...
"I see eyes in my soup": How Delivery Hero implemented the safety system for ..."I see eyes in my soup": How Delivery Hero implemented the safety system for ...
"I see eyes in my soup": How Delivery Hero implemented the safety system for ...
 
ICT role in 21st century education and its challenges
ICT role in 21st century education and its challengesICT role in 21st century education and its challenges
ICT role in 21st century education and its challenges
 
Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...
Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...
Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...
 
EMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWER
EMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWEREMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWER
EMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWER
 
Corporate and higher education May webinar.pptx
Corporate and higher education May webinar.pptxCorporate and higher education May webinar.pptx
Corporate and higher education May webinar.pptx
 

Object Oriented Design

  • 1. Object Oriented Design Sudarsun S., M.Tech Director – R & D Checktronix India Pvt Ltd Chennai 600010
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 16.
  • 17.
  • 18.
  • 19.
  • 20.
  • 22. Weather station - data collection sequence
  • 23.
  • 24.
  • 25.
  • 27.
  • 28.
  • 29.
  • 31.
  • 32.
  • 33.
  • 34.
  • 35.
  • 36.
  • 37. Example class Car extends Vehicle { . . . private Tire[] tires; }
  • 38. Example UML Notation for Inheritance and Aggregation
  • 39.
  • 40. UML Relationship Symbols Open Dotted Dependency Diamond Solid Aggregation Triangle Dotted Interface Implementation Triangle Solid Inheritance Arrow Tip Line Style Symbol Relationship
  • 41.
  • 42.
  • 43. Attributes and Methods in UML Attributes and Methods in a Class Diagram
  • 44.
  • 45.
  • 46. Aggregation and Association An Association Relationship
  • 47.
  • 48.
  • 50.
  • 51.
  • 52.
  • 53.
  • 54.
  • 55.
  • 56.
  • 57. Printing an Invoice – UML Diagrams The Relationships Between the Invoice Classes
  • 58.
  • 59. Method Documentation – Invoice class /** Describes an invoice for a set of purchased products. */ public class Invoice { /** Adds a charge for a product to this invoice. @param aProduct the product that the customer ordered @param quantity the quantity of the product */ public void add(Product aProduct, int quantity) { } /** Formats the invoice. @return the formatted invoice */ public String format() { } }
  • 60. Method Documentation – LineItem class /** Describes a quantity of an article to purchase and its price. */ public class LineItem { /** Computes the total cost of this line item. @return the total price */ public double getTotalPrice() { } /** Formats this item. @return a formatted string of this line item */ public String format() { } }
  • 61. Method Documentation – Product class /** Describes a product with a description and a price. */ public class Product { /** Gets the product description. @return the description */ public String getDescription() { } /** Gets the product price. @return the unit price */ public double getPrice() { } }
  • 62. Method Documentation – Address class /** Describes a mailing address. */ public class Address { /** Formats the address. @return the address as a string with three lines */ public String format() { } }
  • 63.
  • 64.
  • 65.
  • 66.
  • 67.
  • 68.
  • 69.
  • 70.
  • 71.
  • 72.
  • 73.
  • 74.
  • 75.
  • 76.
  • 77.
  • 78.
  • 79. Patterns by Example: Multiple displays enabled by Observer A=10% B=40% C=30% D=20% Application data A B C D A D C B Relative Percentages Y 10 40 30 20 X 15 35 35 15 Z 10 40 30 20 A B C D Change notification Requests, modifications
  • 80.
  • 81. The Observer pattern observerState= subject  getState(); Subject attach (Observer) detach (Observer) Notify () Observer Update() Concrete Observer Update() observerState Concrete Subject GetState() SetState() subjectState observers subject For all x in observers{ x  Update(); }
  • 82.
  • 84.
  • 85. Facade Pattern: Problem Subsystem classes Client Classes Need to communicate with
  • 86. Facade Pattern: Solution Subsystem classes Fac ade Client Classes
  • 88.
  • 90.
  • 92.
  • 93. The Abstract Factory Pattern AbstractFactory CreateProductA() CreateProductB() ConcreteFactory1 Client ProductA1 ProductA2 AbstractProductA ProductB2 ProductB1 AbstractProductB ConcreteFactory2 CreateProductA() CreateProductB()
  • 94. Abstract Factory Example WidgetFactory CreateScrollbar() CreateWindow() Window ScrollBar WWidgetFactory MacWidgetFactory Client WWindow MacWindow MacScrollBar WScrollBar One for each standard.
  • 95.
  • 96.
  • 97.
  • 98.
  • 99.
  • 100. Changes with Rigidity The System Officially Rigid Area Where the change should be made Where the change must be made now Are we containing risk, or spreading rot?
  • 101.
  • 102. Increasing Risk Defects v. Cumulative Modifications Systems tend to become increasingly fragile over time. Intentional, planned partial rewrites may be necessary to sustain growth and maintenance. Changes Probability of introducing a bug 1.0
  • 103.
  • 104. The Trailer The Trailer
  • 105.
  • 106. What is the benefit of good DM? Interdependencies are managed, with firewalls separating aspects that need to vary independently. Fewer Trailers Slow the rot More Flexible Less fragile, the bugs are boxed in Easier to reuse Easier to make the right change
  • 107.
  • 108. First Version All designs start well The program is an overnight success! How could it be more simple, elegant, and maintainable? void copy(void) { int ch; while( (ch=ReadKeyboard()) != EOF) WritePrinter(ch); }
  • 109.
  • 110. Second Version Design bool GtapeReader = false; // remember to clear void copy(void) { int ch; while( (ch=GtapeReader ? ReadTape() : ReadKeyboard()) != EOF) WritePrinter(ch); }
  • 111. Third Version How unexpected! Requirements changed again! bool GtapeReader = false; Bool GtapePunch = false; // remember to clear void copy(void) { int ch; while( (ch=GtapeReader ? ReadTape() : ReadKeyboard()) != EOF) GtapePunch ? WritePunch(ch) : WritePrinter(ch); } It seems that sometimes we need to write to a paper tape punch. We’ve had this problem before, and just added a flag. Looks like it should work again.
  • 112. Example of a Good Design First and only version. void Copy() { int c; while( (c=getchar()) != EOF) putchar(c); } But wait! Aren’t we supposed to be learning OO design? This isn’t OO is it?
  • 113.
  • 114. Rephrased in OO interface Reader { char read(); } interface Writer { void write(char c); } public class Copy { Copy(Reader r, Writer w) { itsReader = r; itsWriter = w; } public void copy() { int c; while( (c==itsReader.read()) != EOF ) itsWriter.write(c); } private Reader itsReader; private Writer itsWriter; }
  • 115.
  • 116.
  • 117.
  • 118.
  • 119.
  • 120. Procedural (open) version enum ShapeType {circle, square}; struct Shape {enum ShapeType itsType;}; struct Circle { enum ShapeType itsType; double itsRadius; Point itsCenter; }; void DrawCircle(struct Circle*) struct Square { enum ShapeType itsType; double itsSide; Point itsTopLeft; }; void DrawSquare(struct Square*) #include <Shape.h> #include <Circle.h> #include <Square.h> typedef struct Shape* ShapePtr; void DrawAllShapes(ShapePtr list[], int n) { int i; for( i=0; i< n, i++ ) { ShapePtr s = list[i]; switch ( s->itsType ) { case square: DrawSquare((struct Square*)s); break; case circle: DrawCircle((struct Circle*)s); break; } } } Shape.h Circle.h Square.h DrawAllShapes.c
  • 121.
  • 122. A Closed Implementation Class Shape { public: virtual void Draw() const =0; }; #include <Shape.h> void DrawAllShapes(Shape* list[],int n) { for(int i=0; i< n; i++) list[i]->draw(); } Shape.h DrawAllShapes.cpp Circle.h Square.h Class Square: public Shape { public: virtual void Draw() const; }; Class Circle: public Shape { public: virtual void Draw() const; };
  • 123.
  • 124.
  • 125. Square/Rectangle A square is-a rectangle, right? So lets consider Square as a subtype of Rectangle. void Square::SetWidth(double w) { width = w; height = w; } void Square::SetHeight(double h) { width = h; height = h; } We can make it work: Uh, oh. This doesn’t quite seem to fit
  • 126.
  • 127.
  • 128.
  • 129.
  • 130.
  • 131. Dependency Inversion Principle Details should depend on abstractions. Abstractions should not depend on details. V.
  • 132.
  • 133. Procedural vs. OO Architecture Procedural Architecture Object-Oriented Architecture
  • 134. DIP Applied on Example Copy Reader Writer Keyboard Reader Printer Writer class Reader { public: virtual int read()=0; }; class Writer { public: virtual void write(int)=0; }; void Copy(Reader& r, Writer& w){ int c; while((c = r.read()) != EOF) w.write(c); } Disk Writer
  • 135.
  • 136. Interface Pollution by “collection” Distinct clients of our class have distinct interface needs.
  • 139. A Segregated ATM UI Example
  • 141.
  • 142.