Refactoring techniques. Data organization

Lecture



Refactoring this group is designed to facilitate the work with the data, replacing the work with primitive types of classes rich in functionality.

In addition, the important point is to reduce connectivity between classes, which improves the portability of classes and the chances of their reuse.

Field self-encapsulation

Problem: You are using direct access to private fields within a class.

Solution: Create a getter and setter for the field, and use only them to access the field.

Replacing a simple field with an object

Problem: In a class (or group of classes) there is a field of simple type. This field has its own behavior and associated data.

Solution: Create a new class, place the old field and its behavior in it, store the object of this class in the original class.

Replacing value by reference

Problem: There are many identical instances of the same class that can be replaced by a single object.

Solution: Turn identical objects into a single reference object.

Replacing a reference with a value

Problem: You have a reference object that is too small and unchangeable to justify the complexity of managing its life cycle.

Solution: Turn it into a value object.

Replacing an array field with an object

Problem: You have an array in which data of different types is stored.

Solution: Replace the array with an object that will have separate fields for each element.

Duplication of visible data

Problem: Program domain data is stored in classes responsible for the user interface (GUI).

Solution: It makes sense to allocate data domain in separate classes and, thus, to provide communication and synchronization between the domain class and the GUI.

Replacing unidirectional communication with bidirectional

Problem: You have two classes that need to use each other’s features, but only one-way communication exists between them.

Solution: Add the missing link to the class in which it is missing.

Replacing bidirectional unidirectional communication

Problem: You have two-way communication between classes, but one of the classes no longer uses the features of the other.

Solution: Remove unused communication.

Replace magic number with symbolic constant

Problem: The code uses a number that carries some specific meaning.

Solution: Replace this number with a constant with a human-readable title explaining the meaning of this number.

Field encapsulation

Problem: You have a public field.

Solution: Make the field private and create access methods for it.

Encapsulation collection

Problem: The class contains a collection field and a simple getter and setter for working with this collection.

Solution: Make the value returned by the getter read-only and create methods for adding / removing items from this collection.

Replacing coding type with class

Problem: The class has a field containing type coding. Values ​​of this type are not used in conditional statements and do not affect program behavior.

Solution: Create a new class and apply its objects instead of the values ​​of the encoded type.

Replacing coding type with subclasses

Problem: You have an encoded type that directly affects the behavior of the program (based on the values ​​of this field, various code is executed in the conditional statements).

Solution: For each value of the encoded type, create subclasses. And then, move the appropriate behaviors from the source class to these subclasses. Control code replace polymorphism.

Replacing coding with state / strategy

Problem: You have a coded type that affects behavior, but you cannot use subclasses to get rid of it.

Solution: Replace type encoding with a state object. If it is necessary to replace the value of the field with the type encoding, another state object is substituted into it.

Subclass substitution with fields

Problem: You have subclasses that differ only in methods that return constant data.

Solution: Replace the methods with fields in the parent class and remove the subclasses.


Comments


To leave a comment
If you have any suggestion, idea, thanks or comment, feel free to write. We really value feedback and are glad to hear your opinion.
To reply

Refactoring theory

Terms: Refactoring theory