C# – What design pattern should I use for import, update, export

ccode-qualitydesign-patterns

I need to create a simple payments validator. On the following class diagram, I tried to present the model of payments. As you can see, each payment type inherits from Payments class.

Payments diagram

Now I want to work with these payments but hide the details so the user can only access what he needs. And those things are are:

Load payments from path and return list of payments

Save payments to path

Update input payments list and return updated list

I am not sure if the way I am doing it is correct.

My idea would be to use Facade design pattern, so PaymentsModel class which would contain following methods should be created:

public class PaymentsModel
{

    IList<ToBePaidPaymentsDto>  GetToBePaidPayments(string path){
         return new IList<ToBePaidPaymentsDto>();
    }

    IList<DonePaymentsDto>  GetDonePayments(string path){
         return new IList<DonePaymentsDto>();
    }

    IList<MissedPaymentsDto>  GetMissedPayments(string path){
         return new IList<MissedPaymentsDto>();
    }

    ...

}

Then create abstract class:

public abstract class Payments<T> 
{
    protected string Delimiter {get; private set;}
    protected int NumberOfHeaders {get; private set;}

    public abstract IList<T> LoadRecords(string path);

    public abstract IList<T> UpdateRecords(IList<T> records);

    public void SaveRecords(string path, DataGridViewRowCollection records)
    {
    }

}

where T is Data Transfer Object depending on the type of payments, so:

ToBePaidPayments class would use ToBePaidPaymentsDto

DonePayments class would use DonePaymentsDto

as presented below

public class PaymentsToBePaid : Payments<IcsToBePaidPaymentDto> {

    public override IList<IcsToBePaidPaymentDto> LoadRecords(string path){

        return null;
    }


    public override  IList<IcsToBePaidPaymentDto> UpdateRecords(IList<IcsToBePaidPaymentDto> records){

        return null;
    }

}

and

public class PaymentsDone : Payments<IcsDonePaymentDto>
{
    public override IList<IcsDonePaymentDto> LoadRecords(string path){

        return null;
    }

    public override IList<IcsDonePaymentDto> UpdateRecords(IList<IcsDonePaymentDto> records){

        return null;
    }

}

Now, my final question is – am I doing this correctly? Am I applying correct design pattern and am I applying it correctly?
Thank you for advice.

Best Answer

Given your comment that payments have different fields based on their status (and I will therefore assume this is an issue because of database tables), then What I'd do is implement a CsvReader class that has a generic-type argument, that maps Csv fields to the POCO in question. Therefore you'd write a single Csv Importer, and that can then be used to import data regardless of what class you throw at it.

Similarly, you can write a CsvExporter class that does the same thing. Write once, use everywhere.

Some comments:

Remove the Dto extension. We know what a payment is, it can potentially be used in many places (the database, the Csv File, business logic). Dto is relevant in a single, specific scenario.
Consider changing Todo to Pending.

Related Solutions

C# – Design Pattern for Logging Changes in Parent/Child Objects

Here are common design patterns to handle these scenarios.

Set up a base class. Child and parent will inherit from base. Base class should do the following:

