Return interface inherited classes in Generic method - c#

I have 3 objects that are very similar with only a few differences
public class Person
{
public Person(ResourceObject resource)
{
// resource comes from an API provided by one
// of our systems (i have no control over it)
this.ResourceObject = resource;
}
// Resource
internal ResourceObject ResourceObject { get; }
// Similar properties
public string ObjectID { get; }
public string ObjectType { get; }
public IEnumerable<string> PropertyNames { get; }
// Person-specific property example - Organisation
public string Organisation { get; set; }
}
public class Computer
{
public Computer(ResourceObject resource)
{
// resource comes from an API provided by one
// of our systems (i have no control over it)
this.ResourceObject = resource;
}
// Resource
internal ResourceObject ResourceObject { get; }
// Similar properties
public string ObjectID { get; }
public string ObjectType { get; }
public IEnumerable<string> PropertyNames { get; }
// Computer-specific property example - OperatingSystem
public string OperatingSystem { get; set; }
}
public class Group
{
public Group(ResourceObject resource)
{
// resource comes from an API provided by one
// of our systems (i have no control over it)
this.ResourceObject = resource;
}
// Resource
internal ResourceObject ResourceObject { get; }
// Similar properties
public string ObjectID { get; }
public string ObjectType { get; }
public IEnumerable<string> PropertyNames { get; }
// Group-specific property example - Members
public string Members { get; set; }
}
I currently have GetPerson, GetComputer and GetGroup methods that are working but they essentially do the same thing and then call one of the specific object constructors. In an effort to dive into the world of Generics and Interfaces and learn more (as you do) i attempted to create a GetResource<T> method that would do the same job as those 3 methods without all the duplicate code.
I created the IResource Interface to identify common properties:
public interface IResource
{
string ObjectID { get; }
string ObjectType { get; }
IEnumerable<string> PropertyNames { get; }
}
and then attempted to create a GetResource<T> method but got stuck at the return code:
public static T GetResource<T>(string identity) where T : IResource
{
// get resource from system API
// and then return T somehow?
return new T(resourceObject);
}
I thought of changing the return value from T to IResource but i'm still not sure how i would identify which class to return (Perhaps i need a base class? Resource perhaps).
The reason i turned to Generics for this specific situation is if the system API updates and suddenly has a new Location object i don't want to have to create a GetLocation method and then have 4 methods that do exactly the same thing except for one line of code.
Is this the correct use case for Generics? and if so how can my method figure out what object to return?

Use a base class to hold common behavior.
public abstract class Resource {
protected Resource (ResourceObject resource) {
// resource comes from an API provided by one
// of our systems (i have no control over it)
this.ResourceObject = resource;
}
// Resource
internal ResourceObject ResourceObject { get; }
// Similar properties
public string ObjectID { get; }
public string ObjectType { get; }
public IEnumerable<string> PropertyNames { get; }
}
Derived classes
public class Person : Resource {
public Person(ResourceObject resource):base(resource){
}
// Person-specific property example - Organisation
public string Organisation { get; set; }
}
public class Computer : Resource {
public Computer(ResourceObject resource) : base(resource) {
}
// Computer-specific property example - OperatingSystem
public string OperatingSystem { get; set; }
}
public class Group : Resource {
public Group(ResourceObject resource) : base(resource) {
}
// Group-specific property example - Members
public string Members { get; set; }
}
Interfaces can't be initialized and thus trying to pass a constructor argument wont work.
With the base class constraint the generic method becomes
public static T GetResource<T>(string identity) where T : Resource {
// get resource from system API
// and then return T somehow?
return (T) Activator.CreateInstance(typeof(T), resourceObject);
}
And used
Person person = GetResource<Person>("person_identity");

Related

Need solution regarding generic c# method

