The problem with the work we do is it not just relevant to what is happening now, but often it must also be useful for the future as well. At work this week I have a great example of this, as we are squeezing new funtionality into the exisitng implementation. This works by extending our static and dynamic data objects to include new fields, the primary of these is to identify whether the object is the original or a new closely related alternate type
public class StaticData
{
public string Name;
public int Id;
public bool IsAlternate;
}
I admit this is not the cleanest design, I personally would argue against it, but it has being developed by our prototyping team in order to get the next phase of the product out very quickly. In our companies current position, Time to Market supersedes everything.
Anyway, the existing code now has a problem. We have the following protoype repeated in multiple layers and used in several exceutables and libraries within the solution.
public string GetStaticData(int ID)
In order to determine if something is the new alternate object we can of course do
public bool GetStaticDataIsAlternate(int ID)
But what happens if we need to implement other types within this framework. Do we continue adding methods?
public bool GetStaticDataIsOtherAlternate(int ID)
public bool GetStaticDataIsYetAnotherAlternate(int ID)
public string GetStaticDataOtherAlternateField(int ID)
public DateTime GetStaticDataYetAnotherAlternateDate(int ID)
Instead we have to change our design to "do exactly what it says on the tin". We actually return the Object not the Attribute
public StaticData GetStaticData(int ID)
This will mean that we change our calling code to be
BusinessObjectLayer.GetStaticData(y).Name;
We have an overhead of changing all references to the usage simply because we got the design wrong in the first place.