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?