I am trying to make my method generic and I am stuck at a point and need your assistance. The code scenario is I have an abstract class say MyBaseAbs which contains common properties:
public abstract class MyBaseAbs
{
public string CommonProp1 { get; set; }
public string CommonProp2 { get; set; }
public string CommonProp3 { get; set; }
}
Now I have child classes:
public class Mychild1: MyBaseAbs
{
public string Mychild1Prop1 { get; set; }
public string Mychild1Prop2 { get; set; }
public string Mychild1Prop3 { get; set; }
}
and another child class:
public class Mychild2: MyBaseAbs
{
public string Mychild1Prop1 { get; set; }
public string Mychild2Prop2 { get; set; }
}
Now I have to create a common method which needs to perform some operations on the basis of Mychild1 and Mychild2, so what I did is:
public MyCustomClass SaveOperation<T>(T myObj)
where T : MyBaseAbs
{
SaveObject obj = new SaveObject();
}
so inside this method I need to write common code which does the mapping for SaveObject object according to the child object passed. How can I determine which object is passed and use properties accordingly.
One option would be to create a base Save function in your base class and make it virtual.
Then override the method in your child classes. This way when you call the Save method in your SaveOperation it should call the appropriate method from the correct child class.
public abstract class MyBaseAbs
{
public string CommonProp1 { get; set; }
public string CommonProp2 { get; set; }
public string CommonProp3 { get; set; }
public virtual void Save() { }
}
public class Mychild1: MyBaseAbs
{
public string Mychild1Prop1 { get; set; }
public string Mychild1Prop2 { get; set; }
public string Mychild1Prop3 { get; set; }
public override void Save() {
//Implementation for Mychild1
}
}
public class Mychild2: MyBaseAbs
{
public string Mychild1Prop1 { get; set; }
public string Mychild2Prop2 { get; set; }
public override void Save() {
//Implementation for Mychild2
}
}
If you can't modify your business objects, you can check the type of the concrete class in the SaveOperation method:
public MyCustomClass SaveOperation<T>(T myObj)
where T : MyBaseAbs
{
SaveObject obj = new SaveObject();
if (myObj is Mychild1) {
Mychild1 mychild1 = (Mychild1) myObj;
// Business logic for object of type Mychild1
} else if (myObje is Mychild2) {
Mychild2 mychild2 = (Mychild2) myObj;
// Business logic for object of type Mychild2
}
}
Notice that this is not a very solid solution as, if you are creating new objects that implement your abstract class, you will have to remeber to add another branch in the if statement.
As #BojanB mentioned, the obvious solution would be to create a virtual method in your base class and override it in the derived, but if you cannot modify the code there then you can create a method for each derived class and create a dictionary that maps each type to its method:
private Dictionary<Type, Action<MyBaseAbs, MyCustomClass>> _saveOperations =
new Dictionary<Type, Action<MyBaseAbs, MyCustomClass>>();
//You can then set an entry for each of your derived classes
_saveOperations[typeof(Mychild1)] = (myObj, myCustomObj) =>
{
//Mychild1-specific logic
};
public MyCustomClass SaveOperation(MyBaseAbs obj)
{
//do the common saving operations here
var result = new MyCustomClass();
//....
var actualType = obj.GetType();
if(_saveOperations.ContainsKey(actualType))
{
_saveOperations[actualType](obj, result);
}
return result;
}
You can then add an item to the dictionary for each derived class. It is the same concept as using the is operator but allows you to add methods for more derived types without modifying the original SaveOperation method
You can use C#'s As-Operator as follows:
Mychild1 child1 = myObj as Mychild1;
if(child1 != null) {
//Here you can use child1.Mychild1Prop1 forexample
}
Link to msdn: https://msdn.microsoft.com/en-us/library/cscsdfbt.aspx

How to map some source properties to a wrapped destination type using AutoMapper?

