Now that we have seen some implementation of object oriented programming, it is time to develop our skills at solving problems from an object-oriented approach. To do this well, we need to disregard what we know about functional problem solving and look at problems from a completely different perspective. We need to identify the objects and classes of objects within a problem, and we need to identify the relationships among those objects and classes.
Before Class: Read sections 6.3.1 through 6.3.3 from the text to familiarize yourself with the terms and methods of object oriented design.
Goals: This lab will stress the importance of using relationships among independently operating objects to solve large problems. Upon completion, the student should be able to create and edit a list of classes that pertain to a problem and how to relate those classes to one another using data-flow diagrams. The student should also have a general familiarity with the idea of delegation.
Introduction: Recall the problem posed in the first lab on object-oriented programming. In that lab we created a class of students, each of which had several particular traits contained in his or her state. The bigger problem posed was to create a database of students containing a set of information about each one. In this lab we will work on implementing that database in the form of directories of students and faculty.
A bigger Object-Oriented Problem:
Suppose the college wants to keep a directory of the students and faculty. Each person is associated with a particular major course of study or department, as well as a set of course units. For the student those course units might be those he is currently enrolled in or those he has completed. Further, students are associated with their faculty advisor, and have a set of grades for completed courses. Also, the college needs a way to keep track of available majors and course units.
1. Make a preliminary list of any and all classes that might pertain to this problem.
Some of the classes that you just determined will be indispensible in the solution, some might be useful, others would probably just get in the way. Perhaps the most important issue in object oriented design is deciding which of these potential classes fall into which of those three categories.
2. Create a second version of your list, a streamlined and organized copy of the first, that includes only the classes that you think will be most useful for solving this problem.
Relationships among Objects
The Has-a Relationship
One of the two major types of relationships in object oriented design is
the containment relationship, where it can be said that one object has-a
other object. To avoid a particular sort of confusion, here is an
example: A pregnant woman has a womb, and in that womb there grows a
child. When the baby is born, the mother still has a womb, and now the
mother has a child. The mother has a womb relationship is not the
sort that we consider in object oriented design; the womb is an intrinsic
part of the mother, not an independent object that can operate on its
own without her. The mother has a child relationship is the one we
would consider because the child is its own autonomous object (at least it
will be when it grows up). Thus it can be said that there is a has-a
relationship between mother and child. Keep this distinction in mind as
you consider the relationships between, say, students, grades, and courses.
Cardinality is a description of containment relationships that describes the number of objects of a certain class that some object contains. In a family with one child, the mother has-a child relationship has a cardinality of one to one, in a family with several children, the mother has-a child relationship has a cardinality of one to many.
3. Make a diagram of containment relationships of the objects in the classes you defined in part 2, and label the cardinality of each relationship.
The Is-a Relationship
The other important relationship in object oriented design is the is-a
relationship. The is a relationship is most useful when describing an
object in a specific class as one in a more general class. For example, a
woman is a person; a man and a child are too. Humanities is a division in
the college; so are science and social studies. Notice that these are
real-life examples of is-a relationships. The relationships we use in
object oriented design should model real life as closely as possible.
These sorts of generalized classes are important to the implementation of
object-oriented problems, they allow us to use delegation, which can be a
powerful tool in large problems.
4. For practice, complete the following relationships that are found in
our original problem:
Advisor is a ________
Advisee is a ________
5. Simplify your diagram from part 3 by using is-a relationships and generalized classes wherever possible.
Methodology: One of the primary goals of object oriented programming is to solve a problem in a fashion that imitates real life. Thus it becomes important, when thinking about interactions between objects, to create a logical set of methods for each class to build a reasonable model of real life.
However, it is also important to make data storage feasible. The easiest way to avoid problems with variables and groups of data is to define them locally and only store them once. Recall the first lab on object oriented programming, where we used a Faculty directory to attain information about professors at the college. That directory contained names of professors coupled with the department in which they teach.
6. If our new design for solving the problem includes objects for professors as well as a directory of them, where is the best place to store information about the faculty members? Are there any reasons to store that information in more than one place, and if so what are those reasons?
Objects: The Students:
We can model real life by assuming that students can be responsible for
keeping up-to-date records of their personal information with regard to
school. They should know what their major is, who their advisor is, what
courses they are taking, etc. Furthermore, if someone asks them for
information about themselves, they ought to be able to provide it. But
they need not do more than know the information and recite it piece by
piece. If we want a description of a student, we will let the directory
print it for us. With this in mind we define the following class of
students:
(define-class student
(constructor-arguments name major advisor credits)
(class-methods (message . arg-pair)
((get-argument)
(let ((args (car arg-pair))
(n (cadr arg-pair)))
(if (< (length args) n)
(error 'get-argument "Invalid number of arguments")
(list-ref args n)))))
(methods (message . args)
;;;; This method adds the student to the student directory.
((enroll)
(let ((ident (student 'get-argument args 0)))
(Students 'add-object ident)))
;;;; This method lets the student declare a major with an advisor.
((declare)
(let ((prof (student 'get-argument args 0))
(desired-major (student 'get-argument args 1)))
;;; Add code here to ok changes with professor in step #12.
(set! advisor prof)
(set! major desired-major))
; (format "Student ~a: sorry, ~b is not listed as a professor for your major." name prof)))
;;;; This method lets you add to the students number of completed credits.
((completed)
(let ((new_credits (student 'get-argument args 0)))
(set! credits (+ credits new_credits))))
;;;; These are self explanatory, and useful to the directory.
((show_credits)
credits)
((show_advisor)
advisor)
((show_department)
major)
((show_name)
name)
))
7. Copy this declaration into XEmacs, and open a Scheme interaction window. Load the OOP package with the command:
(load "/home/walker/153/book-code/vslib/class.scm")
Create some student objects and vary their state using the following
commands, which should be familiar from the other OOP lab:
>(define dick (student 'make "Dick" "undeclared" "staff" 0)) >(define jane (student 'make "Jane" "undeclared" "staff" 0)) >(define mary (student 'make "Mary" "undeclared" "staff" 0)) >(define paul (student 'make "Paul" "undeclared" "staff" 0)) >(dick 'declare "Jepsen" "Math") >(jane 'declare "Walker" "CS") >(mary 'declare "Gardner" "English") >(paul 'declare "Dobbs" "English") >(paul 'completed 4) >(jane 'completed 4) >(mary 'completed 4)
We could check the states of the objects to see that the appropriate changes have been made, but instead we will implement a directory of students. This student directory will act as an intermediary between students and people (or other objects) inquiring about them.
Objects: The Directories:
Our new directory is actually a set of directories, one for faculty and
one for students. We could also define one for courses, like a course
catalog. This should remind you of the phone directories and course
catalog on your shelf in your dorm room. Since a college is a dynamic place with people coming and going
fairly frequently, we should be able to add objects to and delete them from
the appropriate directories. Of course, we would still like our directory
to tell us information about an object. Our directory contains
a list of objects, contained in a slot so that scheme can distinguish one
object from the next.
OOP seeks to imitate real life, but real life is the reason our new directory is deficient in some aspects. In real life OOP in Scheme is difficult, and time is running out to get this lab finished. So some features of the old directory are missing. Notably, it can only handle one piece of "department" state for each object. Thus, we have no double majors and Mr. Walker may only teach in Math or Computer Science, but not both. Also, the directory does not support lists of courses, nor can it remove objects from its listing.
8. Load the directory class definition into Chez Scheme with the command:
> (load "/home/barkley/scheme/lab33-directory.ss")Initialize an empty Student directory:
> (define Students (dir 'make))
9. To be available in the directory, your student objects need to enroll. Do that for each of them with commands of the form:
> (dick 'enroll dick)
10. Try out the following messages. Make sure you understand what they do. You should use messages like these in the steps that follow.
> (Students 'listing) > (Students 'department "Jane") > (Students 'listing "credits") > (Students 'listing "department" "CS") > (Students 'listing "department" "English")
Objects: The Faculty:
11. Our directories get information about the people the have listings
for. We have a student directory, and can easily define a faculty
directory. But to use a faculty directory, we need a class of professors.
Define that class, including important elements of
state and important methods, as per your design from earlier in the lab.
Remember that a professor needs to accept a postition at the college to be
listed in the faculty directory, just as a student must enroll.
Keep in mind the interactions a professor will have with students. If a
students declares a major with a certain professor, that professor needs to
teach in the department of the desired major, and if so needs to add the student to his list of advisees.
If you want you may limit the faculty class to the state and methods
mentioned explicitly in this paragraph, but extra
effort might yield extra credit. Whenever possible, use the directory as
an intermediary when one object wants information about another, and make
sure to give professors the same simple methods students have so that the
directory can give listings of groups of them .
12. Add code to existing methods in the student class such that the interactions described above take place. For example, when a student declares her major, have her tell her new advisor to add her as an advisee, and only let her declare if her desired advisor teaches in her desired department.
This document is available on the World Wide Web as
http://www.math.grin.edu/~walker/courses/153/lab-oop-design.html http://www.math.grin.edu/~barkley/lab-oodesign.html
created April 17, 1998 by Scott G. Barkley