May 2002

This is a list of refactoring that I am primarly interested in.

Refactorings are split into three groups. The refactoring are chosen in this way so that compound refactorings can be implemented with creater ease, and the possible set of refactorings is still covered.

• Add complexity: which means it can store strictly more detail than the original
• Remove complexity: simplfiy structure by making assuptions
• Ease use: add interfaces that help the programmer do more in less code

  The bijections between the new and the old projects need to sipulate what happens when the simpler project can not handle the complexity of the other AND what happens when the simplicty of one requires assumptions added for the complex.

Add complexity

Push Down Field - The field is pushed down to all existing children.

Refer to old field and all new replacments.

Pull Up Field - move a field from a class to the parent class. This requires providing a default field value for all objects in (A - B), assuming A B. Or this requires invalidating any objects in (A-B). Field values in (A - B) are not accessable to old project.

Refer to old and new field

Add Field - allow values to be stored

Refer to new field

Extract Class from Field(s) - the extra complexity comes from the fact that similar Address and PhoneNumber can technically be different locations.

CLASS Person{
     FIELD Name AS String
     FIELD Address AS String
     FIELD PhoneNumber AS String
}

=>

CLASS Person{
     FIELD Name AS String
     FIELD Location
}

CLASS Location{
     FIELD Address AS String
     FIELD PhoneNumber AS String
}

Make new class, refer to old and new fields.

Extract Many Class from Field(s) - The new schema allows mutiple values where before only one was allowed.

CLASS Object{
     FIELD Name AS String
}

=>

CLASS Object{
}

CLASS Name{
     FIELD Object
     FIELD Value AS String
}

• OR

  CLASS Person{
       FIELD Name AS String
       FIELD Address AS String
       FIELD PhoneNumber AS String
  }

  =>

  CLASS Person{
       FIELD Name AS String
  }

  CLASS Location{
       FIELD Person
       FIELD Address AS String
       FIELD PhoneNumber AS String
  }

Make new class, then associate new and old fields.

Extract Subclass from Fields - The selected fields are optional

CLASS Person{
     FIELD Name AS String
     FIELD Address AS String
     FIELD PhoneNumber AS String
}

=>

CLASS Person{
     FIELD Name AS String
}

CLASS Location EXTENDS Person{
     FIELD Address AS String
     FIELD PhoneNumber AS String
}

Make new class, then associate new and old fields

Generalize field type - allow a greater range of values for a field

Add subclass (annotate)

Field to Space Value (consistency kept)

CLASS Object{
     FIELD Name AS String
}

=>

CLASS Object{
}

CLASS Name{
     FIELD* NameSpace;
     FIELD* Object
     FIELD Value AS String
}

Remove Complexity

Remove Field - field values are inaccessable in new project.

Make Key - Declare a set of fields a key, restrict the combination of field values to be unique. Must determine what to do with key collisions. Most times we will be using Attribute to Space Value.

Assume only one object in a class exists

Any spaces that refer to that class collapse to one less dimension

(Class, Database) = (Table)
=> (Class) = (Table)

Change field type to more restrictive -

Assume only one value for a field - a more restritive version of above

field becomes a class field

Inline Class -

Change Value to reference - (identical strings should be the same object)

Ease of Use:

Make Set from many field for reverse lookup (ease of use)

Type Code <=> Class (Male/Female)