Suppose you have this source model:
public abstract class SourceModelBase {
}
public class SourceContact : SourceModelBase {
public string FirstName { get; set; }
public string LastName { get; set; }
public KeyValuePair Pair { get; set; }
public SourceAddress Address { get; set; }
}
public class KeyValuePair { // Not derived from SourceModelBase.
public string Key { get; set; }
public string Value { get; set; }
}
public class SourceAddress : SourceModelBase {
public string StreetName { get; set; }
public string StreetNumber { get; set; }
}
Now the destination model should be mapped 1:1 by default (subject to normal AutoMapper configuration), but each thing derived from SourceModelBase should be mapped to a wrapper class class Wrap<T> { T Payload { get; set; } string Meta { get; set; } }.
public abstract class DestinationModelBase {
}
public class DestinationContact : DestinationModelBase {
public string FirstName { get; set; }
public string LastName { get; set; }
public KeyValuePair Pair { get; set; } // Not wrapped, base class not `SourceModelBase`.
public Wrap<DestinationAddress> Address { get; set; }
}
public class DestinationAddress : DestinationModelBase {
public string StreetName { get; set; }
public string StreetNumber { get; set; }
}
Since the contact class itself is derived from SourceModelBase it should be wrapped as well.
The result should have this structure:
Wrap<DestinationContact> Contact
string Meta // Comes from the custom wrapper logic.
DestinationContact Payload
string FirstName
string LastName
KeyValuePair Pair
string Key
string Value
Wrap<DestinationAddress> Address
string Meta // Comes from the custom wrapper logic.
DestinationAddress Payload
string StreetName
string StreetNumber
Obviously this wrapping should nest, illustrated by the fact that the mapped object itself is subject to it and so is its Address property.
For some reason all I keep finding are questions related to mapping from destination to source. I know I have to somehow use ResolveUsing and if the destination type is derived from SourceModelBase, somehow apply custom logic to provide the Wrap<T> value based on the value of the source property.
I don't know where to start at all, though. Especially when the source object itself is specified to be subject of the wrapping logic as well.
What's the best, most AutoMapper-idiomatic way to wrap the nested objects if they meet a condition and at the same time wrap the original object as well if it meets the same condition? I already have the mapper creation abstracted away so I can mold the original object automatically before passing it to the mapper, which may help with subjecting the original object to the resolver as well by doing mapper.Map(new { Root = originalObject }) so the resolver sees the instance of the original object as if it was a value of a property of source object as well, not the source object itself.
According to this issue on AutoMapper GitHub page, there is no direct way to do it.
But there is some workarounds. For example - reflection.
In this case you need to know wrapper type and implement converter for desired types. In this example it's MapAndWrapConverter from TSource to Wrap<TDestination>
CreateWrapMap method creates two bindings:
SourceAddress -> Wrap<DestinationAddress> and SourceContact -> Wrap<DestinationContact> which allow you to map SourceContant to wrapped DestinationContact.
internal class Program
{
public static void Main()
{
var config = new MapperConfiguration(cfg =>
{
cfg.CreateMap<SourceAddress, DestinationAddress>();
cfg.CreateMap<SourceContact, DestinationContact>();
cfg.CreateWrapMap(
//func selecting types to wrap
type => typeof(DestinationModelBase).IsAssignableFrom(type)
&& !type.IsAbstract,
typeof(Wrap<>),
typeof(MapAndWrapConverter<,>));
});
var mapper = config.CreateMapper();
//Using AutoFixture to create complex object
var fixture = new Fixture();
var srcObj = fixture.Create<SourceContact>();
var dstObj = mapper.Map<Wrap<DestinationContact>>(srcObj);
}
}
public static class AutoMapperEx
{
public static IMapperConfigurationExpression CreateWrapMap(
this IMapperConfigurationExpression cfg,
Func<Type, bool> needWrap, Type wrapperGenericType,
Type converterGenericType)
{
var mapperConfiguration =
new MapperConfiguration((MapperConfigurationExpression)cfg);
var types = Assembly.GetExecutingAssembly().GetTypes();
foreach (var dstType in types.Where(needWrap))
{
var srcType = mapperConfiguration.GetAllTypeMaps()
.Single(map => map.DestinationType == dstType).SourceType;
var wrapperDstType = wrapperGenericType.MakeGenericType(dstType);
var converterType = converterGenericType.MakeGenericType(srcType, dstType);
cfg.CreateMap(srcType, wrapperDstType)
.ConvertUsing(converterType);
}
return cfg;
}
}
public class MapAndWrapConverter<TSource, TDestination>
: ITypeConverter<TSource, Wrap<TDestination>>
{
public Wrap<TDestination> Convert(
TSource source, Wrap<TDestination> destination, ResolutionContext context)
{
return new Wrap<TDestination>
{
Payload = context.Mapper.Map<TDestination>(source)
};
}
}
CreateWrapMap method is a little bit messy, especially the part with finding matching types. But it can be refined according to your needs.

Overriding properties to make them readonly - what about the setter?

