We Keep Coding

OO Design - Exposing implementation details through an interface

I have a class, which holds some details in a large data structure, accepts an algorithm to perform some calculations on it, has methods to validate inputs to the data structure.
But then I would like to return the data structure, so that it can be transformed into various output forms (string / C# DataTable / custom file output) by the View Model.
class MyProductsCollection {
private IDictionary<string, IDictionary<int, ISet<Period>>> products;
// ctors, verify input, add and run_algorithm methods
}
I know that you are supposed to use the "depend on interface not implementation" design principle, so I want to create an interface for the class.
How can I avoid writing the following interface?
Reason being it would expose implementation details and bind any other concrete implementations to return the same form.
interface IProductsCollection {
IDictionary<string, IDictionary<int, ISet<IPeriod>>> GetData();
// other methods
}
How can I easily iterate over the data structure to form different varieties of outputs without bluntly exposing it like this?
EDIT:
Since the class takes in IFunc<IDictionary<string, IDictionary<int, ISet<IPeriod>>>> in the constructor to iterate over the data structure and perform calculations, I could supply it with another IFunc, which would construct the output instead of running calculations. However, I don't know how I could do this aside from the concrete class constructor.

The structure of the IDictionary<string,IDictionary<int,ISet<Period>>> is very suspicious indeed - when you see a dictionary of dictionaries, good chances are that you have missed an opportunity or two to create a class to encapsulate the inner dictionary.
Without knowing much of the domain of your problem, I would suggest defining an interface to encapsulate the inner dictionary. It looks like something that associates a number to a set of periods, so you would define an interface like this:
interface IYearlyPeriods {
bool HasPeriodsForYear(int year);
ISet<Periond> GetPeriodsForYear(int year);
}
I have no idea what's in the periods, so you would need to choose a domain-specific name for the interface.
Moreover, you can wrap the next level of IDictionary too:
interface IProductDataSource {
IEnumerable<string> ProductNames { get; }
IYearlyPeriods GetProductData(string productName);
}
Now you can define an interface like this:
interface IProductsCollection {
IProductDataSource GetDataSource();
// other methods
}
The main idea is to use domain-specific interfaces in place of generic collections, so that the readers and implementers of your code would have some idea of what's inside without referring to the documentation.
You could go even further, and replace the IDictionary with the complex structure that you keep internally with an IDictionary of IProductPeriods implementation. If you would like to keep IYearlyPeriods that you expose to the users immutable, but would like to be able to make modifications yourself, you can make a mutable implementation, and keep it internal to the implementing class.

I would suggest to keep the IDictionary private and provide a simple IEnumerable in the interface.
In your case this could be a custom DTO that hides all the nastiness of the IDictionary<int, ISet<IPeriod>> - which is already quite complex and could (probably) easily change as you need to implement new features.
This could be something like:
class ExposedPeriod
{
public int PeriodIdentifier { get; set; }
public IEnumerable<IPeriod> Periods { get; set; }
}
The ExposedPeriod and PeriodIdentifier probably need better names though. Good names might be found in your domain vocabulary.

Factory pattern with objects that have many optional properties

I'm refactoring a class that represents the data in some XML. Currently, the class loads the XML itself and property implementations parse the XML every time. I'd like to factor out the XML logic and use a factory to create these objects. But there are several 'optional' properties and I'm struggling to find an elegant way to handle this.
Let's say the XML looks like this:
<data>
<foo>a</foo>
<bar>b</bar>
</data>
Assume both foo and bar are optional. The class implementation looks something like this:
interface IOptionalFoo
{
public bool HasFoo();
public string Foo { get; }
}
// Assume IOptionalBar is similar
public class Data : IOptionalFoo, IOptionalBar
{
// ...
}
(Don't ask me why there's a mix of methods and properties for it. I didn't design that interface and it's not changing.)
So I've got a factory and it looks something like this:
class DataFactory
{
public static Data Create(string xml)
{
var dataXml = new DataXml(xml);
if (dataXml.HasFoo())
{
// ???
}
// Create and return the object based on the data that was gathered
}
}
This is where I can't seem to settle on an elegant solution. I've done some searching and found some solutions I don't like. Suppose I leave out all of the optional properties from the constructor:
I can implement Foo and Bar as read/write on Data. This satisfies the interface but I don't like it from a design standpoint. The properties are meant to be immutable and this fudges that.
I could provide SetFoo() and SetBar() methods in Data. This is just putting lipstick on the last method.
I could use the internal access specifier; for the most part I don't believe this class is being used outside of its assembly so again it's just a different way to do the first technique.
The only other solution I can think of involves adding some methods to the data class:
class Data : IOptionalFoo, IOptionalBar
{
public static Data WithFoo(Data input, string foo)
{
input.Foo = foo;
return input;
}
}
If I do that, the setter on Foo can be private and that makes me happier. But I don't really like littering the data object with a lot of creation methods, either. There's a LOT of optional properties. I've thought about making some kind of DataInitialization object with a get/set API of nullable versions for each property, but so many of the properties are optional it'd end up more like the object I am refactoring becomes a facade over a read/write version. Maybe that's the best solution: an internal read/write version of the class.
Have I enumerated the options? Do I need to quit being so picky and settle on one of the techniques above? Or is there some other solution I haven't thought of?

You can think of such keywords as virtual/castle dynamic proxy/reflection/T4 scripts - each one can solve the problem on a slightly different angle.
On another note, this seems perfectably reasonable, unless I misunderstood you:
private void CopyFrom(DataXml dataXml) // in Data class
{
if (dataXml.HasFoo()) Foo = dataXml.Foo;
//etc
}

What I did:
I created a new class that represented a read/write interface for all of the properties. Now the constructor of the Data class takes an instance of that type via the constructor and wraps the read/write properties with read-only versions. It was a little tedious, but wasn't as bad as I thought.

Generic Interface w/ Polymorphism to handle Objects

Previous Post removed; Updated:
So I have a unique issue, which is possibly fairly common though. Properties are quite possibly are most commonly used code; as it requires our data to keep a constant value storage. So I thought how could I implement this; then I thought about how easy Generics can make life. Unfortunately we can't just use a Property in a Generic without some heavy legwork. So here was my solution / problem; as I'm not sure it is the best method- That is why I was seeking review from my peers.
Keep in mind the application will be massive; this is a very simple example.
Abstract:
Presentation Layer: The interface will have a series of fields; or even data to go across the wire through a web-service to our database.
// Interface:
public interface IHolder<T>
{
void objDetail(List<T> obj);
}
So my initial thought was an interface that will allow me to Generically handle each one of my objects.
// User Interface:
public class UI : IHolder
{
void objDetail(List<object> obj)
{
// Create an Instance
List<object> l = new List<object>();
// Add UI Fields:
l.Add(Guid.NewGuid());
l.Add(txtFirst.Text);
l.Add(txtLast.Text);
// l to our obj
obj = l;
return;
}
}
Now I have an interface; which has been used by our UI to put information in. Now; this is where the root of my curiosity has been thrown into the mixture.
// Create an Object Class
public class Customer : IHolder
{
// Member Variable:
private Guid _Id;
private String _First;
private String _Last;
public Guid Id
{
get { return _Id; }
set { _Id = value; }
}
public String First
{
get { return _First; }
set { _First = value; }
}
public String Last
{
get { return _Last; }
set { _Last = value; }
}
public virtual objDetail(List<Customer> obj)
{
// Enumerate through List; and assign to Properties.
}
}
Now this is where I thought it would be cool; if I could use Polymorphism to use the same interface; but Override it to do the method differently. So the Interface utilizes a Generic; with the ability to Morph to our given Object Class.
Now our Object Classes; can move toward our Entity interface which will handle basic Crud Operation.
I know this example isn't the best for my intention; as you really don't need to use Polymorphism. But, this is the overall idea / goal...
Interface to Store Presentation Layer UI Field Value
Implement the Properties to a Desired Class
Create a Wrapper Around my Class; which can be Polymorphed.
Morphed to a Generic for Crud Operation
Am I on the right path; is this taboo? Should I not do this? My application needs to hold each instance; but I need the flexibility to adapt very quickly without breaking every single instance in the process. That was how I thought I could solve the issue. Any thoughts? Suggestions? Am I missing a concept here? Or am I over-thinking? Did I miss the boat and implement my idea completely wrong? That is where I'm lost...

After pondering on this scenario a bit, I thought what would provide that flexibility while still ensuring the code is optimized for modification and business. I'm not sure this is the right solution, but it appears to work. Not only does it work, it works nicely. It appears to be fairly robust.
When is this approach useful? Well, when you intend to decouple your User Interface from your Logic. I'll gradually build each aspect so you can see the entire structure.
public interface IObjContainer<T>
{
void container(List<T> object);
}
This particular structure will be important. As it will store all of the desired content into it.
So to start you would create a Form with a series of Fields.
Personal Information
Address Information
Payment Information
Order Information
So as you can see all of these can be separate Database Tables, but belong to a similar Entity Model you are manipulating. This is quite common.
So a Segregation Of Concern will start to show slightly, the fields will be manipulated and passed through an Interface.
public interface IPersonalInformation
{
public string FirstName { get; set; }
public string LastName { get; set; }
}
So essentially the Interface is passing its variable, to the Interface. So you would culminate an interface to handle that entire form or individual interfaces that you wish to call so that they remain reusable.
So now you have a series of Interfaces, or a single once. But it contains all these variables to use. So you would now create a class:
public class CustomerProperties: IPersonalInformation, IOrderInformation
{
// Implement each Interface Property
}
Now you've created a container that will hold all of your values. What is nifty about this container is you can reuse the same values for another class in your application or choose different ones. But it will logically separate the User Interface.
So essentially this is acting similar to a Repository.
Now you can take these values and perform the desired logic. What becomes wonderful now, is after you've performed your logic you pass the object into our Generic List. Then you simply implement that method in another class for your goal and iterate through your list.
The honesty is it appears to work well and decouple nicely. I feel that it was a lot of work to do something similar to a normal Repository and Unit Of Work, this answers the question but weather or not it is ideal for your project I would look into Repository, Unit Of Work, Segregation Of Concern, Inversion Of Control, and Dependency Injection. They may do this same approach cleaner.
Update:
I thought about it after I wrote this up, I noticed you could actually implement those property values into the Generic List structure bypassing a series of interfaces; but that would introduce consistency issues as you'd have to be aware of what data is being passed in each time, in order. It's possible, but may not be ideal.

Refactoring into sub classes

public class ScheduleRatesController
{
protected CoreDataManager dataManager;
public ScheduleRatesController()
{
dataManager = new CoreDataManager();
}
// testing
public ScheduleRatesController(CoreDataManager manager)
{
dataManager = manager;
}
public virtual void GetTranQuotesToFillRatesAndPayments(ref List<int> ids)
{
ids.AddRange(new List<int>());
}
}
So to give you guys some background, we're splitting one DB query into a bunch of different ones, and we want subclasses to basically each take on a DB call for their GetTranQuotesToFillRatesAndPayments() method that represents it's specific query.
What you see above is the base class I have. I made those two methods virtual as I plan on having subclasses override them to perform their own stuff. So one could be like:
public override void GetTranQuotesToFillRatesAndPayments(ref List<int> ids)
{
ids.AddRange(dataManager.GetLoanTranQuotes());
}
and etc. My question is, is this the best/cleanest way to perform a pattern like this?
The code that calls this is going to contain a huge list of filtered id's, that it's going to need to fill by calling each classes call to GetTranQuotesToFillRatesAndPayments(). Let me know if this doesn't make sense. I'm kind of getting turned off by the fact that I'm going to need to call the same method like 6 times, each on a different class. I think that might be messy in itself even though the goal of it was to make it clean. I don't want to have something like this on the calling side:
List<int> ids = new List<int>();
ScheduleRatesController controller = new LoanController();
controller.GetTranQuotesToFillRatesAndPayments(ref ids);
controller = new TradeController();
controller.GetTranQuotesToFillRatesAndPayments(ref ids);
etc.
Let me know if you need any more background or info.
Thanks.

Several design remarks:
Using the ref keyword usually indicates design problems and should be avoided. There is no need to pass a reference value using the ref keyword (any List<T> is always passed by reference). Your program would work equally without it.
A better idea than passing your list to the method would be to return your data from the method, and allow callers to decide what to do with it. Maybe you will only want to find a single value at some other place in your program, and creating a new list is an overkill. Also, you should try to add as little functionality as possible to each class (Single Responsibility Principle), and your class is right now responsible for fetching the data and deciding how it should be stored.
Naming: your method name is really complex. Also, the name "controller" doesn't usually represent an object responsible for fetching data.
On the other hand, you have a CoreDataManager class (btw, Manager is a bad suffix for any class), which appears to contain a bunch of methods which return various data. What is the need for ScheduleRatesController then? Does it only copy this to a list?
Business logic should be separated from your Data access layer. You should consider using Repository pattern, or similar (check this answer, for example), to ensure that your data class only fetches the data from the DB.
If you have several classes which need to fulfill a certain contract, start by creating the interface which they need to implement. Don't think about reusing code at this time. Your code, for example, forces all subclasses to use the CoreDataManager, while one day it may turn out that a certain "controller" might need to be composed of different objects.

Use a List<Func<List<int>,List<int>>>. Which is basically a list of functions with the following type signature:
List<int> MyFunc(List<int> foo);
You can then pass the list of functions to a method that works like the following:
public List<int> GetAllIds(List<Func<List<int>,List<int>>> functionList) {
var listOfIds = new List<int>();
foreach(var f in functionList) {
listOfIds = f(listOfIds);
}
return listOfIds;
}
You can use lambdas to compose functionList like so:
functionList.Add(list => {
list.AddRange(dataManager.GetLoanTranQuotes());
return list;
});
Now you do not have to depend on any specific inheritance hierarchy. You can use function composition to produce the whole list.

Object Design: How to Organize/Structure a "Collection Class"

I'm currently struggling to understand how I should organize/structure a class which I have already created. The class does the following:
As its input in the constructor, it takes a collection of logs
In the constructor it validates and filters the logs through a series of algorithms implementing my business logic
After all filtering and validation is complete, it returns a collection (a List) of the valid and filtered logs which can be presented to the user graphically in a UI.
Here is some simplified code describing what I'm doing:
class FilteredCollection
{
public FilteredCollection( SpecialArray<MyLog> myLog)
{
// validate inputs
// filter and validate logs in collection
// in end, FilteredLogs is ready for access
}
Public List<MyLog> FilteredLogs{ get; private set;}
}
However, in order to access this collection, I have to do the following:
var filteredCollection = new FilteredCollection( specialArrayInput );
//Example of accessing data
filteredCollection.FilteredLogs[5].MyLogData;
Other key pieces of input:
I foresee only one of these filtered collections existing in the application (therefore should I make it a static class? Or perhaps a singleton?)
Testability and flexibility in creation of the object is important (Perhaps therefore I should keep this an instanced class for testability?)
I'd prefer to simplify the dereferencing of the logs if at all possible, as the actual variable names are quite long and it takes some 60-80 characters to just get to the actual data.
My attempt in keeping this class simple is that the only purpose of the class is to create this collection of validated data.
I know that there may be no "perfect" solution here, but I'm really trying to improve my skills with this design and I would greatly appreciate advice to do that. Thanks in advance.
EDIT:
Thanks to all the answerers, both Dynami Le-Savard and Heinzi identified the approach I ended up using - Extension Methods. I ended up creating a MyLogsFilter static class
namespace MyNamespace.BusinessLogic.Filtering
{
public static class MyLogsFilter
{
public static IList<MyLog> Filter(this SpecialArray<MyLog> array)
{
// filter and validate logs in collection
// in end, return filtered logs, as an enumerable
}
}
}
and I can create a read only collection of this in code by doing
IList<MyLog> filteredLogs = specialArrayInput.Filter();
ReadOnlyCollection<MyLog> readOnlyFilteredLogs = new ReadOnlyCollection<MyLog>(filteredLogs);

It sounds like you do three things to your logs:
Validate them
Filter them
and
Access them
You want to store the logs in a collection. The standard List collection is a good fit since it doesn't care what's in it, gives you LINQ and allows you to lock the collection with a read-only wrapper
I would suggest you separate your concerns into the three steps above.
Consider
interface ILog
{
MarkAsValid(bool isValid);
... whatever data you need to access...
}
Put your validation logic in a separate interface class
interface ILogValidator
{
Validate(ILog);
}
And your filtering logic in yet another
interface ILogFilter
{
Accept(ILog);
}
Then with LINQ, something like:
List<MyLog> myLogs = GetInitialListOfLogsFromSomeExternalSystem();
myLogs.ForEach(x => MyLogValidator(x));
List<MyLog> myFilteredLogs = myLogs.Where(x => MyLogFilter(x));
The separation of concerns makes testing and maintainability much better. And stay away from the singletons. For many reasons including testability they are out of favor.

The way I see it, you are looking at a method that returns a collection of filtered log, rather than a collection class wrapping your business logic. Like so:
class SpecialArray<T>
{
[...]
public IEnumerable<T> Filter()
{
// validate inputs
// filter and validate logs in collection
// in end, return filtered logs, as an enumerable
}
[...]
}
However, it does look like what you really wish is actually to separate the business logic in charge of filtering the logs from the SpecialArray class, perhaps because you feel like the logic touches many things that do not really concern SpecialArray, or because Filter does not apply to all generic cases of SpecialArray.
In that case my suggestion would be to isolate your business logic in another namespace, perhaps one that uses and/or requires other components in order to apply said business logic, and offer your functionality as an extension method, concretly :
namespace MyNamespace.Collections
{
public class SpecialArray<T>
{
// Shenanigans
}
}
namespace MyNamespace.BusinessLogic.Filtering
{
public static class SpecialArrayExtensions
{
public static IEnumerable<T> Filter<T>(this SpecialArray<T> array)
{
// validate inputs
// filter and validate logs in collection
// in end, return filtered logs, as an enumerable
}
}
}
And when you need to use that business logic, it would look like this :
using MyNamespace.Collections; // to use SpecialArray
using MyNamespace.BusinessLogic.Filtering; // to use custom log filtering business logic
namespace MyNamespace
{
public static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main2()
{
SpecialArray<Logs> logs;
var filteredLogs = logs.Filter();
}
}
}

Some thoughts:
As you correctly point out, using an instanced class improves testability.
Singletons should be used if (A) there is only one instance of the class in your whole system and (B) you need to access this instance at multiple different places of your application without having to pass the object around. Unnecessary use of the Singleton pattern (or any other kind of "global state") should be avoided, so unless (B) is satisfied in your case as well, I'd not use a singleton here.
For simple dereferencing, consider using an indexer. This will allow you to write:
FilteredCollection filteredlogs = new FilteredCollection( secialArrayInput );
//Example of accessing data
filteredlogs[5].MyLogData;
If your class only consists of a constructor and a field to access the result, using a simple method might be more appropriate than using a class. If you want to do it the fancy way, you could write it as an extension method for SpecialArray<MyLog>, allowing you to access it like this:
List<MyLog> filteredlogs = secialArrayInput.Filter();
//Example of accessing data
filteredlogs[5].MyLogData;

If you want to inherit the interface of SpecialArray for you final filtered array then derive from SpecialArray instad of having an instance member. That would allow:
filteredCollecction[5].MyLogData;
etc..