Fundamentals of Object Oriented Programming Training Notes by James Portis
Fundamentals of Object Oriented Programming Training Notes by James Portis

Object Oriented Programming

  • As programs got bigger and bigger, procedural API’s couldn’t scale up
    • OOP became rage in 80’s
  • Object orientation is programming paradigm
    • not a language, the languages are
      • C++, C#, Java, JavaScript, Perl, PHP, Python, Objective-C, Ruby, VB.NET, and others
  • What is an object
    • Object orientation was invented to make thinking and solving programming problems more link thinking about and solving real world problems
    • in real world, objects are tough to define besides “things”, which is a wishy-washy proposal
      • Objects in real world
        • they have identity, in which one object is not necessarily all of the objects in the universe and not the same as another object (even if it is a copy, they are not the same object).
        • have differing levels of complexity
        • can contain other objects
        • have inherent properties or attributes
          • attributes describe current state of object
          • most objects have multiple attributes
        • objects have behaviors, specific to type of object
      • Computing Objects
        • can be described by the same ideas
          • identity
          • attribute
          • behavior
        • in computer program, objects are self contained
        • objects are not always physical items or necessarily visible
        • to decide if something is an object
          • is the thing a noun
            • ex. in an event management app, an event (which is a noun) would be an object
          • can also ask if you would put the word “the” before object
            • ex. the mug, the apple, the event
            • wouldn’t say – the saving, the exploding, the printing
              • these are verbs and would be mapped to behaviors of objects, not the objects themselves
  • What is a class
    • objects and classes go hand in hand
      • can’t talk about one without dealing with the other
    • the point of OOP isn’t about objects, it’s about classes
      • we use classes to create objects
    • class describes what object will be, but not the object itself
      • class provides a blueprint of what the object will be
        • if you want a house, you start with the blueprint
    • programmers write the class, and use the class to create the object
    • one class can build multiple objects
      • like one blueprint can guide the building of multiple houses
    • Class always comes first
    • Components of a class
      • name – describes what the class is. (Identity)
        • ex. employee, bankAccount, Event, Player, Document
        • name can also be called “type”
      • attributes – what describes it
        • ex. width, height, scope, fileType
        • attributes can also be called “properties” or “data”
      • behavior – what can it do?
        • ex. play, search, save, print
        • behavior can also be called “operations”
        • when written in code, behaviors are called methods
          • methods are functions that belong to a class
      • the above is a class diagram, it shows class name in bold, attributes and data types in 2nd box, and behaviors or operations that the class can invoke in 3rd box
        • given the class definitions, we can create objects
          • called an instance of a class
          • for above example, can create instances of multiple customers with different names and locations
      • and object is an instance of a particular class
        • process of creating objects is called instantiation
        • each object has its own identity, independent of other objects, and it’s own data (attributes) and it’s own behavior
    • Existing classes in OO (object oriented) languages
      • Most OOP languages have pre-written generic classes
        • at minimum: strings, dates, collections, file I/O, networking
  • 4 fundamental ideas in OOP – 4 things to keep in mind when creating classes – APIE
    • Abstraction –
      • focus on the essential qualities of an object, not just on one specific example
        • in real world, if I say table, you know what I am talking about, even if the table you are thinking of is different than the table in my mind
      • ignores irrelevant or unimportant information
      • means we can have an idea or concept that is separate from any other instance of an object
        • don’t make a class for Joe’s bank account or Jan’s bank account, make a class for bank account of which jan and joe’s accounts are objects
          • data or attributes of class will be what is shared between accounts
            • each will have accountNumber, balance, timeCreated, etc.
              • IMPORTANT – for OOP, if any attribute is not critical for class, omit it
                • ex. all bank accounts have a timeCreated, however, if this information isn’t useful to my app, then I can omit this attribute from my class
      • Abstraction is the foundation of OOP
    • Polymorphism
      • means “many forms”
      • allows us to do correct behavior, even if what we are working with can take many forms
        • ex. if evaluating a + b
          • if a and b are integers, they are added
            • a = 7, b = 13 = resolves to 20
          • if a and b are strings, concatenates them
            • a = “Hello”, b = “World” – resolves to “HelloWorld”
        • can get complicated
          • if creating bank account app, can have bankAccount class and CheckingAccount and SavingsAccount subclasses
            • if, for example, withdrawing from savingsAccount came with a penalty, then you create new behavior for withdrawing in SavingsAccount subclass
              • however, there is already a withdraw behavior, so new behavior is said to override the parents behavior
              • can inherit behavior when useful, but can override behavior if necessary
                • FINALLY MAKES SENSE!! Now, regardless of which account you are dealing with, can perform withdraw() behavior and know that the proper process will be performed on object, depending on type
                  • perform the same withdraw() method on checking and savings, but savings will be a different method with the same name in the subclass
                  • allows us to do the right thing at the right time
                  • most classes won’t need polymorphism, you’ll notice situations where you need it when it happens
    • Inheritance
      • can create a new class and base it on an existing class
      • ChildClass inherits from ParentClass
        • new class has everything that parent class has, all attributes and behaviors without having to code them in
        • in this arrangement, ParentClass is called a superclass and childClass is subclass
        • subclasses add new attributes and behaviors, but pull in all attributes and behaviors for superclass
          • try to only inherit from one superclass (C++ offers ability to inherit from multiple super classes)
    • Encapsulation
      • the idea of surrounding something
        • to keep contents together
        • to protect contents
      • refers to idea of keeping attributes and behaviors bundled together in same class
        • also want to restrict access to inner workings of class or any objects based on that class
          • this is called information hiding or data hiding
            • principal is that object should not reveal anything about itself besides what is absolutely necessary for other parts of app to work
              • if making bank application, don’t want anything to affect account balance without going through deposit() or withdrawl() behavior
                • this is called black boxing – closing off inner-workings of object besides necessary I/O components
              • this reduces dependencies between different parts of application
                • a change in one place won’t require many changes in other places
            • rule it so hide as much as possible
  • Object Oriented Design Process
    • entire point is to decide what classes you need and what they should do
    • 1 – Gather Requirements
      • What does app need to do, what problem are we trying to solve.  WRITE IT DOWN
      • Decides what app is required to do
      • Functional Requirements – what does it do?
        • features and capabilities
        • Example – System MUST display the heart rate, temperature of a patient connected to the patient monitor
        • Example – Application MUST allow user to search by customer name or order number
      • Non-Functional Requirements – what else?
        • help documentation
        • legal requirements – if working with sensitive data, what legal requirements are there
        • Performance requirements – how many users, etc.
        • support requirements – if app fails, then what?
        • security requirements
        • Example – System MUST respond to searches within 2 seconds
        • Example – Help Desk MUST be available during business hours
        • Example – MUST comply with relevant legal regulations
      • Don’t focus of the 100 different things the app could do, for right now, what MUST the app do to work at it’s minimal level – MOST IMPORTANT IDEA
        • Don’t be exhaustive, won’t write this once and freeze it in time, will reinvent often
      • Want these statements to be short and succinct, getting directly to the point of the application
      • Requirement Analysis is entire field on it’s own, can use FURPS or FURPS+
        • Functional Requirements
        • Usability Requirements
        • Reliability Requirements
        • Performance Requirements
        • Supportability Requirements
        • Design Requirements – Constraints
        • Implementation Requirements – what is language?  what standards?
        • Interface Requirements – not to user interface, but external systems
        • Physical Requirements – physical constraints
    • 2 – Describe the App
      • Build a simple narrative in conversational language for how people will use the app
      • can create mockup of UI at this step, but that can also become a distraction
      • In this step, switch to user focus
        • how does user accomplish specific goal in application
        • typical user should be able to read and understand descriptions
      • Use-Case – 3 components
        • Title – what is the goal?
          • Short phrase with active verb
            • register new member
            • transfer funds
            • purchase items
        • Actor – who desires it?
          • can be user, customer, member, administrator, or another computer system
          • these are anything with behavior that exists outside of application but still wants to accomplish a goal
          • ask these questions
            • does app need to interact with other computer systems?
            • do we need to distinguish between roles or security groups?
            • do we need different actions for different job titles or departments
          • use cases often involve multiple actors
            • primary actors
              • not necessarily most important
              • one that initiates use case
            • secondary actors
              • everyone else is secondary actor
          • sometimes actors will suggest goals, and sometimes goals will suggest actors
          • remember that goals don’t always succeed
            • start by describing successful steps
            • but always think about alternative flows
        • Scenario – how is it accomplished?
          • Details of accomplishing one goal, can be written as paragraph or as steps (numbered list)
            • Step 1 – Customer chooses to enter checkout
            • Step 2 – Customer is shown confirmation page
            • etc.
            • can also add extensions in certain cases
              • Describe steps for out of stock
            • can also describe preconditions
              • customer has added at least one item to cart
          • think user-focused goals
            • user doesn’t want to log in as goal, they want to do something once logged in
              • logging in is part of use-cases, not use-case in itself
            • don’t make goals to broad
              • write book or merge organization isn’t directed enough, these goals require multiple interactions with system, not a single use case
            • Emphasize the goal of a single encounter with the system
          • When writing scenario, use active voice and omit needless words or phrases
            • Use – customer provides payment information
            • Not – system is provided with payment information by customer
          • Focus on intentions and keep user interface out of scenarios
          • Ask these questions in case something was missed during scenario development
            • Who does system administration tasks?
            • Who manages users and security?
            • What happens if the system fails?
            • Is anyone looking at performance metrics?
        • There are many ways to describe use-cases, with a fully dressed being the extreme example of defining everything
          • for large, world-wide enterprises this makes sense, for small applications don’t let formality become enemy of progress
        • Once you have use-cases written, and only after they are written, can use use-case diagram to reinforce ideas
          • not a diagram of a single use case
          • almost always a diagram of a set of use cases with multiple actors
          • exists to get overview and see how they interact in context
          • use stick figures to represent actos
          • use ovals around titles
          • use box as boundary of application, anything inside is part of system
          • then draw lines between users and use cases they will interact with
          • represent external actors on right of box
          • primary actors on the left, secondary actors on the right
          • does not refer to sequence, but can if there is normal workflow that will be easy to diagram
      • User-Story
        • simpler and shorter than use case
        • describes small scenario from user focus
        • unlike use case, the story is written as one or two sentences on index cards
        • Follow a formal
          • As a (type of user), I want (goal) so that (reason)
          • focus on one specific goal for one specific user
        • can quickly brainstorm a lot of user stories, even very particular ones
        • user stories vs use cases
          • stories are
            • short
            • one goal, no details
            • informal
            • used as placeholders for conversations about goals
          • cases are
            • long
            • multiple goals and details
            • casual to very formal
            • used as a record of your conversations about goals
        • can use one or the other and in many cases, both
    • 3 – Identify the Main Objects
      • This is starting point of identifying actual classes
      • use the stories to pick out the most important ideas, concepts, and things and discard what is irrelevant
      • Domain Modeling
        • a conceptual model of system
        • identifying the most important objects in system
          • what are things in application we need to be aware of
      • Step 1 – Gather use case or user stories
      • Step 2 – Parse through use case for nouns and make list or underline them
        • these are possible objects
        • don’t analyse or judge candidate objects, just mark them
      • Step 3 – With list of nouns, scan for obvious duplicates and omit
      • Step 4 – Scan list for attributes, for example
        • order and order number are both found in list, but order number only makes sense as an attribute for the order class, so can omit order number and remember to place as attribute
      • Step 5 – Make quick diagram of left-over nouns and place them in boxes
      • Step 6 – With diagram built, use lines to represent relationships between objects
        • don’t describe every connect, just most interesting
        • then place short descriptive words to describe relationship
          • order and payment are related in that order is paid by payment
            • write “paid by” above or below line documenting the relationship
          • shopping cart “contains” items
          • customer “places” order
        • then use relationship arguments to further describe
          • 1 > * is one to many
        • Be careful with background in relational database design, don’t want to carefully describe keys and all many to many relationships, just looking for things that jump out as important
          • As with other parts of beginning this process, DONT OVERTHINK IT!
    • 4 – Describe the Interactions
      • formally describe interactions between objects
        • customer needs to open a bank account
        • spaceship needs to explode when hitting asteroid, etc
      • Useful to understand the responsibilities of different objects and necessary behaviors, also order of operations
      • can create sequence diagram at this step
      • Identifying Responsibilities
        • Step 1 – Gather the use cases and user stories
        • Step 2 – Look for verbs, underline and copy to list
          • always remember that objects are responsible for themselves
            • if check order status is verb, the responsible party seems to be the customer, whom would perform the status check
              • this is incorrect, don’t put coding for checking order status in customer class
                • customer should ask order for order status, while order is responsible for order status
              • don’t give too much behavior to actor, the system is responsible for most processing where the actor is responsible for querying application and asking for processes to be run and returned to actor
              • AVOID GLOBAL MASTER OBJECTS, responsibilities should be distributed between objects
            • CRC Cards
              • Class Responsibility Collaboration
                • represents on class
                • class name at top
                • responsibilities on left of card
                • collaborators on right ⅓ or card
    • 5- Create a Class Diagram
      • a visual representation of the classes you need
        • be specific
      • no code, do everything on paper
      • Use UML Class Diagram specifications (noted above)
        • have primary attributes and primary operations
        • classes are named in singular and uppercase first letter
        • won’t know all attributes yet, but should know primary
          • name attributes in Camo-case or Pascal-case, lower case first word, capital next words with no space
          • also write the suggested data type to take diagram to next level, use colon then string, boolean, date, integer, etc.
          • can assign a default value if necessary with = sign and quotes around the default value
            • name: String = “New Product”
        • Write the operations in the third vertical box with Pascal-case
          • if we know that methods will interact with attributes (send or receive data to/from attributes)
            • use get and set as part of operation name
              • getName or setActive
            • put any parameters in parenthesis after the operation name
              • setActive (Boolean)
            • use colon plus return type to designate the data type you expect to return from operation
              • getName () : String
        • To indicate visibility of attributes and operations in class, use + or – signs to show whether attribute or operation should be hidden
          • – name: String = “New Product” – indicates that the name attribute should be private to the class, not directly accessible from other objects
          • + getName() : String – indicates that the operation will be public and directly accessible
            • if operation will only be used internally and doesn’t need to be acted upon, make object private
            • leave as much private as possible and only make things public if you know another object has to use attribute or method
        • Can add notes to the diagram with a box on the right of the diagram with a folded top-right corner
          • write your note in the box
          • use dashed line to connect note to desired object
  • Diagramming Techniques
    • Use Unified Modeling Language (UML) for diagramming
    • not programming language, it is a graphical notation language
    • describes of 12 different, diagrams, only interested in a few options
      • class diagram, 3 main parts, class name, attributes, and methods in three vertical boxes
      • For most developers, knowing a little UML is better than knowing a bunch of UML
        • don’t overemphasize diagrams
        • use them as support system for brain
        • focus first on using paper or whiteboard
  • Object Lifetimes
    • how are objects created, what happens when they are created, how are they deleted
    • making an object is instantiation
      • for Java:  Customer fred = new Customer()
        • creates new customer object in the customer class, naming it fred
        • new keyword is responsible for creating object
          • computer is allocating a little memory for new object and initializing all variables, then returning reference to object
      • use Constructors to be a part of the instantiation process
        • when creating new object without constructors, new object is created (called fred in example above) but object name (String attribute) is null and shieldStrength (Int attribute) is 0 (default)
        • constructors make sure than any variables that are related to object are immediately set upon the instantiation of the object
        • In Java, constructor methods are indicated by writing the method inside the class with the same name as the class
          • public Spaceship() {
            name = “Unnamed Ship”;
            shieldStrength = 100;
            }

            • if placed with public class Spaceship, this method will set the initial variables for any newly created spaceships
            • Constructors take no arguments and return nothing
            • now use basic instantiation to create object with already set attributes
        • in UML class diagram, indicate constructors by writing a method in operations box with the same name as the class
        • Overloading Constructors
          • if you want multiple constructors whom handle data differently, can create a constructor that takes arguments and sets different initial attribute values
            • // overloaded constructor
              public Spaceship(String n) {
              name = n;
              shieldStrength = 200;
              }

              • this creates a constructor that will take a string labeled “n” and set the object name to that string, also doubles shields
            • you then modify your instantiation
              • Spaceship excelsior = new Spaceship(“Excelsior 2”);
                • this creates object: excelsior, with name: Excelsior 2 and shieldStrength: 200
          • these give you flexibility and allow you to pass in data during instantiation
        • in UML class diagram, overloaded constructors are indicated by writing a method with the same class name but with an accepted data type
          • Spaceship(String) vs. Spaceship()
      • Destructors / Finalizers
        • method that is called when object is no longer needed and can be disposed / deleted / deallocated / released
        • these are not needed as often as constructors, but they have their uses
          • used if an object is holding a resource and I want to make sure that object is released before connection is destroyed
    • Static or Shared Members
      • variables that are shared across all objects in class
      • for example, if savings accounts have the same interest rates for savings accounts, you wouldn’t want each savings account to have it’s own set variable for interest rates, instead you would have a static interest rate variable which is set at the class level and applies to all objects created in that class
        • called class level variable / attribute vs. instance-level variable
        • to create a class level variable in Java, inside class write
          • // static variables
            public static float interestRate;

            • public indicates visibility
            • static indicates variable type
            • float indicates floating point integer
            • interestRate indicates variable name
        • by using static variables, doesn’t mean variables do not change, it means that changes are shared across all objects of that class
          • not static as unchanging, but static as opposed to dynamic
        • to access a variable of an object, would use the actual name of the object appended to the name of the variable
          • joeAcct.accountNumber and aliceAcct.accountNumber
            • these would return the account number for Joe’s Account and Alice’s account
        • to access variable at class level (shared), use class name appended with variable name
          • SavingsAccount.interestRate = .85;
            • this sets interest rate for all objects in class to .85
      • can also create static methods that exist at class level as opposed to methods existing at object level
        • // public static methods
          public static setInterestRate(float r) {
          // add code to lag any change
          interestRate = r;
          }

          public static getInterestRate() {
          return interestRate;
          }

          • static methods can only access static variables
      • in UML, static members (attributes and operations) are identified with underlines
        • interestRate
      • most classes will be composed of mainly instance level members but static members can be useful depending on the situation
  • Understanding Inheritance
    • in most OOP languages, we are using inheritance all the time
    • inheritance describes an “is a” relationship between objects
      • a car is a vehicle
      • a bus is a vehicle
      • a car is a bus – not right
      • can have multiple levels to inheritance
        • a prius is a car is a vehicle
      • inheritance is taking this form of abstraction which we do in everyday life and bringing it to the world or programming
      • allows us to identify if there are shared attributes between objects
    • in UML, inheritance is shown as open arrow directing class back to parent class
    • child class automatically has all attributes and behaviors from parent class
      • then extra information is added or sometimes we want to change attributes and behaviors that we are inheriting
        • OOP languages often allow for child class to change attributes or methods as they are inherited from parent class
          • this is called overriding
    • it is common for noobs to overuse inheritance and have too many levels for different classes, avoid this
      • don’t try to find inheritance, it will announce itself naturally
      • check again if going beyond one or two level of inheritance
    • most everything in OOP inherits from a base “object” class, with multiple trees of decreasingly vague children classes
    • Abstract Class – if parent class will never actually be instantiated, called an abstract class
      • ex. CheckingAccount and SavingsAccount are children of BankAccount, but the only classes getting instantiated are checking and savings, not the BankAccount class itself
        • the parent class exists purely for the reason of being inherited
      • can mark class as abstract (in Java use abstract class BankAccount)
        • means language won’t allow object to be instantiated from class
      • classes than can be instantiated are Concrete Classes
    • Understanding Interface
      • overused word, in this reference does not mean user interface
      • Interface is very similar to class but has no functionality or behavior, it is just a list of method signatures
      • interface Printable {

        // method signatures
        void print();
        void printToPDF(String filename);

        }

        • not allowed to put functionality inside interface
      • Interfaces are set up, then can create classes that use interface
        • class ExampleClass implements Printable
          • this means that we are promising to create methods with certain names, listed previously
          • must then provide methods of a particular name
            • class ExampleClass implements Printable {

              // method bodies
              public void print() {
              // write method here
              }
              }

              • now other parts of application can make decisions based on interfaces
              • can ask if certain objects support interfaces, and if they do, can perform methods found in implementation class without even knowing what that implementation is
        • developers prefer to use interfaces to construct formal list of methods as opposed to inheritance
          • “Program to an interface, not an implementation”
          • interfaces are more future friendly as you are not pulling in a bunch of methods that might not be applicable to an object
    • Aggregation
      • describes a “has a” relationship
        • a customer “has a” address
          • implicitly can be used to describe one or many
        • in UML, use a diamond on the side of the line that is the container element
        • aggregation is very common and is often unnecessary to document unless the relationship is interesting
    • Composition
      • a more specific form of aggregation that implies ownership
      • same as above, but if owning object is destroyed, so is contained objects
        • a document “has a” page
          • but that page or pages belongs to that document, so if the document is trashed, all associated page objects should be deleted
          • also says that page objects aren’t associated with any other class
        • composition is usually worth showing on your diagrams
  • Behavioral Diagrams in UML
    • Sequence Diagrams
      • used to show one particular interaction between a few objects in a single scenario
      • only sequence the important interactions, and don’t get too granular
          • use : then className to identify an instance of a class
          • vertical dotted lines represent timelines
          • now list messages that are passed between objects
          • solid arrow with full head are requests
          • dashed arrows with line heads are responses
          • boxes in vertical lines represent processing being done by application for object
          • in example
            • a checkEmail request is sent to computer
  • Best to do diagram work on paper first, but there are tools to help
    • Diagramming Tools – Visio or OmniGraffle
    • Web Based – gliffy.com or creately.com or lucidchart.com
    • Programming Tools – Visual Studio, Eclipse with UMLTools
    • Commercial Products – Altova UModel, Sparx Enterprise Architect, Visual Paradigm
    • Open-Source – ArgoUML, Dia
  • Design Patterns
    • Well tested solutions to common programming problems that occur again and again
    • best practices for how to arrange classes to make application work
    • best reference is Design Patterns: Elements of Reusable Object-Oriented Software
      • called Gang of Four book
      • breaks patterns into 4 groups
        • Creational Patterns – approaches for dealing with object creation
          • abstract factory
          • builder
          • factory method
          • prototype
          • singleton – ensure that a class only has one instance and provide only one way to access instance
        • Structural Patterns – approaches for class design, how to create extra functionality
          • adapter
          • bridge
          • composite
          • decorator
          • facade
          • flyweight
          • proxy
        • Behavioral Patterns – approaches for communicating between objects
          • Chain of responsibility
          • command
          • interpreter
          • iterator
          • mediator
          • memento – handles “undo” in an object in a way that doesn’t violate encapsulation
          • observer
          • state
          • strategy
          • template method
          • visitor
  • Object Oriented Development Principles
    • General Development principles
      • DRY – Don’t Repeat Yourself
        • don’t copy and paste identical chunks of code, encapsulate them and share them between objects
      • YAGNI – You Ain’t Gonna Need It
        • solve the problems that you know exist, don’t spend time writing speculative code for problems you might not have
      • Code Smell – refers to how well the code was written, relative to best practices
        • long methods – long methods should be broken into sets of much shorter methods
        • very short or long identifiers – i is used for iteration, but shouldn’t find variables like “a” or “b” or “abcdefghijklmnopqrstuvwxyz” in code
        • pointless comments – code should be commented and well written
        • god object – one object that tries to do everything in program
        • feature envy – if class seems to do little beyond inherit features from other class, you have problem
    • SOLID Principles
      • S – Single Responsibility Principle
        • an object should have one primary responsibility, one reason to exist, and that reason should exist entire in one class
      • O – Open / Closed Principle
        • class should be open to extension, but closed to modification
        • if have working code and need to add feature, do this be adding new code and extending old, not rewriting old code
      • L – Liskov Substitution Principle
        • derived classes must be substitutable for their base classes
        • put another way – all children must be treated equally, no exception for dealing with certain children
      • I – Interface Segregation Principle
        • Multiple specific interfaces are better than any one general purpose interface
        • no class should be forced to support huge lists of methods that don’t relate directly to the class itself
      • D – Dependency Inversion Principle
        • Depend on abstractions, not on concretions
        • minimize dependencies between objects
        • hardest to grasp, in real world it means creating blanket objects that can support multiple subclasses should you need them, but not too many that it violates other principles
        • refer to training video when needing further help with this concept as it makes sense but can be easy to overdo
    • GRASP Principles
      • General Responsibility Assignment Software Patterns
      • takes more of a responsibility focus
        • who does what
      • 9 ideas
        • Creator
          • who is responsible for creating object?
          • does one object contain another?
          • does one object closely use another, or make another object?
        • Controller
          • Don’t connect user interface elements directly to business objects
          • don’t want UI users to need to understand business objects, or vice versa
          • create a controller using Model View Controller design pattern to handle communication between business process and user interface elements
        • Pure Fabrication
          • when the behavior does not belong anywhere else, create a new class to handle it
        • Information Expert
          • Assign the responsibility to the class that has the most information to fulfill it
          • classes are responsible for themselves
        • High Cohesion
          • cohesion is a measure of how focus the internal behavior of a class is
          • are all behaviors related to class’ responsibility?
          • we want high cohesion
        • Indirection
          • to reduce coupling between objects, introduce an intermediate object
          • if 4 objects need to speak with each other, too many connects between objects, use indirect object between them to handle communication, so now only 4 lines going from each object to new indirect object
        • Low Coupling
          • coupling is the level of dependencies between objects
          • reduce the amount of required connections between objects
          • there will be a minimum necessary
          • we want low coupling
        • Polymorphism
          • Automatically correct behavior based on type
        • Protected Variation
          • how to design a system so that changes and variations to the system will not reduce functionality and performance
          • important to identify the most likely points of change
  • More Info
    • Software Requirements by Carl Weigars
    • Writing Effective Use Cases by Allister Copen
    • User Stories Applied by Mike Cohen
    • URL Distilled by Martin Fowler
    • Refactoring by Martin Fowler
    • Head First Design Patterns