I have the following design goal in a class hierarchy:
There is a BaseClass defining some properties, which would usually be read/write:
public class Media
{
public virtual object Content { get; set; }
public virtual double recordingLength { get; set; }
}
The intention is to have some subclasses where this property now is readonly:
public class CompactDisk : Media
{
public override object Content
{
get { return this.getContent(); }
set {
// THERE SHOULDN'T BE A SETTER
}
}
public override double recordingLength
{
get { return 74; }
set {
// NO SETTER EITHER HERE!
}
}
}
I'm lost here, because I don't know how should I implement my design intent.
One possible approach is using interfaces.
You can split your base concept into two interfaces:
public interface IWritableMedia
{
object Content { set; }
double recordingLength { set; }
}
public interface IReadOnlyMedia
{
object Content { get; }
double recordingLength { get; }
}
And then something like CompactDisk should only implement IReadOnlyMedia:
public class CompactDisk : IReadOnlyMedia
{
public object Content { get { return ......; } }
public double recordingLength { get { return .......; } }
}
If you want to implement a CD-RW (rewritable), you should implement both interfaces:
public class RewritableCompactDisk : IReadOnlyMedia, IWritableMedia
{
public object Content { get; set; }
public double recordingLength { get; set; }
}
This way you can type your variables as IReadOnlyMedia or IWritableMedia:
IReadOnlyMedia media = new CompactDisk();
IWritableMedia media2 = new RewritableCompactDisk();
Now the issue is IWritableMedia doesn't provide getters and you don't want to declare another variable of type IReadOnlyMedia. The solution is designing a third interface called IReadWriteMedia and RewritableCompactDisk should implement it:
public interface IReadWriteMedia : IReadOnlyMedia, IWritableMedia
{
}
public class RewritableCompactDisk : IReadWriteMedia
{
public object Content { get; set; }
public double recordingLength { get; set; }
}
Since IReadWriteMedia implements IReadOnlyMedia and IWritableMedia, now you'll be able to type variables with IReadWriteMedia and access both getters and setters:
IReadWriteMedia media3 = new RewritableCompactDisk();
object content = media3.Content;
media3.Content = "hello world";
You can't, or really shouldn't, have a design where the sub types "hide" functionality of the base type. You can:
In your setters throw a NotSupportedException, or similar. This is how the Stream class behaves when you try to set the length of a stream that cannot be set.
Change your design. I don't see a way to get properties working the way you want (without resorting to "hiding", which IMHO isn't a good solution), but perhaps something like this:
public interface IMedia
{
object Content { get; }
double RecordingLength { get; }
}
public interface IWritableMedia : IMedia
{
void SetContent(object content);
void SetRecordingLength(double length);
}
Your CompactDisk would implement the just the IMedia interface, whereas a HardDrive class may choose to implement the IWritableMedia interface.

File Indexing software - Design

