Saint Louis University |
Computer Science 150
|
Dept. of Math & Computer Science |
Preface: These notes are not meant to be a complete presentation of the material. Instead, they are designed as a very brief outline of topics/terminology to be discussed in class. For more complete coverage, please carefully read the appropriate sections of Chapter 1 of the text.
built-in vs. user-defined data types
built-in vs. user-defined operations/functions;
flow of control;
higher-level algorithms
Thoughtful pairing of data/operations.
class: (e.g., Canvas, Rectangle, Color)
object/instance: a member of a class. Created through the process of instantiation, by calling the class constructor
trunk = Rectangle(30, 70)
There can be many instances of a class. Each instance has its own state information (via "data members")
What the class does is defines the internal representation for storing the state information, and the algorithms used to implement the external behaviors of its instances.
In object-oriented terminology, we tend to use the following as
synonyms:
operation, action, behavior,
member function, method.
(Our prefered terminology is method.)
paper.setTitle('My Zoo')
body.move(200, 100)
paper.add(body)
Terminology: calling/invoking the method, the caller and callee, the method name, parameters.
Note: the calling syntax for a method is different from the original
construction, such as
Note: object-oriented syntax is different from traditional function calling, such as sleep(0.5). Note that there is no callee (and no state information) when using traditional functions.
Note: parentheses are required, even when zero parameters are sent, as in, paper.close(). Omitting those parenthesis is a common "gotcha"
The syntax of a method is the formal language used for
calling the method (e.g.,
The semantics of a method are the effect of such a call. Typical considerations:
Methods that may change the state of the callee are known as mutators. Methods that cannot change the state are known as accessors (those are typically used to return information to the caller).
We noted that each instance of a class has its own state information. That must be stored in memory in some way. This is typically done by managing one or more attributes (aka data members) for each object.
A key principle of object-oriented program is known as encapsulation. All interactions with objects should be through calling methods, and outside users should never need to directly access the internal attributes. The responsibility for maintaining attributes is left to the designer of the class. This creates a distinction between the public interface and private implementation.
For example, although our cs1graphics.Rectangle class supports behaviors getWidth, setWidth, getHeight, and setHeight. However, internally we do not explicitly store a "width" or "height" attribute for a rectangle! Those are actually based on computing measures of a transformation matrix. But you don't need to know this to be a user of the graphics package and the Rectangle class.
In large object-oriented systems, there will be many instances of many different classes, all interacting through a sequence of method calls.
Can portray such interactions with sequence diagrams (see Ch. 1).
Beauty of OOP and encapsulation is that it makes it much easier to develop, maintain, adapt, and reuse software. Each class has its well-defined responsibilities. Higher-level functionality is based on interactions.
Development: as long as there is agreement on the public interface for a class, one programmer can start writing code that uses the class, even while another program is implementing the class
Debugging: can often test individual classes and locate problems before intergrating the whole system. Even if a bug appears in the full system, it should be easier to track down which class contains the error.
Maintenance: Developers can reimplement the internals of a class (either to fix bugs, or to improve performance), and so long as they do not change the public interface, client code need not be changed.
Reusability: Classes with general responsibilities can often be reused across many different projects.
This is an advanced OOP technique that allows one or more subclasses to be developed as extensions of an existing base class. By taking advantage of commonality among groups of classes, inheritance promotes greater code reuse. Alternate terminology: subclass aka child class; base class aka parent class
We will revisit this technique around mid-semester, but you have already seen the use of inheritance in our cs1graphics package (e.g., Drawable, Shape, FillableShape, Circle, Rectangle, Text). The use of inheritance greatly helped us in implementing the graphics pacakge. It also makes it a bit easier for users of the library because there is a lot of common syntax shared by different classes (e.g., setFillColor)