Inheritence Hierarchy

Dzmitry Huba wrote the following here about Inheritence:

If two or more classes share only common data (no common behavior), then that common data should be placed in a class that will be contained by each sharing class.

If two or more classes have common data and behavior (i.e., methods), then those classes should each inherit from a common base class that captures those data and methods.

If two or more classes share only a common interface (i.e., messages, not methods), then they should inherit from a common base class only if they will be used polymorphically.

… Just something I want to ponder at some point soon.


Repository Pattern

Updated 2009-12-30 – Adjusted  the title to be a general post about the Repository pattern, added links to other posts, forum entries and information, slightly re-organized.

I’ve been looking at the general problem of developing an API and the issues that result, and this is in the context of the repository pattern particularly. Though I don’t think the issues are any different when not using the repository pattern. You still need to be able to load the data you need and avoid issues like: If I Eager load I’ll have way to much data, if I load it when i need it I’ll be opening connections all over the place. With the repository pattern you break the practice of separation of concerns if you inject a reference to any required repositories or services etc. If you actually just provide somewhere on an entity to put it’s sub-entity or a collection and only load it when you need it… well that just doesn’t feel right at all…

Definition of the Repository Pattern

The lazy Loading Approach

The Non Lazy Loading Approach

Use the Repository Pattern

Don’t Use the Repository Pattern

Examples and others