I have two classes that read distinct files. As an examples, two classes, sourceA or Client, and sourceB or Resources:
public class Client()
{
public string ClientName {get; set;}
public int ClientNumber {get; set;}
public string Address {get; set;}
//...
}
public class Resources()
{
public int ClientNumber {get; set;}
public decimal Resources {get; set;}
//...
}
Let’s say that I need to merge booth classes into a new one, but I just need some fields from class Client and Resources. Is there any software pattern motivated by something like this, to compose a class like ClientReport?
The new class should be something like this:
public class ClientReport()
{
public string ClientName {get; set;}
public int ClientNumber {get; set;}
public string Address {get; set;}
public decimal Resources {get; set;}
public int CalculateRating()
{
//...
}
}
These new classe will have some properties of Client and Resources, and copying code from them in order to create ClientReport seems to be a repetition, and I think it should be a away to compose this class and only use the needed properties from Client and Resources.
8
Here are (at least) two objects client and report involved.
From what you write so far, a report seems best to be composed of a client and ressources:
public class ClientReport()
{
public Client client;
public decimal ressources;
public getClientName(){ return this.client.getName(); }
// ...
public setRessources(decimal ressources){ this.ressources=ressources; }
public ClientReport(Client client){
this.client=client;
}
}
Instead of copying the fields of the Client you should wrap the Client into the ClientReport (pass it via constructor) and delegate incoming calls of the report to the Client itself (see getClientName()). So you are free to hide/show (= encapsulate), whatever part of the Client you want. It makes sense to hide the creation of the ClientReport behind a Builder. The Builder reads first SourceA to generate the List<Clients>. After that it reads SourceB to map the ressources to the respective client. The Builder itself has only one method getClientReports(), which does all that transparently to the consumer.
You should further clean up your object design. Perhaps it makes sense in your domain to have an Address-object, which is wrapped by the Client object.
2
The definition of your client class should not be tied to how you acquire the data to construct the class. You should review your business requirements of your client class and define it based on that only.
From what you have shown so far, it looks like you need two file processing classes which both are provided a collection of client objects to work on, whether that is for creation or update.
The key thing is that the client class needs to be freestanding from the processing needed for the files. Tomorrow you may need to read from a database, or a web service, or something else, but that certainly doesn’t change the definition of a client in your business domain.
4
If I understand your question, the Facade Pattern fits your needs:
Intent:
- Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem
easier to use.- Wrap a complicated subsystem with a simpler interface.
Your Facade, the ClientReport class, has classes SourceA and SourceB by composition. The simpler, unified interface provided by ClientReport delegates to the appropriate methods of SourceA and SourceB; however, the client deals only with the ClientReport interface.
The link above has this checklist for using the Facade pattern:
- Identify a simpler, unified interface for the subsystem or
component.- Design a ‘wrapper’ class that encapsulates the subsystem.
- The facade/wrapper captures the complexity and collaborations of the
component, and delegates to the appropriate methods.- The client uses (is coupled to) the Facade only.
- Consider whether additional Facades would add value.
1