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:

Style and elegance have a number of benefits:

• A clean design is easier to extend. Adding features to convoluted code requires much more thought and effort to avoid accidentally breaking other parts of the system. A good design will make it easier to quickly deliver changes to clients in the future and will save on future development costs.
• The code will be easier to understand, so new developers and developers working in new areas of the code will not have to spend as much time learning how the system works. This will save in development costs.
• Elegant code is less likely to be buggy, and bugs that do exist are easier to fix. This will improve the acceptance of the software by clients and reduce support costs.
• Developers will have much better morale if they are working with nice code. Good morale leads to better productivity and staff retention.

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:

• Do the simplest thing that could possibly work: To apply the Law of Demeter, wrapper methods often have to be added to classes, which is extra work.
• Don't repeat yourself: If wrapper methods are being used extensively, this could be viewed as repeating yourself since these wrapper methods are all very similar. If multiple classes wrap the same kind of object, some wrapper methods may end up being exactly duplicated.
• Single responsibility principle and One key abstraction: If a class has to wrap its contained objects and provide a public interface to perform functionality on them, it will effectively have multiple responsibilities.

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.