We are now going to talk about the extract class refactoring. When a
softer system evolves, we might end up with classes that really do the
work of more than one class because we keep adding functionality to
the class. Therefore also they're too
big, too complicated. In particular, we might
end up with a class that is doing the work of two
classes. Typical examples are classes with many methods and quite a lot of
data, quite a lot of fields. In this case, it's normally good idea
to split the class into two, so what you will do, you will
create a new class and move there the relevant fields and methods from
the original class. So as to have two classes, each one implementing a
piece of the functionality. Let's look at an example. In this case we're
going to use a UML like representation for the class. We have this class Person
that ends up representing also a phone number. And imagine that we add
up these pieces, you know, a little bit at the time so we end
up with something that really is doing the job of the person and
of the phone number. So what we can do, we can actually do exactly
what we described here. We split this class
into a Person class, and the Phone Number class.
And then we establish a use relation, so we
have a reference of the phone number class into
this class. And by separating the telephone number behavior
into its own class, I once more improved the
structure of the code, because now I have classes
that are more cohesive, and do exactly one thing.