Depending on abstractions [1], decoupling [2] dependencies and segregating interfaces [3] are highly desirable design attributes to make systems that are easy maintain and extend over time. However if the fan-in [4] (S. Counsell, A. Mubarak, and R. M Hierons: An Evolutionary Study of Fan-in and Fan-out Metrics in OSS) coupling metrics of the resulting shared interfaces are low then the design leads to code bloat [5] as a side effect [6].
A common cause of low fan-in is the different types of arguments that a highly cohesive set of algorithms can handle. The following code helps to illustrate the previous situation by defining an IList.List function which is implemented by a DAO class.
public interface IListable
{
object List(int recordId);
}
public class DAO : IListable
{
public object List(int recordId)
{
//Code to query a data repository using the given Id
}
}
The purpose of the IList interface is providing a centralized List abstraction of repository records. The DAO class is a sample class to show the IList implementation. When different data types are needed (for instance: a record description of “string” type) then data type dependent interfaces becomes code bloat. A common approach for addressing the previous issue consist in upcasting [7] the input parameters to object types and providing metadata to perform the downcasting right.
This approach can be seen in the Microsoft’s DbParameter [8] and IDataParameter [9] implementations; those implementations provide a Value object property and a DbType meta-data property. This approach represents an issue because data must be casted and potentially boxed/unboxed [10]. Boxing (automatic or manual) is an expensive operation because a new wrapper must be allocated and constructed. UnBoxing is also expensive computationally.
A second well known approach is based on using Generics [11] or abstract algorithms with template [12] arguments’ types. The main issue of this kind of parametric polymorphism [13] is that function signatures are defined by the consumers of the interface, so the actual specific implementation has to cast to a specific type as described in the following RepositoryDAO.Get function.
public interface IGetable
{
object Get<T>(T contextData);
}
public class RepositoryDAO : IGetable
{
public object Get<T>(T contextData)
{
string obj = Convert.ToString(contextData);
//Do something with the value
}
}
Abstractions should not care about different types because their purpose is generalizing a behavior regardless of the underlying details. To keep the number of segregated integrated under a manageable number to make it easy to understand, maintain and extend a potential solution should provide static concrete arguments’ data types and inferred dynamic binding to avoid casting and code bloat. The previous new concept is expressed in the following pseudo code:
public interface IRead
{
object Read(dynamic T contextData);
}
public class DAOReader:IRead
{
public object Read(string contextData)
{
//Do something with the concrete argument
}
}
public class Consumer
{
public void Test()
{
IRead obj=new DAOReader();
obj.Read("Hello World!");
}
}
The previous potential requirements could be summarized as “Naming Interface Delegation” because the actual interface type definition is delegated to the consumer during early binding; plus they favor the Open Close design principle [14].
Note that pseudocode is for illustration purposes only because no formal research has been carried out at the moment. Also note that Naming Interface Delegtaion seem similar to Weak Typing and dynamic dispatch because their syntax is similar but the semantics are different. In the Weak Typing case syntax means that a few validation rules for compiling are in place while dynamic dispatch [15] is specific to dynamic selection of the callee/target function based on the caller’s data types. Because types are inferred during the dynamic binding by the interface, the variadic [16] functionality is not desirable.
Cheers,
Javier Andrés Cáceres Alvis
Microsoft Most Valuable Professional – MVP
Intel Black Belt Software Developer
