Question

intro code:

public interface Course {

    /**
     * returns the number of units (hours) a specific course is
     */
    public int units();

    /**
     * returns the number of students signed up for the course
     */
    public int numOfStudents();

    /**
     * returns the maximum number of students the course can have signed up to it
     */
    public int maxNumStudents();

    /**
     * returns whether or not the student is enrolled in the course
     */
    public boolean registered(Student s);

    /**
     * enrolls s in the course
     * 
     * @pre     this.registered(s) == false
     * @pre     this.numOfStudents() < this.maxNumStudents()
     * 
     * @post    this.registered(s) == true
     * @post    this.numOfStudents() == $prev(this.numOfStudents()) + 1
     */
    public void register(Student s);

}


public interface Student {

    /**
     * enrolls the student in course c
     * 
     * @pre     c.registered(this) == false
     * @pre     c.numOfStudents() < c.maxNumStudents()
     * @pre     this.totalUnits() + c.units() <= 10
     * 
     * @post    c.registered(s) == true
     * @post    this.totalUnits() == $prev(this.totalUnits()) + c.units()
     */
    public void register(Course c);

    /**
     * return the total number of units this student currently is enrolled in
     * 
     * @pre     true
     * @post    0 <= $ret <= 10
     */
    public int totalUnits();

}

in the example code im trying to describe two separate entities (interfaces/classes/whatever) which on the one hand should be (i would like, at least) loosely coupled but on the other hand do depend on each other and require a certain knowledge of each other.

in the above scenario i would need a third class that actually unites them into a working system. its ugly because as of now, the above definition is as loosely coupled as can be – student.register(c) only changes the student object, and course.register(s) only changes the course object. so a unifying class would have to run both s.register(c) and c.register(s).

although if i relogate all the register() logic to one class then i tightly couple them.

is there a cleaner way of designing this?

Answer 1

By using interfaces you are already reducing the level of dependency between concrete objects and that is a good thing. Some dependency is necessary for your system to work so you have to decide how much you want to tolerate.

Consider that a Student in your system can register for a course. Since Course is an interface it may be possible to implement a number of different types of Courses and the student will then be able to register for any of them. As long as the student only knows the Course interface that should be fine. And the same thing for the Course, it only knows the Student interface not the concrete Students.

Just one thing. In a situation where you have a bi-directional association as you describe I like to make one side the owner of the relationship. That is, I can decide that Student owns the relationship and as such, a Student may register for the Course but the Course does not Register the Student.

Then all client code will make a single call s.register(c). The register in Student will then take care of the inverse side of the relationship. This reduces the need of client code to know both sides of the relationship.