Have a .Status property (read-only) that tracks if an object is {unchanged, new, updated, deleted} The status is set during {constructor, .delete() method, each Property's setter}. You will need a factory method to generate an object instance with a status of "unchanged" or a method to mark itself as "unchanged".
btw. This approach makes an object more "atomic" because it is self-contained and it keeps track of its own changes. This is also an example of why people use Properties (getters/setters) instead of public vars.
A commonly used pseudo locking mechanism is to use a combination of .LastModifiedDateTime (read only) and .LastModifier (read-only) columns on each DB table (non code-table/static-table). These are also set in the constructor/factory method. On Update/Save, compare the current LastModifiedDateTime & LastModifier to the DB. If they don't match then reject this change.

#1 is similar to the way many ORMs maintain state (handle changes). #2 is often referred-to as a "soft locking mechanism".

C# – Refactoring Abstract Classes into Helper Classes

From a software architecture perspective, is it a good approach to refactor such abstract classes that act as repositories of shared private methods (similar to above) into helper classes (or strategy pattern, if we want to call it that) as seen in Iteration 3? This question is not for this specific case but in general.

In general this is a reasonably good idea. Both helper classes and an abstract base class take the burden of knowing how to implement a certain bundle of functionality from a class, and hence allow us to consolidate shared functionality. The advantage of a helper class is that it allows us to change that functionality more dynamically and independently, we can replace the helper with a mock/stub during testing, inject different implementations of the helper and change two different dependents on the helper independently without changing their interfaces.

An abstract class has the advantage of convenience: it requires fewer keypresses to delegate functionality to a base class than a helper class. This is not a significant benefit. And when the abstract base class is just providing some private methods, its main advantages -- essentially serving as a template or transformation from interface to interface -- are not leveraged. So I think overall this is a solid idea.

If it is a good approach to do that refactoring, then what is the real use of abstract classes and the protected keyword as far as software design/architecture is concerned?

There are frequently cases where some functionality can be defined as a wrapper around some smaller set of functionality. There are a few subcases of this:

Checks around unsafe operations. Suppose I have a stack that should throw a IllegalOperationException when it is empty and pop is called. I can use an abstract class to abstract away these safety checks -- thus ensuring that child classes cannot forget to implement them. This can look like

public abstract class SafeStack<T> {
    protected abstract T UnsafePop();
    protected abstract int Size { get; }

    public T Pop() {
        if (this.Size <= 0) {
            throw new IllegalOperationException("Cannot pop an empty stack.");
        }
        return this.UnsafePop();
    }
}

"Template classes". Sometimes you get into cases where you have a number of classes that implement some common functionality by the same recipe. So I might have

public class ExcelReportGenerator {
    private void SaveToExcelFile(Summary summary){}

    public void SaveReport(ReportData data) {
        CleanReportData cleaned = data.Clean();
        Summary summary = cleaned.Summary();
        SaveToExcelFile(summary);
    }
}

public class HtmlReportGenerator {
    private void SaveToHtmlFile(Summary summary){}

    public void SaveReport(ReportData data) {
        CleanReportData cleaned = data.Clean();
        Summary summary = cleaned.Summary();
        SaveToHtmlFile(summary);
    }
}

You can remove the duplication by making an abstract ReportGenerator with a protected abstract SaveToFile(Summary) method.

Lots of delegation. Suppose you have classes implementing some ComplicatedMethod(ComplicatedParameters parameters) where the parameters have many optional parameters / reasonable defaults. If you want to define methods that delegate to the ComplicatedMethod(ComplicatedParameters) with various defaults set, an abstract base class with abstract ComplicatedMethod(ComplicatedParameters) with the delegating methods defined there is a reasonably nice way to accomplish this.

Now, you do not have to use abstract classes for any of these. You can always simulate an abstract class by defining an interface for the child class and taking that interface as a constructor parameter. And over the last decade or so mainstream languages have defined other nice ways for accomplishing the same thing, such as generic classes, extension methods or interface defaults.

I think there are still cases where you're trying to accomplish some mix of the above three where the niceties of using an abstract base class can overpower the downsides of inheritance to make it worthwhile.

Would an abstract class like AbstractAccountManager above be violating SRP after the methods were changed from private to protected (I suppose it can be argued that its no longer doing only one thing, but difficult to say when to stop identifying what a single responsibility should be)?

This is an interesting thought, and maybe? As you note, "responsibility" is a hard thing to really pin down, but in general going from private to protected is adding to your interface. A non-sealed class has three interfaces: the one it shows to the world (public) the one it shows to its its children (public and protected) and the one it shows to its overriders (virtual). If you think of responsibility as being tied to a class's interface, which is about right, then adding a protected member is growing the responsibility.

Bonus, unasked question. It looks to me like your example is crying out for a generic implementation. Something like

class AccountManager<TAccount> : IAccountManager where T : IAccount, new() {
    private int GetAccountId(string data) { 
        //Some data conversions, database references, calculations etc
        return accountId;
    }
    private int GetAccountName(string data) { 
        //Some data conversions, database references, calculations etc
        return name;
    }
    public void Import(string importData) {
        TAccount a = new TAccount();
        a.Id = GetAccountId(importData.Substring(11, 55); //hardcoding just to keep this example simple
        a.Name = GetAccountName(importData);
        a.Save();
    }
}

Best Answer

Related Solutions

C# – Design Pattern for Logging Changes in Parent/Child Objects

C# – Refactoring Abstract Classes into Helper Classes

Related Topic