2005 Exam answers

Question 1

[20 marks for whole question] For each of the following descriptions (a) – (e):

• [1 mark each] Name a maxim (or pattern, code smell, etc) that captures the idea.
• [1 mark each] Explain the rationale for this maxim (i.e. why the maxim exists).
• [2 marks each] Comment on the validity and value of this maxim.

1. [4 marks] Methods that change attribute values should be distinct from methods that merely return values.

   Answer: Command query separation

2. [4 marks] Methods should not directly access attributes defined by a superclass.

   Answer: Avoid protected data

3. [4 marks] Classes should be designed around their behaviour, rather than their data.

   Answer: Define classes by behavior, not state pattern

4. [4 marks] Classes that have subclasses should not be directly instantiated.

   Answer: Avoid concrete base classes

5. [4 marks] Very badly designed software should be completely rewritten rather than progressively edited.

   Answer: The Reconstruction pattern from the Big ball of mud paper by Foote and Yoder

Question 2

[6 marks] Some employers believe that aesthetic issues such as style and elegance have no place in OO software design: all that matters is functionality. Is this true? Write an argument to convince a sceptical employer of your view.

Answer:

Question 3

[6 marks] Identify maxims that either conflict with or support the Law of Demeter. For each one, explain how it conflicts with / supports the Law of Demeter. Using these ideas as justification, make a recommendation for how (or whether) experienced software engineers should apply the Law of Demeter.

Answer:

Conflicts:

• Implement behavior with abstract state pattern (Really? See discussion)

Support:

• Keep related data and behavior in one place
• Tell, don't ask
• Message chain smell
• Beware of many accessors
• Don't expose mutable attributes

Question 4

[10 marks] If the Gang of Four decided to produce a new edition of their design patterns book, (updated with UML diagrams and examples in current OO languages), and they asked for your advice on specific ways to improve the book and its patterns, what would you tell them?

Answer:

• I would advise the GoF to leave out the Interpreter pattern because I think it is an analysis pattern rather than a general design pattern. All other design patterns are applicable to a wide range of domains while the interpreter pattern is a specific version of the Composite pattern applied to the domain of languages. I therefore feel that it does not fit in with the other patterns in the book.

• I would also advise the GoF to leave out the Singleton pattern. I think this pattern is a classic example of a pattern that is easily overused by developers despite the fact that it can have some unwanted consequences. Therefore, I feel that the singleton pattern should be excluded from the book to not further encourage its use.

• I would suggest a modification to the Composite pattern. In particular, I would suggest moving the addChild, removeChild and getChild methods from the Component to the Composite. The reason for this is that in the current design these methods are overridden in the Leaf class to do nothing. This results in the contract for these methods being quite vague and complex. In fact, clients can't really be sure if a child was added or removed when calling this method because they might not know if they are dealing with a Leaf or Composite. See Composite for a more detailed explanations of the options for this pattern and their consequences.

Question 5

5. [4 marks] The wiki pages ConflictingIdeas and DesignPatternsBreakRules describe opposing OO design concepts. Identify and describe a conflict that has not already been documented on these pages.

Answer:

Question 6

6. [18 marks] Suggest a series of refactorings (from MartinFowler1999) that you would apply to the Java code of Figure 1. (Don’t just name them – explain how the code would change.)

public class Snorkulator {
  ...
}

Answer:

Question 7

[36 marks] See Sorcerers design.