2007 Exam answers
m |
m (Reverted edits by Ebybymic (Talk); changed back to last version by Nelson Shaw) |
||
(19 intermediate revisions by 8 users not shown) | |||
Line 1: | Line 1: | ||
== Question 1 == | == Question 1 == | ||
+ | |||
[26 marks for whole question] For each part (a)-(m), name the idea (or ideas) that best match the description and briefly explain your answer. If possible, include WikiNames. | [26 marks for whole question] For each part (a)-(m), name the idea (or ideas) that best match the description and briefly explain your answer. If possible, include WikiNames. | ||
# (a) [2 marks] Keep the number of fields in a class small. | # (a) [2 marks] Keep the number of fields in a class small. | ||
− | #: ''Answer:'' [[One key abstraction]], [[Large class smell]] | + | #: ''Answer:'' [[One key abstraction]], [[Large class smell]], [[Single responsibility principle]], [[Keep it simple]], [[limit compositions in a class]], [[Minimize number of methods]] |
# (b) [2 marks] Methods should use most of the fields of the method’s object. | # (b) [2 marks] Methods should use most of the fields of the method’s object. | ||
− | #: ''Answer:'' [[Single responsibility principle]], [[One key abstraction]] | + | #: ''Answer:'' [[Single responsibility principle]], [[One key abstraction]], [[Keep related data and behavior in one place]], [[Methods should use most fields of a class]] |
# (c) [2 marks] When several methods cooperate to do a job, give them the same name. | # (c) [2 marks] When several methods cooperate to do a job, give them the same name. | ||
#: ''Answer:'' [[Recursion introduction]] | #: ''Answer:'' [[Recursion introduction]] | ||
# (d) [2 marks] Objects should invoke methods of contained objects. | # (d) [2 marks] Objects should invoke methods of contained objects. | ||
− | #: ''Answer:'' [[Tell, don't ask]], [[Beware accessors]], [[Favor composition over inheritance]] | + | #: ''Answer:'' [[Tell, don't ask]], [[Beware accessors]], [[Favor composition over inheritance]], [[Law of Demeter]] |
# (e) [2 marks] A CodeSmell that supports one of RielsHeuristics. | # (e) [2 marks] A CodeSmell that supports one of RielsHeuristics. | ||
− | #: ''Answer:'' [[Switch statement smell]] [[Beware type switches]] [[Large class smell]] | + | #: ''Answer:'' [[Switch statement smell]] supports [[Beware type switches]], [[Large class smell]] supports [[Avoid interface pollution]] and [[Minimize number of methods]]. |
# (f) [2 marks] A pattern that conflicts with TellDontAsk. | # (f) [2 marks] A pattern that conflicts with TellDontAsk. | ||
− | #: ''Answer:'' [[Observer]] | + | #: ''Answer:'' [[Observer]], [[Visitor]]. |
# (g) [2 marks] A pattern that supports TellDontAsk. | # (g) [2 marks] A pattern that supports TellDontAsk. | ||
− | #: ''Answer:'' [[Factory Method]] | + | #: ''Answer:'' [[Factory Method]], [[Command]], [[Interpreter]]. |
# (h) [2 marks] A pattern that employs DoubleDispatch. | # (h) [2 marks] A pattern that employs DoubleDispatch. | ||
#: ''Answer:'' [[Visitor]] | #: ''Answer:'' [[Visitor]] | ||
# (i) [2 marks] A pattern based on ModelTheRealWorld. | # (i) [2 marks] A pattern based on ModelTheRealWorld. | ||
− | #: ''Answer:'' [[Composite]], [[Model | + | #: ''Answer:'' [[Singleton]], [[Composite]], [[Model View Controller]]? [[Strategy]]/[[State]]? |
# (j) [2 marks] A pattern that conflicts with one of RielsHeuristics. | # (j) [2 marks] A pattern that conflicts with one of RielsHeuristics. | ||
− | #: ''Answer:'' [[Avoid no-op overrides]] | + | #: ''Answer:'' [[Avoid no-op overrides]] - [[Composite]], [[Hide data within its class]] - [[Visitor]]. |
# (k) [2 marks] A pattern that exhibits a CodeSmell. | # (k) [2 marks] A pattern that exhibits a CodeSmell. | ||
− | #: ''Answer:'' [[Iterator]] | + | #: ''Answer:'' [[Iterator]] - [[Parallel inheritance hierarchies smell]], [[Visitor]] - [[Feature envy smell]] |
# (l) [2 marks] An architectural pattern that contains a design pattern. | # (l) [2 marks] An architectural pattern that contains a design pattern. | ||
− | #: ''Answer:'' [[Observer]] + [[Strategy]] = [[Model | + | #: ''Answer:'' [[Observer]] + [[Strategy]] = [[Model View Controller]] |
# (m) [2 marks] A design problem that the Waterfall Process was intended to fix. | # (m) [2 marks] A design problem that the Waterfall Process was intended to fix. | ||
#: ''Answer:'' [[Big ball of mud]] | #: ''Answer:'' [[Big ball of mud]] | ||
Line 33: | Line 34: | ||
[10 marks] Which of RielsHeuristics can be traced back to ideas described in JohnsonAndFoote1988? For each heuristic you identify, explain how it is based on the earlier idea. | [10 marks] Which of RielsHeuristics can be traced back to ideas described in JohnsonAndFoote1988? For each heuristic you identify, explain how it is based on the earlier idea. | ||
− | :''Answer:'' | + | :''Answer:'' |
+ | * [[Avoid concrete base classes]] - [[The top of the class hierarchy should be abstract]]. | ||
+ | * [[Inheritance for specialization]] - [[Subclasses should be specializations]]. | ||
+ | * [[Favour deep hierarchies]] - [[Class hierarchies should be deep and narrow]]. | ||
+ | * [[Beware type switches]] and [[Beware value switches]] - [[Eliminate case analysis]]. | ||
+ | * [[Beware of non-communicating methods]] - [[Separate methods that do not communicate]]. | ||
+ | * [[Favor composition over inheritance]] - [[Beware inheritance over composition]] | ||
== Question 3 == | == Question 3 == | ||
Line 39: | Line 46: | ||
[16 marks for whole question] For each of the following maxims (a)-(d) name other maxims (as many as you can) that support it. Briefly explain each answer. | [16 marks for whole question] For each of the following maxims (a)-(d) name other maxims (as many as you can) that support it. Briefly explain each answer. | ||
− | # [4 marks] | + | # [4 marks] [[Program to the interface not the implementation]] |
− | #: ''Answer:'' | + | #: ''Answer:'' [[Dependency inversion principle]], [[Information hiding]] |
− | # [4 marks] | + | # [4 marks] [[Separation of concerns]] |
− | #: ''Answer:'' | + | #: ''Answer:'' [[Single responsibility principle]], [[One key abstraction]] |
− | # [4 marks] | + | # [4 marks] [[Software reuse]] |
− | #: ''Answer:'' | + | #: ''Answer:'' [[Favor composition over inheritance]], [[Reusable frameworks over reusable components]], [[Open closed principle]] |
− | # [4 marks] | + | # [4 marks] [[Open closed principle]] |
− | #: ''Answer:'' | + | #: ''Answer:'' [[Abstraction]], [[Make all Member Variables Private]], [[No Global Variables]], [[Software reuse]] |
== Question 4 == | == Question 4 == | ||
Line 58: | Line 65: | ||
[5 marks] Imagine it was your job to interview an applicant for an OO design job. If you were allowed to ask only one question, and from the answer you had to judge whether the person was a skilled OO designer, what would you ask? Explain your reasoning. | [5 marks] Imagine it was your job to interview an applicant for an OO design job. If you were allowed to ask only one question, and from the answer you had to judge whether the person was a skilled OO designer, what would you ask? Explain your reasoning. | ||
− | :'' | + | :''Possible Answers:'' |
+ | * Explain in what ways you can make an OO system more maintainable and reusable. --[[User:Elliot Fisher|Elliot Fisher]] 08:39, 6 October 2008 (UTC) | ||
+ | * Explain what you think is the most fundamental idea in OO design. --[[User:Aidan Bebbington|Aidan]] 03:19, 4 October 2009 (UTC) | ||
+ | * If you were to create an OO model of the room we are in, what classes would you create? --[[User:Aidan Bebbington|Aidan]] 03:19, 4 October 2009 (UTC) | ||
== Question 6 == | == Question 6 == | ||
[35 marks for whole question] See [[Trains design]]. | [35 marks for whole question] See [[Trains design]]. |
Latest revision as of 03:08, 25 November 2010
Contents |
Question 1
[26 marks for whole question] For each part (a)-(m), name the idea (or ideas) that best match the description and briefly explain your answer. If possible, include WikiNames.
- (a) [2 marks] Keep the number of fields in a class small.
- (b) [2 marks] Methods should use most of the fields of the method’s object.
- (c) [2 marks] When several methods cooperate to do a job, give them the same name.
- Answer: Recursion introduction
- (d) [2 marks] Objects should invoke methods of contained objects.
- (e) [2 marks] A CodeSmell that supports one of RielsHeuristics.
- Answer: Switch statement smell supports Beware type switches, Large class smell supports Avoid interface pollution and Minimize number of methods.
- (f) [2 marks] A pattern that conflicts with TellDontAsk.
- (g) [2 marks] A pattern that supports TellDontAsk.
- Answer: Factory Method, Command, Interpreter.
- (h) [2 marks] A pattern that employs DoubleDispatch.
- Answer: Visitor
- (i) [2 marks] A pattern based on ModelTheRealWorld.
- Answer: Singleton, Composite, Model View Controller? Strategy/State?
- (j) [2 marks] A pattern that conflicts with one of RielsHeuristics.
- Answer: Avoid no-op overrides - Composite, Hide data within its class - Visitor.
- (k) [2 marks] A pattern that exhibits a CodeSmell.
- (l) [2 marks] An architectural pattern that contains a design pattern.
- Answer: Observer + Strategy = Model View Controller
- (m) [2 marks] A design problem that the Waterfall Process was intended to fix.
- Answer: Big ball of mud
Question 2
[10 marks] Which of RielsHeuristics can be traced back to ideas described in JohnsonAndFoote1988? For each heuristic you identify, explain how it is based on the earlier idea.
- Answer:
- Avoid concrete base classes - The top of the class hierarchy should be abstract.
- Inheritance for specialization - Subclasses should be specializations.
- Favour deep hierarchies - Class hierarchies should be deep and narrow.
- Beware type switches and Beware value switches - Eliminate case analysis.
- Beware of non-communicating methods - Separate methods that do not communicate.
- Favor composition over inheritance - Beware inheritance over composition
Question 3
[16 marks for whole question] For each of the following maxims (a)-(d) name other maxims (as many as you can) that support it. Briefly explain each answer.
- [4 marks] Program to the interface not the implementation
- [4 marks] Separation of concerns
- [4 marks] Software reuse
- [4 marks] Open closed principle
Question 4
[8 marks for whole question] Describe a design flaw in a 427 project produced by one of your classmates. Choose the most serious flaw you can find, clearly describe where it occurs (including where it can be found in the wiki) and support your argument, where possible, with maxims etc.
- Answer:
Question 5
[5 marks] Imagine it was your job to interview an applicant for an OO design job. If you were allowed to ask only one question, and from the answer you had to judge whether the person was a skilled OO designer, what would you ask? Explain your reasoning.
- Possible Answers:
- Explain in what ways you can make an OO system more maintainable and reusable. --Elliot Fisher 08:39, 6 October 2008 (UTC)
- Explain what you think is the most fundamental idea in OO design. --Aidan 03:19, 4 October 2009 (UTC)
- If you were to create an OO model of the room we are in, what classes would you create? --Aidan 03:19, 4 October 2009 (UTC)
Question 6
[35 marks for whole question] See Trains design.