Review of 115 material

• Classes & Objects
• The hierarchy of Objects is first the ADT, or the abstract concept, which is formalized by a Class, which is instantiated by an object
• The basic building blocks of object-oriented (OO) programs are objects.
• Objects have properties and behaviors. Properties are analagous to class variables, and behaviors are analagous to class methods.
• Objects are instances of classes.
• At runtime an OO program consists of a system of objects which communicate with one another by sending messages to each other.
• Java concepts
• Access to methods and variables can be declared public, private, or protected
• Class variables should be declared private, and given accessor and mutator methods, to protect data integrety and hide implementation details
• Methods and variables can be declared static. You declare a variable as static to ensure only one copy is available to all instances of a class. You declare a method static if there is no logical class to attach it to (library method).
• UML class diagrams
• UML class diagrams are used to show selected aspects of the design of a program.
• UML class diagrams consist of boxes (representing classes and interfaces) and lines between boxes (representing relationships between classes).
• Relationships
• has-a/composition

This is typically a relationship between two classes. As we have gotten to know this relationship, if A has-a B then A declares an instance variable of type B, creates an instance of B in its constructor, and assigns that new instance to the instance variable. This relationship is appropriate to model situations where one object models an integral part of another object (such that the lifetime of the part is determined by the lifetime of the whole). This can be a relationship between a class C and an interface I if C declares an instance variable of type I but creates an instance of a class which implements I in the constructor, and assigns that new instance to the instance variable. In our example, a computer has-a graphics card.

• knows-a/association

This is typically a relationship between two classes. As we have gotten to know this relationship, if A knows-a B then A declares an instance variable of type B, and provides some mechanism by which that instance variable can be assigned an instance of type B (either via a parameter in the constructor or by providing a mutator). In particular A has no responsibility to create an instance of B. The lifetimes of A and B can be entirely independent of each other. As with the has-a relationship this can be a relationship between a class C and an interface I. If so, C declares an instance variable of type I but assigns to the instance variable an instance of a class which implements I. In our example, a computer knows-a network

• uses-a/dependency

We have used this relationship as a bit of a catch-all relationship - any relationship between classes which isn't a has-a, knows-a, is-a or implements relationship. Typically we will use this if there is some mention of a class/interface in a class, but no instance variable is involved. In effect this means that either no variable is involved (an instance of a class is simply created) or a local variable (possibly a parameter) is used to store a reference to an object. In our example, a computer uses-a login

• is-a/inheritance/generalization

This relationship is expressed in Java using the "extends" keyword in the class header. It is a relationship either between two classes or between two interfaces. In our example, a laptop is-a computer

• implements/realization

This relationship is expressed in Java using the "implements" keyword in the class header. It is a relationship between a class and an interface.

• Design patterns
• One way to think of design patterns is as "best practices" solutions to commonly occuring problems.
• Design patterns we saw last semester:
• Command - Encapsulate method behavior in a class.
• Factory method - produces classes at runtime. Useful for adding descriptive names to constructors, or for determining at runtime which subclass or implmentor will be returned from a request for the factory. Example was database connections to different types of databases.
• Null object - A placeholder pattern to avoid null pointer and base/last case exceptions.
• Singleton - Only create one (or a distinct number) of instances of a class. Allows control of expensive or restricted resources.
• State - Pass state in to object, with interface that allows object to return state dependent results without being aware of the state. Sky cloudy/clear example.
• Strategy - Avoid coding multiple algorightms for a particular task by encapsulating the algorithm in a class and passing it in to the object which needs the algo. Sorting a list example.
• Decorator - Adds functionality to a component without affecting the component that it is decorating (picture frame analogy)
• Polymorphism
• Different objects of same (super)type respond to same message in different ways (appropriate to their actual type)
• For example, if you pull the tail of a dog and a cat they will respond differently (dog will growl and bark, the cat will hiss and scratch). Same message, different response. Polymorphism.
• Recall lab 5 from last semester. The different types of heads had different behavior. The spinning head did something different from the bobble head. Same message, different response. Polymorphism.