Video rental system
m (Reverted edits by Ebybymic (Talk); changed back to last version by Lukas Korsika) |
|||
| (9 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| − | '''Design a system that allows DVDs to be rented to customers.''' | + | == '''Design a system that allows DVDs to be rented to customers.''' == |
| − | + | ||
| Line 7: | Line 6: | ||
It would seem that a consensus between designers would indicate a good design (or at least an informed agreement to disagree). | It would seem that a consensus between designers would indicate a good design (or at least an informed agreement to disagree). | ||
| + | |||
| + | ''The idea that independent designers arriving at the same design provides evidence of goodness is echoed in the [[Rule of three]] from the [[Design patterns]] community. --[[User:Warwick Irwin|Wal]] 00:14, 18 July 2008 (UTC)'' | ||
| + | |||
Here is the Video Rental System design we came up with after a short period of group discussion. | Here is the Video Rental System design we came up with after a short period of group discussion. | ||
| − | [[image:VideoRental1.jpg]] | + | |
| + | [[image:VideoRental1.jpg|650px|]] | ||
I short order this class diagram was pulled apart for numerous reasons as will be discussed below. | I short order this class diagram was pulled apart for numerous reasons as will be discussed below. | ||
Feel free to find better ways of doing this and contribute to the discussion. | Feel free to find better ways of doing this and contribute to the discussion. | ||
| − | There are some things we did get right. Using the [[Many to many association idiom]] to create a relationship between Customer and Title | + | '''There are some things we did get right.''' |
| + | |||
| + | Using the [[Many to many association idiom]] to create a relationship between Customer and Title using the rental and transaction class is good. | ||
| + | |||
| + | '''There are many things that could be done better''' | ||
| + | |||
| + | The Title class suffers from some multiple personality problems. It is being used to represent the instance of a movie title while also it is being used to represent every physical instance of the movie in the store. By splitting the Title class on to two classes we take care of [[Separation of concerns]] and we [[Avoid redundant data]]. This has the benefit of only having to create one instance of each title that is in the store irrespective of the number of physical holdings. | ||
| + | |||
| + | |||
| + | And it looks like this | ||
| + | |||
| + | [[image:VideoRental2.jpg|550px|]] | ||
| + | |||
| + | ---- | ||
| + | |||
| + | Actually I would argue that a Rental should link to a PhysicalHolding instead of a Title. If you wanted to incorporate, for instance, condition or some other difference between PhysicalHoldings it is useful to know which holding a Rental refers to. --[[User:Lukas Korsika|Lukas Korsika]] 01:08, 21 October 2010 (UTC) | ||
Latest revision as of 03:22, 25 November 2010
Design a system that allows DVDs to be rented to customers.
Design a video rental system. Sounds easy enough doesn't it? How do we know if the design is any good? What principles guide us in evaluating it?
It would seem that a consensus between designers would indicate a good design (or at least an informed agreement to disagree).
The idea that independent designers arriving at the same design provides evidence of goodness is echoed in the Rule of three from the Design patterns community. --Wal 00:14, 18 July 2008 (UTC)
Here is the Video Rental System design we came up with after a short period of group discussion.
I short order this class diagram was pulled apart for numerous reasons as will be discussed below. Feel free to find better ways of doing this and contribute to the discussion.
There are some things we did get right.
Using the Many to many association idiom to create a relationship between Customer and Title using the rental and transaction class is good.
There are many things that could be done better
The Title class suffers from some multiple personality problems. It is being used to represent the instance of a movie title while also it is being used to represent every physical instance of the movie in the store. By splitting the Title class on to two classes we take care of Separation of concerns and we Avoid redundant data. This has the benefit of only having to create one instance of each title that is in the store irrespective of the number of physical holdings.
And it looks like this
Actually I would argue that a Rental should link to a PhysicalHolding instead of a Title. If you wanted to incorporate, for instance, condition or some other difference between PhysicalHoldings it is useful to know which holding a Rental refers to. --Lukas Korsika 01:08, 21 October 2010 (UTC)
