One Into Many
From CSSEMediaWiki
(Difference between revisions)
m (Reverted edits by Ebybymic (Talk); changed back to last version by Matthew Harward) |
|||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | |||
| − | |||
== Overview == | == Overview == | ||
This pattern is to be used in cases where a previous implementation has a one to one relationship and it needs to be modified to a one to many relationship. This pattern is specifically designed for Objects; however it may be used for lower or higher level concepts. | This pattern is to be used in cases where a previous implementation has a one to one relationship and it needs to be modified to a one to many relationship. This pattern is specifically designed for Objects; however it may be used for lower or higher level concepts. | ||
| Line 10: | Line 8: | ||
== Solution == | == Solution == | ||
| + | # If the class/object implements a [[Singleton]] pattern, remove the code required to save a single instance. | ||
| + | ## Write a test to make sure multiple instances of the object can be instantiated, i.e. simply creating multiple instances. | ||
| + | ## Change the code to work by changing the constructor access. | ||
| + | ## Remove unnecessary code. | ||
| + | ## Refactor as necessary. | ||
| + | # If it is a simple case of an object only being held by another object once when multiple are required, for instance, in a model, use a collection like a Set or List to encapsulate these objects. | ||
| + | ## Do not change existing interface initially. | ||
| + | ## Write a test for the existence of the collection. | ||
| + | ## Replace the existing field with a field holding the collection, making sure to rename the field. | ||
| + | ## Get the test to past. | ||
| + | ## Refactor to adjust any constructors as necessary. | ||
| + | ## Refactor to change any existing getter/setter methods if required. | ||
| + | ## Make sure all holding classes work for the situation. | ||
| + | ## Make sure all aggregated classes work for the situation. | ||
| + | ## Check any classes that use the model, refactor as necessary. | ||
| + | # If a more complex problem exists, follow these steps: | ||
| + | ## ... | ||
== See Also == | == See Also == | ||
Latest revision as of 03:11, 25 November 2010
Contents |
Overview
This pattern is to be used in cases where a previous implementation has a one to one relationship and it needs to be modified to a one to many relationship. This pattern is specifically designed for Objects; however it may be used for lower or higher level concepts.
The Problem
During initial coding/design, you failed to notice that a relationship had the potential to be one-to-many and instead coded it as one-to-one. Now, you realise your problem and need to rectify it.
General Issues
Solution
- If the class/object implements a Singleton pattern, remove the code required to save a single instance.
- Write a test to make sure multiple instances of the object can be instantiated, i.e. simply creating multiple instances.
- Change the code to work by changing the constructor access.
- Remove unnecessary code.
- Refactor as necessary.
- If it is a simple case of an object only being held by another object once when multiple are required, for instance, in a model, use a collection like a Set or List to encapsulate these objects.
- Do not change existing interface initially.
- Write a test for the existence of the collection.
- Replace the existing field with a field holding the collection, making sure to rename the field.
- Get the test to past.
- Refactor to adjust any constructors as necessary.
- Refactor to change any existing getter/setter methods if required.
- Make sure all holding classes work for the situation.
- Make sure all aggregated classes work for the situation.
- Check any classes that use the model, refactor as necessary.
- If a more complex problem exists, follow these steps:
- ...
