Recently one of my teammates started refactoring a 2000 line code behind in one of our asp.net pages. When he mentioned that he was going to refactor this page, a few ears perked up. I got the vibe that when they heard the word refactor... they heard "Re-Write" and i felt inclined to jump in and provide a definition for them. Which i stole from Martin Fowler's definitive book on refactoring.
Refactoring is the process of improving the internal structure of the code without changing the external behavior of the code.
One of the other team members said "Sure, that's YOUR opinion".
I'll let you be the judge on that.
Anyhow, I was reading the Fowler book and found a nice little tidbit regarding BIG classes... namingly big UI classes. That works out well since that is what my friend is doing.
Basically he says if you have a large UI class with lots of instance variables to move those variables over to the domain class.
Then, he says, if you don't have a domain class... create one!
Well this probably would work out really well for this particular refactoring project because we have a LOT of domain data going on and all of this should be in the domain class. Unfortunately, we already have 'domain classes' that only have data and no behavior.
So my thinking is that a good way to do this is to use the decorator pattern to extend them with some functionality while maintaining the data that they have since they're coming from an object provider (n-tier architecture).
For example, consider this domain class.
public class Person
{
public string firstName;
public string lastName;
}
it's only data. if we wanted to add a method on here, such as "getFullName", we would have to extend this class. However, the problem raised here is that the web service gives us THIS class and we cannot modify that class's structure.
So let's try the decorator pattern like this:
public class DecoratorPerson : Person
{
private Person _personData;
public DecoratorPerson(Person personData)
{
_personData = personData;
}
public new string firstName
{
get { return _personData.firstName; }
set { _personData.firstName = value; }
}
public new string lastName
{
get { return _personData.lastName; }
set { _personData.lastName = value; }
}
public string fullName
{
get { return _personData.firstName + " " + _personData.lastName; }
}
}
So now I can get first name, last name, and the new functionality of “fullName” all with the ability to use this object interchangeably where I was previously using the “Person” object.