http://www.dotnetcurry.com/patterns-practices/1381/using-generics-csharp-maintainability
Quoting:
"When we encapsulate data, we can change the internal representation of the data without affecting the consumers of the unit encapsulating the data.
On the other hand, when we don’t encapsulate data, the behavior units will access data (received as method parameters for example) directly and therefore they have a hard dependency on the internal representation of the data.
Therefore, when doing behavior-only encapsulation, it is harder to change the internal representation of data.
In this article, I am going to discuss how we can use generics in C# to make it easier to handle data-related change requests in software applications when doing behavior-only encapsulation."
(...)
"You aren’t gonna need it (The YAGNI principle)
Should we always separate data-independent and data-dependent logic into different classes?
Should we make our data-independent classes generic from the start?
Well, it depends.
But in most of the cases, we don’t have to.
In most of the cases, applications start small, and then they evolve with time. It is important to first concentrate efforts on meeting the requirements we have at hand. We can always refactor later to meet new requirements.
In a document processing application that processes plain text documents only, we can start normally without making the document type generic in the classes that deal with documents.
Later, when we need to introduce different documents types, we can refactor existing classes/interfaces to become generic, and we can also refactor to separate data-independent behavior and data-dependent behavior into different classes.
If we follow the SOLID principles (the Single Responsibility Principle in particular), chances are that separation of data-independent and data-dependent behavior, is already high. Also, refactoring in this case would be a lot easier compared to when our classes are very long."
