OO Analysis and Design Tips

  • General overview
  • Meaning of great software:
    • First, develop software that the customer needs and satisfy requirements
    • Second, apply basic OO principles to add flexibility (OOD)
      • Like duplicate code
      • Bad class design
    • Third, strive for maintainable, reusable design (DP)
  • Object Characteristics:
    • Objects should do what their names indicate: if I’m a plan I shouldn’t contain method GetTicket
    • Each object should represent a single concept: like ball! This could be basketball of football
    • Unused properties are dead giveaway:
      • If you have a field that is rarely has values. Why this property is a part from this object?
  • OOD:
    • Keep your objects well encapsulated
  • Design Pattern:
    • When try to edit your code you should modify the min number of classes
    • With min number of code lines!
    • Explain the principle Loosely Coupled Objects:
      • Separation of objects jobs so each one do its task separately and independently
  • Customers/Programmer Golden Rules:
    • Customers are satisfied when their apps work
    • Customers are satisfied when their apps keep working
    • Customers are satisfied when their apps upgraded
    • Programmers are satisfied when their apps reused
      • (Open-Closed-Principle (OCP) & Single-Responsibility-Principle (SRP))
    • Programmers are satisfied when their apps flexible -> Software Architects
  • Notes:
    • Encapsulation is breaking your application is logical parts
    • Find parts that could change and separate them from the stable parts
  • Gathering Requirements
  • What exactly is a requirement?
    • It’s a specific thing your system has to do to work correctly
  • When you are coming to requirements best thing to do is “let the customer talk”
    • Take care of what the system should do rather than how to do it
  • Make sure that the system could work although unexpected errors appear
  • After understanding the system and determine requirements, think under negative thinking
  • What is Main path and alternative path? What are the differences bettween them?
  • Requirements Should meet:
    • Ensure that the system works like customer expect
    • Covers all steps in the use cases
    • Use your use cases to recover point ur customers didn’t tell you
  • Characteristics of good use case:
    • Starting Condition
    • Stopping Condition
    • External Initiator
    • Clear Value
  • Chapter # 3:
    • Rules # 1: The customer is always right: D
    • Chapter keywords:
      • Scenario
  • Chapter # 4:
    • Your software should work in real world not perfect world
    • Analysis helps you ensure your system works in a real world context
    • Analysis Steps:
      • Identify the problem
      • Plan a solution
    • Delegation shields your objects from implementation changes to other objects in your software
    • Textual Analysis:
      • Looking at the nouns ( and verbs) in your use case to figure out classes and methods
    • Verbs in the use case are usually methods inside classes
    • Keywords:
      • Real-world context, peal-world context, Textual Analysis, Association
  • Chapter # 5:
    • Good design = flexible software
    • Keywords: Abstract Class, concrete, generalization, aggregation
    • Rule: Always favor coding to the interface not the implementation
    • Using a Map Data Structure to store variable properties
    • cohesive class: class that does one thing really well and doesn’t try to do or be something else
    • Keywords: cohesive class
  • Chapter # 7:
    • Commonality
    • Variability
  • OO Tips:
    • Avoid duplicate code
    • Objects should be loosely coupled:
      • objects are independent on each other
      • Change of an object doesn’t require bench of changes to other objects!
    • Classes shouldn’t store living things unless the system is going to store long-term information about them
    • Class Diagram Helps:
      • If there’s a mistake you can figure out it before writing actual code and fix it in the drawing
    • Using a Map Data Structure to store variable properties
    • Most good designs come from analysis of bad designs
    • It’s not recommended to add a new class with a constructor only!
    • To test your software flexibility:
      • How many classes did you have to add?
      • How many classes did you have to change?
  • OO Principles:
    • Encapsulate what varies
    • Always favor coding to the interface not the implementation
    • Each class has one responsibility

The more cohesive your software is, looser the coupling between classes

Design Patterns Tips

  • Chapter One:

    • The original fundamental design patterns were called GoF patterns
    • Don’t inherited unusable behavior or attribute
    • Identify the aspects of your application that vary and separate them from what stays the same
    • All design patterns provide a way to let some part of a system vary independently of all other parts
    • Assign the concrete implementation object at run time
    • Changing type at run time via interfaces (references)
    • Strategy Pattern: defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it
    • Patterns allow you to say more with less
    • One of the secrets to creating maintainable OO Systems is thinking about how they might change in the future
    • OO Principles:

      • Encapsulate what various
      • Favor composition over inheritance
      • Program to an interface not an implementation
    • Good OO designers are reusable, extensible and maintainable
    • Patterns don’t give you code; they give you general solutions to design problems. You apply them to your specific application
    • Patterns aren’t invented they are discovered
    • Patterns provide a shared language that can maximize the value of your communication with other developers
  • Chapter Two:

    • If you program for interface not implementation your code could be extendible dynamically
    • Publishers + Subscribers = Observer Pattern
    • Publisher is called SUBJECT and the subscribers are called OBSERVERS
    • You can find an OBJECT that also is an OBSERVER
    • Observer Pattern: defines one-to-many dependency between objects so that when one object changes state, all of it’s dependents are notified and updated automatically
    • Strive for loosely coupled designs between objects that interact
    • Loosely coupled designs allow us to build flexible OO systems that can handle change because they minimize the interdependency between objects
    • You can send the OBJECT in the update method in order to enhance any new measurements to the application
    • Don’t depend on a specific order of notification for your observers
    • OO Principles:

      • Strive for loosely coupled designs between objects that interact
  • Chapter Three:

  • Classes should be open for extension and closed for modifications
  • Decorator Pattern:

  • Attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality
  • Decorators have the same supertype as the objects they decorate.
  • You can use one or more decorators to wrap an object

Design Patterns an Introduction

  • After you finish this article you should be able to:

    • Know what are design patterns?
    • Define good solutions
    • Design problem in a context
  • Definition:

    • A design pattern is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander and has been adapted for various other disciplines
    • An organized collection of design patterns that relate to a particular field is called a pattern language
  • Defining ‘good’ Solution:

    • A pattern must explain:

      • why a particular situation causes problems
      • And why the proposed solution is considered a good one
    • Alexander describes common design problems as arising from "conflicting forces" — such as the conflict between wanting a room to be sunny and wanting it not to overheat on summer afternoons. A pattern would not tell the designer how many windows to put in the room; instead, it would propose a set of values to guide the designer toward a decision that is best for their particular application. Alexander, for example, suggests that enough windows should be included to direct light all around the room. He considers this a good solution because he believes it increases the enjoyment of the room by its occupants. Other authors might come to different conclusions, if they place higher value on heating costs, or material costs. These values, used by the pattern’s author to determine which solution is "best", must also be documented within the pattern
  • Design Problems in a Context:

  • A pattern must also explain when it is applicable. Since two houses may be very different from each other, a design pattern for houses must be broad enough to apply to both of them, but not so vague (مبهم) that it doesn’t help the designer make decisions
  • The range of situations in which a pattern can be used is called its context. Some examples might be "all houses", "all two-story houses", or "all places where people spend time." The context must be documented within the pattern
  • For instance, in Alexander’s work, bus stops and waiting rooms in a surgery are both part of the context for the pattern "A PLACE TO WAIT"