Critique Design Decisions

Exercise critique the design decisions below.

  1. MoocRoster extends JhuRoster (or the other way around)

    Solution

    • The advantage of having one type of roster extend the other one lies in type substitution benefits. For example, if MoocRoster extends JhuRoster, we can have an array of type JhuRoster and store rosters of type MoocRoster in there.

    • The main issue with this design is that there is a minimal incentive for an inheritance; if MoocRoster extends JhuRoster (or the other way around), it must override all of its operations. There goes the incentive on code reuse. Besides, the semantic meaning of inheritance is not firmly met here either. It is not clear that MoocRoster is a JhuRoster (or the other way around).

  2. JhuRoster and MoocRoster are entirely separate data types (or "data structures" if you like).

    Solution

    • The advantage of having two independent types, JhuRoster and MoocRoster, is that we avoid the awkwardness of having one extend the other.

    • The disadvantages, on the other hand, are twofold:

      • It will add complexity (and possibly duplicate code) in clients of these types (i.e. all classes that need to maintain a roster of students).

      • The two types of rosters may evolve independently and diverge from having a unified interface. That means more work for clients of these rosters as they must learn to work with two potentially different interfaces.

  3. There is a Roster class where both MoocRoster and JhuRoster extend it.

    Solution

    The last design, like the first one, benefits from the potentials of type substitution. It further offers a more justified inheritance relationship; indeed JhuRoster is a Roster and MoocRoster is a Roster.

    The problem with this design occurs when implementing the base type Roster. We have two choices:

    • Implement Roster as if it was a JhuRoster or MoocRoster. In this case, one of the JhuRoster or MoocRoster will just be an alias for the Roster class. The criticism applied to the first design will be applicable here.

    • Don't really implement Roster! Instead, put stubs in place of its methods. The issue with this approach is that one can still instantiate the Roster even through the methods in it have no real implementation!

      Student john = new Student("John Doe", "john@email.com");
Roster myRoster = new Roster(30);
myRoster.add(john); // what will happen??!