Object Oriented Design

• This is chapter 5.
  • It is VERY short. Read it.
  • If you want to put off reading Relationships you may.
• He states that OO design is concerned with "What are the (real-world) object that I am modeling?"
  • I would discard real-world
• Procedural vs Object Oriented programming
  • Functional decomposition - what are the tasks.
  • Object oriented - what are the objects that solve this problem?
• In 230 you might have learned that objects have
  • Attributes: the data
  • Responsibilities: The methods.
  • You sometimes see a comment about "message passing", but this is really just a function call, and the message is the parameters or the return value.
• In our text he describes an object as having
  • Attributes are divided somewhat into:
    • Components, or other objects that are more basic building blocks of our object.
    • Properties (variables and their values),
  • Behaviors
• I think it is essential that an object have both methods and attributes.
  • Something with only methods is a function or algorithm.
  • Something with only data is a variable.
• I read somewhere that you need to make sure that your classes have clear, sharp boundaries for their responsibilities.
  • This will be different for different designers.
  • What does a bug do in our program?
    • Is a bug essentially the entire player?
      • Does a bug take a turn?
    • Is the bug just an array?
    • Is the bug an entity that is responsible for
      • Determining if it is complete.
      • Determining if it has/needs a part?
      • Adding a part to the collection?
  • Whatever you decide, you need to incorporate:
    • Abstraction (interface/implementation)
      • Encapsulation: Designing a class so that its attributes are isolated from actions or external code except through the formal interface.
      • The formal interface is the methods.
      • Very rarely, or never, should data be accessible directly
        • This is a discipline
        • The user (programmer) should now know the internal data (abstraction)
        • You should be able to modify the internal rep, and still have program work (reusability)
        • Remember Constructors, Destructors, transformers (setters) , observers (getters)
        • The class should protect its self from incorrect/inappropriate modification.