2008 Exam answers
From CSSEMediaWiki
(Difference between revisions)
JaninaVoigt (Talk | contribs) |
JaninaVoigt (Talk | contribs) |
||
| Line 3: | Line 3: | ||
* Replace the Pair class with a Transaction class and two subclasses CreditTransaction and DebitTransaction. These classes will contain the information that was contained in Pair, and any other behavior related to transactions which is likely to have leaked out into the rest of the system. | * Replace the Pair class with a Transaction class and two subclasses CreditTransaction and DebitTransaction. These classes will contain the information that was contained in Pair, and any other behavior related to transactions which is likely to have leaked out into the rest of the system. | ||
*Currently, the Pair class is used to keep track of the Stock a Stockholder owns (price and date of purchase or sale) and to record transactions (the stock that was traded and the date of the trade). | *Currently, the Pair class is used to keep track of the Stock a Stockholder owns (price and date of purchase or sale) and to record transactions (the stock that was traded and the date of the trade). | ||
| − | + | *'''Violations:''' | |
| − | + | **[[Behavioral completeness]] - The Pair class currently only acts as a data container but does not contain the behaviour related to that data. | |
| − | + | **[[One key abstraction]] - Pair currently does not capture one particular domain concept but tries to do several things at once. This is also related to [[Single responsibility principle]]. | |
| − | + | **[[Separation of concerns]] - Pair should only have one particular responsibility but at the moment fulfills several. These should be separated. | |
* Replace Stock class with CompanyStock and OwnedStock. These classes will not share a common super class as they differ greatly in what they represent. | * Replace Stock class with CompanyStock and OwnedStock. These classes will not share a common super class as they differ greatly in what they represent. | ||
| − | **'''Violations:''' | + | * The Stock class currently tries to represent both a single share (OwnedStock) and the master share with information about the stock for a particular company (CompanyStock). |
| + | *'''Violations:''' | ||
| + | **[[Single responsibility principle]] - The Stock class tries to represent two very different concepts at the same time. | ||
| + | **[[One key abstraction]] | ||
* Broker and StockHolder should both hold a reference to an Account object. This would replace the brokersAccount property of Broker. The Account class would manage Transactions and include a reference to the account holder (Broker or StockHolder). | * Broker and StockHolder should both hold a reference to an Account object. This would replace the brokersAccount property of Broker. The Account class would manage Transactions and include a reference to the account holder (Broker or StockHolder). | ||
**'''Violations:''' [[Single responsibility principle]] | **'''Violations:''' [[Single responsibility principle]] | ||
* Broker and StockHolder should both hold a reference to ContactDetails object. Alternatively they could both inherit from a Person class, but if we favor composition over inheritance this would seem the less preferred solution. This also wouldn't be a good solution if a Broker can be a company as well as a person. This would allow personal details of Brokers and StockHolders to be stored. In the current design the notion of a Person is mixed with that of an Account. The improved design separates these two and would allow someone to have multiple accounts. | * Broker and StockHolder should both hold a reference to ContactDetails object. Alternatively they could both inherit from a Person class, but if we favor composition over inheritance this would seem the less preferred solution. This also wouldn't be a good solution if a Broker can be a company as well as a person. This would allow personal details of Brokers and StockHolders to be stored. In the current design the notion of a Person is mixed with that of an Account. The improved design separates these two and would allow someone to have multiple accounts. | ||
**'''Violations:''' [[Single responsibility principle]] | **'''Violations:''' [[Single responsibility principle]] | ||
Revision as of 04:22, 17 July 2009
Question 1
Possible improvements to the design:
- Replace the Pair class with a Transaction class and two subclasses CreditTransaction and DebitTransaction. These classes will contain the information that was contained in Pair, and any other behavior related to transactions which is likely to have leaked out into the rest of the system.
- Currently, the Pair class is used to keep track of the Stock a Stockholder owns (price and date of purchase or sale) and to record transactions (the stock that was traded and the date of the trade).
- Violations:
- Behavioral completeness - The Pair class currently only acts as a data container but does not contain the behaviour related to that data.
- One key abstraction - Pair currently does not capture one particular domain concept but tries to do several things at once. This is also related to Single responsibility principle.
- Separation of concerns - Pair should only have one particular responsibility but at the moment fulfills several. These should be separated.
- Replace Stock class with CompanyStock and OwnedStock. These classes will not share a common super class as they differ greatly in what they represent.
- The Stock class currently tries to represent both a single share (OwnedStock) and the master share with information about the stock for a particular company (CompanyStock).
- Violations:
- Single responsibility principle - The Stock class tries to represent two very different concepts at the same time.
- One key abstraction
- Broker and StockHolder should both hold a reference to an Account object. This would replace the brokersAccount property of Broker. The Account class would manage Transactions and include a reference to the account holder (Broker or StockHolder).
- Violations: Single responsibility principle
- Broker and StockHolder should both hold a reference to ContactDetails object. Alternatively they could both inherit from a Person class, but if we favor composition over inheritance this would seem the less preferred solution. This also wouldn't be a good solution if a Broker can be a company as well as a person. This would allow personal details of Brokers and StockHolders to be stored. In the current design the notion of a Person is mixed with that of an Account. The improved design separates these two and would allow someone to have multiple accounts.
- Violations: Single responsibility principle
