Video rental system
| 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 8: | Line 7: | ||
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). | ||
| + | |||
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. | ||
| Line 15: | Line 15: | ||
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]] | ||
Revision as of 04:48, 17 July 2008
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).
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