I am currently developing a file indexing system. I have an interface IDiskDrive that can get immediate file items (files/folders). The interface definition is as follows...
public interface IDiskDrive
{
bool IsReady { get; }
string Name { get; }
string VolumeLabel { get; }
string VolumeLabelName { get; }
DiskDriveType Type { get; }
FolderPath RootFolder { get; }
DiskDriveUsage Usage { get; }
IEnumerable<IFileItem> GetImmediateFileItems(FolderPath path);
}
The ability to read all file/folders is complete and works correctly. Now, I need to actually index the file files and folders. Looking ahead I know I will need some reporting tools. This leads me to think I need another abstraction, based upon IDiskDrive that can read/populate. I also need the ability to select drives for indexing.
My question is should my new class inherit IDiskDrive or should I use composition (possibly a decorator)?
// inheritance
class IndexedDiskDrive : IDiskDrive
{
public IndexedDiskDrive(IDiskDrive drive)
{
...
}
public int Id {get; internal set; } // database id
public bool Selected { get; internal set; }
public DateTime? DateLastIndexed { get; internal set; }
// IDiskDrive implementation
public bool IsReady
{
get { return this.Drive.IsReady; }
}
}
or composition...
class IndexedDiskDrive
{
public IndexDiskDrive(IDiskDrive drive)
{
this.Value = drive;
}
public IDiskDrive Value
{
get;
private set;
}
// additional properties
public int Id { get; internal set; }
public bool Selected { get; internal set;}
public DateTime DateLastIndexed { get; internal set; }
}
Note:
I need access to the underlying IDiskDrive for the UI.
For example, I request user to select drives to index. I initially supply a list of local drives and the ability to add network drives. To try and keep code simple, I thought the idea of a new class with a selected property might help.
This allows the GUI to enumerate a list of IndexedDiskDrives and set/clear the select property.
In both examples you expose the IDiskDrive object from the other object. In the first case you inherit from the same inteface, which means you expose the same methods and in the other case you expose the object via a property.
I don't see a reason yet why you want to do this.
It sounds like a typical constructor DI case to me. Just have a new interface for your new class which is doing a different job and hence requires a different contract, and if it needs the IDiskDrive object as a dependency, then just inject it via the constructor and leave it as it is.
P.S.: I know this is not something you have asked, but you might be interested in Lucense.NET, which is a .NET library to index files. They might have already solved your problem for your:
http://lucenenet.apache.org/
EDIT:
From your current class design I would do the following:
void Main()
{
// Use IoC container in real app:
var diskDrive = new DiskDrive(...);
var fileIndexer = new FileIndexer();
var fileItems = diskDrive.GetImmediateFileItems(filePath);
fileIndexer.IndexFiles(fileItems);
}
// Define other methods and classes here
public interface IDiskDrive
{
bool IsReady { get; }
string Name { get; }
string VolumeLabel { get; }
string VolumeLabelName { get; }
DiskDriveType Type { get; }
FolderPath RootFolder { get; }
DiskDriveUsage Usage { get; }
IEnumerable<IFileItem> GetImmediateFileItems(FolderPath path);
}
public interface IFileIndexer
{
void IndexFiles(IEnumerable<IFileItem> files);
}
public class FileIndexer : IFileIndexer
{
public void IndexFiles(IEnumerable<IFileItem> files)
{
// do stuff
}
}

Strategy for resolving correct interface implementation in multi-tenant environment

