When multiple classes implement one (or more) interface, despite being different classes, they might have a lot of logic in common and only differ slightly.
In that case, it may be handy to move the shared logic into a shared class, which is then used as a component. Calls of methods with a shared logic are delegated to that component.
For exemple :
interface IFoo
{
void DoFoo();
}
interface IBar
{
void DoBar();
}
interface IBaz
{
void DoBaz();
}
class DefaultFoo()
{
public void Do() { /* Shared logic */ }
}
class DefaultBar()
{
public void Do() { /* Shared logic */ }
}
class FooBarBaz1 : IFoo, IBar, IBaz
{
DefaultFoo defaultFoo = new DefaultFoo();
DefaultBar defaultBar = new DefaultBar();
public void DoFoo() { defaultFoo.Do(); }
public void DoBar() { defaultBar.Do(); }
public void DoBaz() { /* FooBarBaz1 specific IBaz implementation */ }
}
class FooBarBaz2 : IFoo, IBar, IBaz
{
DefaultFoo defaultFoo = new DefaultFoo();
public void Foo() { defaultFoo.Do(); }
public void Bar() { /* FooBarBaz2 specific IBar implementation */ }
public void Baz() { /* FooBarBaz2 specific IBaz implementation */ }
}
// More ForBarBazX classes...
In classes FooBarBaz1 and FooBarBaz2, we completely wrap the DefaultFoo instance to give the impression from the public side that FooBarBaz1 and FooBarBaz2 are doing the work while they are just delegating it.
The problem with that is, if you have a large number of classes that must implement the interface and / or the interface has many methods, you end up being force to write a lot of "useless" delegation code.
So my question is : can't we just NOT wrap the shared logic ? Instead of requiring the methods to be implemented, the interfaces require to have these components exposed.
We would have instead :
interface IFoo
{
DefaultFoo Foo { get; }
}
interface IBar
{
DefaultBar Bar { get; }
}
interface IBaz
{
DefaultBaz Baz { get; }
}
class DefaultFoo()
{
public virtual void Do() { /* Shared logic */ } // Note the virtual.
}
class DefaultBar()
{
public virtual void Do() { /* Shared logic */ } // Note the virtual.
}
class FooBarBaz1 : IFoo, IBar, IBaz
{
private class SpecificBaz : DefaultBaz
{
public override void DoBaz() { /* Specific logic */ }
}
public DefaultFoo Foo { get; private set; }
public DefaultBar Bar { get; private set; }
public DefaultBaz Baz { get; private set; }
public FooBarBaz1()
{
Foo = new DefaultFoo();
Bar = new DefaultBar();
Baz = new SpecificBaz();
}
}
class FooBarBaz2 : IFoo, IBar, IBaz
{
private class SpecificBar : DefaultBar
{
public override void Bar() { /* Specific logic */ }
}
private class SpecificBaz : DefaultBaz
{
public override void Baz() { /* Specific logic */ }
}
public DefaultFoo Foo { get; private set; }
public DefaultBar Bar { get; private set; }
public DefaultBaz Baz { get; private set; }
public FooBarBaz1()
{
Foo = new DefaultFoo();
Bar = new SpecificBaz();
Baz = new SpecificBaz();
}
}
Than, instead of doing :
ForBarBaz1 fooBarBaz = new ForBarBaz1();
fooBarBaz.Foo();
fooBarBaz.Bar();
fooBarBaz.Baz();
One would access the exposed components :
ForBarBaz1 fooBarBaz = new ForBarBaz1();
fooBarBaz.Foo.Do();
fooBarBaz.Bar.Do();
fooBarBaz.Baz.Do();
What do you think about this ? It seems to be like it preserves modularity while avoiding the large amounts of "useless" wrapping code.
PS : I'm asking this for C# but I guess it would also apply to some other languages.
Related
Say i have this example code:
interface IBase {
int BaseProperty { get; }
}
interface IDerived : IBase {
int DerivedProperty { get; }
}
and i like to write mocks for both interfaces.
Base mock is easy:
class BaseMock : Mock<IBase> {
public int BaseProperty { get; set; } = 42;
public BaseMock() {
SetupGet(o => o.BaseProperty).Returns(BaseProperty);
}
}
but im not sure how to correctly write derived mock:
class DerivedMock : Mock<IDerived> {
public int BaseProperty { get; set; } = 42;
public int DerivedProperty { get; set; } = 73;
public DerivedMock() {
// setups related to IBase
SetupGet(o => o.BaseProperty).Returns(BaseProperty);
// setups related to IDerived
SetupGet(o => o.DerivedProperty).Returns(DerivedProperty);
}
}
this implementation will work as expected, but im forced to copy bassically whole content of BaseMock class here and that is not DRY ...
ideally i would like to inherit DerivedMock from BaseMock, but then setups related to IDerived would not compile (o is IBase and i it to be IDerived)...
I appreciate any kick in the right direction :)
Rafał Rutkowski kicked me to right direction and i ended up with this code for anyone else interested:
interface IBase {
int BaseProperty { get; }
}
interface IDerived : IBase {
int DerivedProperty { get; }
}
class BaseMock : Mock<IBase>, IBase {
public int BaseProperty { get; set; } = 42;
public BaseMock() {
SetupAll(this, this);
}
public static void SetupAll<TBase>([NotNull] Mock<TBase> mock, [NotNull] TBase instance)
where TBase : class, IBase {
mock.SetupGet(o => o.BaseProperty).Returns(instance.BaseProperty);
}
}
class DerivedMock : Mock<IDerived>, IDerived {
public int BaseProperty { get; set; } = 42;
public int DerivedProperty { get; set; } = 73;
public DerivedMock() {
SetupAll(this, this);
}
public static void SetupAll<TDerived>([NotNull] Mock<TDerived> mock, [NotNull] TDerived instance)
where TDerived : class, IDerived {
BaseMock.SetupAll(mock, instance);
mock.SetupGet(o => o.DerivedProperty).Returns(instance.DerivedProperty);
}
}
public class UnitTest1
{
public void Test() {
BaseMock baseMock = new BaseMock();
IBase baseObject = baseMock.Object;
baseMock.BaseProperty = 37;
Assert.AreEqual(37, baseObject.BaseProperty);
baseMock.VerifyGet(o => o.BaseProperty, Times.Never);
// ----------------
DerivedMock derivedMock = new DerivedMock();
IDerived derivedObject = derivedMock.Object;
derivedMock.BaseProperty = 42;
derivedMock.DerivedProperty = 73;
Assert.AreEqual(42, derivedObject.BaseProperty);
Assert.AreEqual(73, derivedObject.DerivedProperty);
}
}
reason why i wrote it this way is that i can dynamicall change property value AND verify that it was readed / written.
You don't inherit from the Mock class. Instead you use Mock's Object property to get the mocked object. To reuse setting up IBase mock, you can do something like this:
private static void SetupBase<T>(Mock<T> mock)
where T : class, IBase
{
// setup base methods and properties
mock.SetupGet(x => x.BaseProperty).Returns(1);
}
private static void SetupDerived(Mock<IDerived> mock)
{
SetupBase(mock);
// setup derived methods and properties
}
[Test]
public void Test()
{
var derivedMock = new Mock<IDerived>();
SetupDerived(derivedMock);
var derived = derivedMock.Object;
Assert.AreEqual(1, derived.BaseProperty);
derivedMock.SetupGet(x => x.BaseProperty).Returns(2);
Assert.AreEqual(2, derived.BaseProperty);
}
I am trying to populate an array of objects that inherit from IFoo. The problem I am facing is that structure map is populating the property within IFoo with the same instance of IBar. I cannot add AlwaysUnique() to IBar because this is used elsewhere in our enterprise application and would have consequences.
Is there anyway that I can get it to create new instances of the Bar object for every Foo in the collection?
public interface IFoo
{
IBar bar { get; set; }
}
public class Foo1 : IFoo
{
public IBar bar { get; set; }
public Foo1(IBar bar) { this.bar = bar; }
}
public class Foo2 : IFoo
{
public IBar bar { get; set; }
public Foo2(IBar bar) { this.bar = bar; }
}
public interface IBar
{
Guid id { get; set; }
}
public class Bar : IBar
{
public Guid id { get; set; }
public Bar() {this.id = Guid.NewGuid();}
}
class Program
{
static void Main(string[] args)
{
var container = new Container(_ =>
{
_.Scan(x =>
{
x.TheCallingAssembly();
x.AddAllTypesOf<IFoo>();
});
_.For<IBar>().Use<Bar>(); //I can't change this line because Bar is used elsewhere in the project
});
var foos = container.GetAllInstances<IFoo>();
if (foos.ElementAt(0).bar == foos.ElementAt(1).bar)
throw new Exception("Bar must be a different instance");
}
}
You could do this with a custom policy. See example 3 here, you could adapt that to your needs.
Something like:
public class BarUniqueForFoo : IInstancePolicy
{
public void Apply(Type pluginType, Instance instance)
{
if (pluginType == typeof(IBar) && instance.ReturnedType == typeof(Bar)
{
instance.SetLifecycleTo<UniquePerRequestLifecycle>();
}
}
}
I'm trying to create instance of class Bar but I'm receiving an error:
"Cannot implicitly convert type ConsoleApplication1.Bar to
ConsoleApplication1.BaseFoo<ConsoleApplication1.baseOutput,
ConsoleApplication1.baseInput>"
Any idea what I'm missing or what I'm doing wrong? Any advice will be nice.
public class baseOutput
{
public string output;
}
public class baseInput
{
public string input;
}
public class ExtendOutput : baseOutput
{
public long id;
}
public class ExtendInput : baseInput
{
public long id;
}
public class BaseFoo<baseOutput, baseInput>
{
protected virtual void DoSmth()
{
}
}
public class Bar : BaseFoo<ExtendOutput, ExtendInput>
{
protected override void DoSmth()
{
base.DoSmth();
}
}
public class Test
{
public void Show()
{
}
private BaseFoo<baseOutput, baseInput> CreateInstance()
{
return new Bar(); // Error right here
}
}
I'll give you an example of why you're prevented from doing that.
Imagine instead, your classes were written like this:
public class BaseFoo<TOutput, TInput>
where TOutput : BaseOutput
{
public TOutput Something { get; set; }
}
public class Bar : BaseFoo<ExtendOutput, ExtendInput>
{
}
public class BaseInput { }
public class BaseOutput { }
public class ExtendOutput : BaseOutput { }
public class SomethingElse : BaseOutput { }
Now, you have this method:
private BaseFoo<BaseOutput, BaseInput> CreateInstance()
{
//At this point, Something will be of type ExtendOutput.
return new Bar();
}
So, we call it like this:
var myBar = CreateInstance();
Now, mybar.Something is of type BaseOutput. That's fine, though, because ExtendOutput : BaseOutput, right? Not quite.
What happens when we do this:
myBar.Something = new SomethingElse();
That's valid, because Something expects a BaseOutput, and SomethingElse is a BaseOutput. However, the object is actually a Bar, which explicitly says it should be an ExtendOutput.
The problem is clearer if we attempt to cast it back:
var myBaseFoo = CreateInstance();
myBaseFoo.Something = new SomethingElse();
Bar myBar = (Bar)myBaseFoo;
myBar.Something; // Here, we're told it's going to be an `ExtendOutput`,
// but we get a `SomethingElse`?
That's clearly wrong. And that's why you're prevented from doing what you're trying to do. You can have this behavior with covariance.
Covariance makes it illegal to pass in a TOutput. So, this line
public TOutput Something { get; set; }
Would be invalid. We would only be allowed to expose the getter:
public TOutput Something { get; }
Which alleviates the above problem
Bar is BaseFoo<ExtendOutput, ExtendInput>, and CreateInstance() requires BaseFoo<baseOutput, baseInput> to be returned, so it can't return Bar which is BaseFoo<ExtendOutput, ExtendInput>.
Regardless ExtendOutput inherits baseOutput, when you inherit a generic class the inheritance is invariant.
Consider using interfaces with in and out generic modifiers:
public class baseOutput
{
public string output;
}
public class baseInput
{
public string input;
}
public class ExtendOutput : baseOutput
{
public long id;
}
public class ExtendInput : baseInput
{
public long id;
}
public interface IBaseFoo<out T1, out T2>
{
public void DoSmth();
}
public class Bar : IBaseFoo<ExtendOutput, ExtendInput>
{
public void DoSmth()
{
}
}
public class Test
{
public void Show()
{
}
private IBaseFoo<baseOutput, baseInput> CreateInstance()
{
return new Bar();
}
}
interface IRecipe<T>
{
ICollection<IIngredient<T>> Ingredients { get; set; }
T Cook();
}
interface IIngredient<T> {}
public class Cheese : IIngredient<Pizza> {}
public class Tomato : IIngredient<Pizza> {}
public class Egg : IIngredient<Omlette> {}
I want that when I request an instance of IRecipe<SomeType> StructureMap finds all implementations of IIngredient<SomeType> and registers them with Recipe somehow.
So e.g. if I request interface IRecipe<Pizza> I will get concrete instance of Recipe<Pizza> that has the correct ingredients.
Is there any way to achieve this?
Yes this can be done with StructureMap.
I've made ICollection<IIngredient<T>> Ingredients readonly, added concrete implementations of Pizza and Omlette and extended Cheese and Tomato to be available for both Recipe's
public class Pizza { }
public class Omlette { }
public class Recipe<T> : IRecipe<T> where T : class, new()
{
private readonly IEnumerable<IIngredient<T>> _ingredients;
public Recipe(IEnumerable<IIngredient<T>> ingredients)
{
_ingredients = ingredients;
}
public ICollection<IIngredient<T>> Ingredients
{
get { return _ingredients.ToList(); }
}
public T Cook()
{
return new T();
}
}
public interface IRecipe<T>
{
ICollection<IIngredient<T>> Ingredients { get; }
T Cook();
}
public interface IIngredient<T> { }
public class Cheese : IIngredient<Pizza>, IIngredient<Omlette> { }
public class Tomato : IIngredient<Pizza>, IIngredient<Omlette> { }
public class Egg : IIngredient<Omlette> { }
Here's the method for registration
public StructureMap.IContainer ConfigureStructureMap()
{
StructureMap.IContainer structureMap;
StructureMap.Configuration.DSL.Registry registry =
new StructureMap.Configuration.DSL.Registry();
registry.Scan(scanner =>
{
scanner.TheCallingAssembly();
scanner.ConnectImplementationsToTypesClosing(typeof(IIngredient<>));
});
structureMap = new StructureMap.Container(registry);
structureMap.Configure(cfg =>
cfg.For(typeof(IRecipe<>)).Use(typeof(Recipe<>)));
return structureMap;
}
And two test methods
[Test]
public void StructureMapGetInstance_Pizza_ReturnsTwoIngredients()
{
StructureMap.IContainer structureMap = ConfigureStructureMap();
var pizza = structureMap.GetInstance<IRecipe<Pizza>>();
Assert.That(pizza.Ingredients.Count, Is.EqualTo(2));
}
[Test]
public void StructureMapGetInstance_Omlette_ReturnsThreeIngredients()
{
StructureMap.IContainer structureMap = ConfigureStructureMap();
var omlette = structureMap.GetInstance<IRecipe<Omlette>>();
Assert.That(omlette.Ingredients.Count, Is.EqualTo(3));
}
I want to create a class that could hold any of a number of same type of classes. For example lets says I have a base class like follows:
public class BaseClass
{
public string MyBaseString
{
get;
set;
}
}
And then I have a few derived classes like this:
public class DerivedClass : BaseClass
{
public MyDerivedClassString
{
get;
set;
}
}
public class DerivedClass2 : BaseClass
{
public MyDerivedClass2String
{
get;
set;
}
}
Now I would like a class that accepts one of these implementations and does stuff with it. Here is the only thing I can think of, but there must be a better way:
public class ClassA
{
public object MyClass
{
get;
set;
}
public ClassA (object myClass)
{
MyClass = myClass;
if (object is BaseClass)
{
//do something
}
else if (object is DerivedClass)
{
//do something specific to derived class
}
else if (object is DerivedClass2)
{
//do something specific to derived class 2
}
}
}
CLARIFICATION: The specific goal I am trying to accomplish is to use ClassA as a container class for various implementations of the BaseClass. The business goal I am trying to accomplish is to create a Legend object which might use multiple color schemes (i.e. a Mono Color Ramp, Multi Color Ramp, etc). So I would like the Legend class to contain the ColorScheme that is being used, but still have access to that color scheme's unique properties for modification later on.
CLARIFICATION 2 Based on the wide array of responses I got, I thought I'd provide an exact replication of what I'm trying to do:
public class BaseColorScheme
{
List<Color> _colors = new List<Color>();
public List<Color> Colors
{
get
{
return _colors;
}
set
{
_colors = value;
}
}
}
public class SingleColorScheme : BaseColorScheme
{
public Color MidColor
{
get;
set;
}
public SingleColorScheme( Color midColor, int numberOfClassifications )
{
Colors = CreateMonoColorRamp( midColor, numberOfClassifications );
}
}
public class MultiColorScheme : BaseColorScheme
{
public Color StartColor
{
get;
set;
}
public Color EndColor
{
get;
set;
}
public Color MidColor
{
get;
set;
}
public MultiColorScheme( Color startColor, Color endColor, Color midColor )
{
StartColor = startColor;
EndColor = endColor;
MidColor = midColor;
Colors = //do something to define multi color scheme
}
}
Then I would have a Legend Class that would be something like
public class Legend
{
public object ColorScheme
{ get; set; }
public Guid LegendId
{ get; set; }
public Legend(object colorScheme)
{
ColorScheme = colorScheme;
}
}
Finally I might have a form that sits on top of the legend that displays the properties of the various color schemes based on which type of color scheme it is. Hopefully that helps clarify a bit.
public class ClassA<T> where T : BaseClass
{
public T MyClass { get; set; }
public ClassA(T myClass) { MyClass = myClass; }
}
Beyond that, define the common interface of the class hierarchy either as an interface or as methods (concrete, abstract, or virtual) within the base class. Then you can be assured all derived classes have such method / properties and can use them within your generic wrapper.
Instead of letting ClassA perform whatever needs to be done, you can use polymorphism and let the classes do it to themselves.
Simply declare a virtual method in the base class, have it do whatever you need it do so, and then override this method in the subclasses. In the method in ClassA, you just need to call that method on the object you receive as a parameter - without having to care about the specific type.
If you need to access different properties based on which derived class is passed something like this should help:
public class ClassA<T> where T : BaseClass
{
public T MyClass { get; set; }
public ClassA(T myClass) { MyClass = myClass; }
public void DoStuffToMyClass()
{
if(MyClass is BaseClass)
{ // do base class stuff }
else if(Myclass is DerivedClass)
{ // do DerivedClass stuff }
else if(MyClass is DerivedClass2)
{ // do DerivedClass2 stuff }
}
}
This gives you the type saftey to ensure you at least have the BaseClass object, and possibly a derived class.
The answer is polymorphism, let the object do it themselves.
public class BaseClass
{
public string MyString { get; set; }
public virtual string DoIt()
{
return "I'm Base Class";
}
}
public class DerivedClassA
{
public override string DoIt()
{
return "I'm Derived Class A";
}
}
public class DerivedClassB
{
public override string DoIt()
{
return "I'm Derived Class B";
}
}
....
public ClassA (BaseClass myClass)
{
MyClass = myClass;
MyClass.DoIt();
}
.....
ClassA x1 = ClassA(new BaseClass()) // calls BaseClass.DoIt()
ClassA x2 = ClassA(new DerivedClassA()) // calls DerivedClassA.DoIt()
ClassA x3 = ClassA(new DerivedClassB()) // calls DerivedClassB.DoIt()
whenever you catch yourself acting differently based on the run-time type of the object, you are dealing with code that breaks OO principles, i.e. a class that does not respect the base class contract.
Can you use virtual methods?
public abstract class BaseClass
{
public abstract void DoStuff();
}
public class DerivedClass1 : BaseClass
{
public override void DoStuff()
{
...
}
}
public class DerivedClass2 : BaseClass
{
public override void DoStuff()
{
...
}
}
Without generics:
public class ClassA
{
public BaseClass MyClass
{
get;
set;
}
public ClassA (BaseClass myClass)
{
MyClass = myClass;
myClass.DoStuff();
}
}
or with generics:
public class ClassA<T> where T : BaseClass
{
public T MyClass { get; set; }
public ClassA (T myClass)
{
MyClass = myClass;
myClass.DoStuff();
}
}
Keep it simple: polymorphism
Hopefully your objects have a common interface, something like:
class Base {
public virtual void DoSomething() { /* Default implementation */ }
}
class Derived1 : Base {
public override void DoSomething() { /* Implementation specific to this type */ }
}
class Derived2 : Base {
public override void DoSomething() { /* Another implementation specific to this type */ }
}
Or maybe they implement a common interface. So hopefully your consuming class can hold the most general representation of your inputs as possible and invoke code as such:
class Dependent {
public Dependent(Base instance) {
instance.DoSomething();
}
}
So your Dependent class doesn't really are whether it has a derived type or a base type.
Not quite as simple: visitor pattern
Sometimes polymorphism doesn't really work, which is particularly the case if you need to access the specific members of your derived classes, and those members aren't in the base class. Visitor pattern works well in this case, especially if you have a fixed, well-defined graph of objects.
public interface IVisitor<T> {
T Visit(Base x);
T Visit(Derived1 x);
T Visit(Derived2 x);
}
class Base {
public virtual T Accept<T>(IVisitor<T> visitor) { visitor.Visit(this); }
public string BaseString { get; set; }
}
class Derived1 : Base {
public override T Accept<T>(IVisitor<T> visitor) { visitor.Visit(this); }
public string Derived1String { get; set; }
}
class Derived2 : Base {
public override T Accept<T>(IVisitor<T> visitor) { visitor.Visit(this); }
public string Derived2String { get; set; }
}
So Derived1 and Derived2 have a different set of properties, and if you need to get to those properties without a runtime type-checking, implement a visitor:
class DefaultStringVisitor : IBaseVisitor<string> {
public string Visit(Base x) { return x.BaseString; }
public string Visit(Derived1 x) { return x.Derived1String; }
public string Visit(Derived2 x) { return x.Derived2String; }
}
class Dependent {
public Dependent(Base x) {
string whatever = x.Accept<string>(new DefaultStringVisitor());
}
}
So the visitor pattern gives you access to your derived object's members without a type-check. Its a somewhat inflexible pattern (i.e. need to know which objects to visit up front), but it might work for your needs.