One Into Many

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
(New page: I encountered this during my design study. --~~~~ == Overview == This pattern is to be used in cases where a previous implementation has a one to one relationship and it needs to be modif...)
 
m (Reverted edits by Ebybymic (Talk); changed back to last version by Matthew Harward)
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
I encountered this during my design study. --[[User:Matthew Harward|Matthew Harward]] 00:57, 7 August 2009 (UTC)
 
 
 
== 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.
  
 
== The Problem ==
 
== 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 solve it.
+
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 ==
 
== General Issues ==
  
 
== 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

  1. If the class/object implements a Singleton pattern, remove the code required to save a single instance.
    1. Write a test to make sure multiple instances of the object can be instantiated, i.e. simply creating multiple instances.
    2. Change the code to work by changing the constructor access.
    3. Remove unnecessary code.
    4. Refactor as necessary.
  2. 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.
    1. Do not change existing interface initially.
    2. Write a test for the existence of the collection.
    3. Replace the existing field with a field holding the collection, making sure to rename the field.
    4. Get the test to past.
    5. Refactor to adjust any constructors as necessary.
    6. Refactor to change any existing getter/setter methods if required.
    7. Make sure all holding classes work for the situation.
    8. Make sure all aggregated classes work for the situation.
    9. Check any classes that use the model, refactor as necessary.
  3. If a more complex problem exists, follow these steps:
    1. ...

See Also

Personal tools