Given this interface:
public interface ILoanCalculator
{
decimal Amount { get; set; }
decimal TermYears { get; set; }
int TermMonths { get; set; }
decimal IntrestRatePerYear { get; set; }
DateTime StartDate { get; set; }
decimal MonthlyPayments { get; set; }
void Calculate();
}
and 2 implentations of it:
namespace MyCompany.Services.Business.Foo
{
public interface ILoanCalculator : Common.ILoanCalculator
{
}
public class LoanCalculator : ILoanCalculator
{
public decimal Amount { get; set; }
public decimal TermYears { get; set; }
public int TermMonths { get; set; }
public decimal IntrestRatePerYear { get; set; }
public DateTime StartDate { get; set; }
public decimal MonthlyPayments { get; set; }
public void Calculate()
{
throw new NotImplementedException();
}
}
}
namespace MyCompany.Services.Business.Bar
{
public interface ILoanCalculator : Common.ILoanCalculator
{
}
public class LoanCalculator : ILoanCalculator
{
public decimal Amount { get; set; }
public decimal TermYears { get; set; }
public int TermMonths { get; set; }
public decimal IntrestRatePerYear { get; set; }
public DateTime StartDate { get; set; }
public decimal MonthlyPayments { get; set; }
public void Calculate()
{
throw new NotImplementedException();
}
}
}
Given the simple code from above, lets say that the implementation of Calculate method will be different per company. What is the proper way to load the assemblies during initialization and call the correct method of the correct assembly? I have figured out the easy part with is determining which company the request is for, now I just need to call the correct method that corresponds to the current Business.
Thank you,
Stephen
Updated Example Code
Big shout out to #Scott, here are the changes I had to make in order for the accepted answer to work correctly.
In this case I had to use the Assembly Resolver to find my type. Note that I used an attribute to mark my assembly so that filtering based on it was simpler and less error prone.
public T GetInstance<T>(string typeName, object value) where T : class
{
// Get the customer name from the request items
var customer = Request.GetItem("customer") as string;
if (customer == null) throw new Exception("Customer has not been set");
// Create the typeof the object from the customer name and the type format
var assemblyQualifiedName = string.Format(typeName, customer);
var type = Type.GetType(
assemblyQualifiedName,
(name) =>
{
return AppDomain.CurrentDomain.GetAssemblies()
.Where(a => a.GetCustomAttributes(typeof(TypeMarkerAttribute), false).Any()).FirstOrDefault();
},
null,
true);
if (type == null) throw new Exception("Customer type not loaded");
// Create an instance of the type
var instance = Activator.CreateInstance(type) as T;
// Check the instance is valid
if (instance == default(T)) throw new Exception("Unable to create instance");
// Populate it with the values from the request
instance.PopulateWith(value);
// Return the instance
return instance;
}
Marker Attribute
[AttributeUsage(AttributeTargets.Assembly)]
public class TypeMarkerAttribute : Attribute { }
Usage in plugin assembly
[assembly: TypeMarker]
And finally, a slight change to the static MyTypes to support qualified name
public static class MyTypes
{
// assemblyQualifiedName
public static string LoanCalculator = "SomeName.BusinessLogic.{0}.LoanCalculator, SomeName.BusinessLogic.{0}, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null";
}
I don't think there is an easy or particularly elegant solution, because ServiceStack resolves it's services based on concrete classes rather than by interfaces, and this is something beyond the capability of Funq. However it's not impossible.
You will need to have a default implementation of each interface that you want to use as a DTO, because ServiceStack resolves using the concrete class.
So essentially here we have a DefaultCalculator which will provide us the route into our action method.
[Route("/Calculate","GET")]
public class DefaultCalculator : ILoanCalculator
{
public decimal Amount { get; set; }
public decimal TermYears { get; set; }
public int TermMonths { get; set; }
public decimal IntrestRatePerYear { get; set; }
public DateTime StartDate { get; set; }
public decimal MonthlyPayments { get; set; }
public void Calculate()
{
throw new NotImplementedException();
}
}
Then our action method is used almost as normal, except we call a method GetInstance<T> which we implement in our MyServiceBase from which this service extends, rather than Service, because it makes it easier to share this method across services.
public class TestService : MyServiceBase
{
public decimal Get(DefaultCalculator request)
{
// Get the instance of the calculator for the current customer
var calculator = GetInstance<ILoanCalculator>(MyTypes.LoanCalculator, request);
// Perform the action
calculator.Calculate();
// Return the result
return calculator.MonthlyPayments;
}
}
In MyServiceBase we implement the method GetInstance<T> which is responsible for resolving the correct instance, based on the customer name, of T, in this case is the ILoanCalculator.
The method works by:
Determine the customer name from the Request.GetItem("customer"). Your current method will need to set the customer identifier on the Request Items collections using Request.SetItem method at the point where you identify your customer. Or perhaps move the identification mechanism into this method.
With the customer name known the full type name can be built, based on the passed in type name template. i.e. MyCompany.Services.Business.Foo.LoanCalculator where Foo is the customer. This should resolve the type if the containing assembly has been loaded at startup.
Then an instance of the type is created as T i.e. the interface, ILoanCalculator
Then a safety check to make sure everything worked okay.
Then populate the values from the request that are in DefaultCalculator which is also of type ILoanCalculator.
Return the instance.
public class MyServiceBase : Service
{
public T GetInstance<T>(string typeName, object value)
{
// Get the customer name from the request items
var customer = Request.GetItem("customer") as string;
if(customer == null) throw new Exception("Customer has not been set");
// Create the typeof the object from the customer name and the type format
var type = Type.GetType(string.Format(typeName, customer));
// Create an instance of the type
var instance = Activator.CreateInstance(type) as T;
// Check the instance is valid
if(instance == default(T)) throw new Exception("Unable to create instance");
// Populate it with the values from the request
instance.PopulateWith(value);
// Return the instance
return instance;
}
}
You can optionally add a cache of instances to prevent having to use Activator.CreateInstance for each request.
If you are going to have many different types being created dynamically then you may wish to organise their type strings into a static class:
public static class MyTypes
{
public static string LoanCalculator = "MyCompany.Services.Business.{0}.LoanCalculator";
public static string AnotherType = "MyCompany.Services.Business.{0}.AnotherType";
//...//
}
Then all that's left to do is ensure that you add the assemblies with your different customer implementations are loaded into your application, which you could do from your AppHost Configure method.
foreach(var pluginFileName in Directory.GetFiles("Plugins", "*.dll"))
Assembly.Load(File.ReadAllBytes(pluginFileName));
Obviously this method relies on the full type name being of a specific format to match it to customers. There are other approaches but I believe this to be straightforward.
I hope that helps.

Categories

Resources