Consider the code:
public abstract class Base
{
public Dictionary<int, string> Entities { get; private set; }
protected Base()
{
Entities = new Dictionary<int, string>();
}
}
public abstract class A : Base
{
public abstract void Update();
}
public abstract class B : Base
{
public abstract void Draw();
}
Is it possible to restrict classes (in the same assembly) from inheriting from Base, forcing them to inherit from either A or B?
To elaborate a little on my comment. This isn't supported, so the answer is no. The only contrived way of trying this that comes to mind (that obviously wouldn't work) would be to have a sealed abstract class, which is nonsensical, as neither A nor B, nor anything else, could then inherit either.
There is no discriminator that allows us to say, "sealed for", for instance.
The only way to prevent an inheritance is declare class like sealed.
public sealed abstract class A
{
}
but you will get compile error:
Abstract class can not be declared sealed.
The reason for this is that simply no any meaning in decalring abstract class and limiting its inheritance tree. Abstact class is an entity that targets to be expanded by someone by its definition.
The closest thing you can do, as far as I know, is the following:
public abstract class Base
{
internal Base()
{
// do stuff
}
}
Then move A, B, and Base into their own assembly. Anything outside the assembly can see Base, but cannot extend it directly because it can't access the constructor.
Or you could do a runtime check:
public abstract class Base
{
protected Base()
{
if (!(this is A || this is B))
// throw an exception
}
}
The only way round this that I can think of would be to have something like:
A.dll
internal abstract class Base
{
public Dictionary<int, string> Entities { get; private set; }
protected Base()
{
Entities = new Dictionary<int, string>();
}
}
B.dll
public abstract class A : Base
{
public abstract void Update();
}
public abstract class B : Base
{
public abstract void Draw();
}
C.dll
public class C : A
{
public void Draw()
{
}
}
and then to use [assembly: InternalsVisibleTo...] in the AssemblyInfo.cs of A.dll to make internal classes visible to B.ll.
Disclaimer: It's quite convoluted and I wouldn't recommend it, but I couldn't think of any way to satisfy your constraints.
Related
I was practicing c# abstract class and inheritance, but I was wondering if derived classes could access the constructor by calling the base
public abstract class A
{
protected bool value_A;
protected int value_B;
public A(int input)
{
A = true;
B = false;
}
public abstract int function_B();
}
}
public class childA : A
{
public childA (int input):base(input)
{
}
public override int function_B()
{
//do smth
}
}
public class childB : A
{
public childB(int input):base(input)
{
}
public override int function_B()
{
//do something different
}
public void functionC(int input)
{
}
}
I was confused if I should use this abstract class design or just go ez by using inheritance -> declare a virtual function in class A.
Yes, you can. Derived class c'tor can call base class one, even if the base class is abstract.
Generally, using abstract base class makes sense if there is a common functionality (or traits) that you want to reuse, and instantiating the base class does not make sense (and therefore you make it an abstract class).
A basic example is "Shapes" hierarchy, with abstract base class Shape that has color and center (for instance) and virtual method Draw, and all specific shapes inheriting from Shape and implementing the actual Draw functionality for each specific shape.
I want to build a class that would have a property, in which there is an instance of a class, which implements an abstract class. Here's and example.
public class MyClass {
public MyDerivedClassA derived;
public void mainClassUtility () {
derived.foo();
}
}
public abstract class MyAbstractBaseClass {
public abstract void foo();
}
public class MyDerivedClassA : MyAbstractBaseClass {
public override void foo(){
return;
}
}
public class MyDerivedClassB : MyAbstractBaseClass
{
public override void foo()
{
return;
}
}
Basically, I want to make sure the object I'm using is derived from an abstract class and implements all the methods I will need to use. There will be many implementations of the abstract class and depending on the current state of the program, MyClass might be using different implementations of the ABC. I want to write the program in a way, that no matter what implementation of the ABC is currently being used, there is a way to call it's methods by MyClass. What would be the best solution to this problem?
Unless I'm misunderstanding the question, you're pretty much there. Have MyClass expect a property of the abstract base class and you should be all set.
using System;
public class Program
{
public static void Main()
{
var myClassOne = new MyClass(new MyDerivedClassA());
var myClassTwo = new MyClass(new MyDerivedClassB());
myClassOne.mainClassUtility();
myClassTwo.mainClassUtility();
}
public class MyClass
{
public MyAbstractBaseClass Derived;
public MyClass(MyAbstractBaseClass derived)
{
Derived = derived;
}
public void mainClassUtility ()
{
Derived.foo();
}
}
public abstract class MyAbstractBaseClass
{
public abstract void foo();
}
public class MyDerivedClassA : MyAbstractBaseClass
{
public override void foo()
{
Console.WriteLine("I am MyDerivedClassA");
return;
}
}
public class MyDerivedClassB : MyAbstractBaseClass
{
public override void foo()
{
Console.WriteLine("I am MyDerivedClassB");
return;
}
}
}
How to require an implementation of an abstract class in C#?
You can not instantiate a abstract class - and thus can not use it for most cases. Except as variable/argument/generic type argument. You need to make a concrete (non-abstract) class that inherits from it. You can only use the abstract class as a variable/argument type. To guarantee that only stuff that inherits from it can be used there.
Basically, I want to make sure the object I'm using is derived from an abstract class and implements all the methods I will need to use.
Then use the abstract class as type argument. It means only instaces of the abstract class (of wich there can be no instance) or instances of classes that inherit from it (that somebody else writes) can be used at that place.
Note that Abstract classes and Interfaces overlap in nearly all uses. There is a miriad small differences, but I do not think they mater. The only big difference I can see, is one of exclusivity:
a class can implement as many Interfaces as it wants.
You can only inherit from one abstract class. that means it is for a primary, exclusive purpose. That way you prevent some dumb ideas, like someone trying to make a Windows Form that is also a DBConnection.
I have a bunch of derived classes that inherit from a base class. Each derived class still has unique members. One of these derived classes needs to be able to access all the other derived class's members. My aim with this problem is to write as little code as possible.
Would it be sloppy or bad practice to initialize all the derived classes' members in the base class so that one of the derived classes can access those members, instead of initializing them in said derived class?
Proposed approach:
public class BaseClass {
public BaseClass() {
...
der1Initializer = Der1Initializer(new Factory1());
der2Initializer = Der1Initializer(new Factory2());
List initializers = new List(){ der1Initializer , der2Initializer };
der3Initializer = Der3Initializer(initializers);
}
Der1Initializer der1Initializer;
Der2Initializer der2Initializer;
Der3Initializer der3Initializer;
}
public class DerivedClass1 : BaseClass {
public SomeFunction {
der1Initializer.init();
}
}
public class DerivedClass2 : BaseClass {
public SomeFunction {
der2Initializer.init();
}
}
public class DerivedClass3 : BaseClass {
...
}
So that:
public class Der3Initializer {
public GroupInitializationFunction {
initializers[0].init(); //der1Initializer
initializers[1].init(); //der2Initializer
}
}
Instead of:
public class BaseClass {
public BaseClass() {
...
}
public class DerivedClass1 : BaseClass {
public DerivedClass1 {
der1Initializer = Der1Initializer(new Factory1());
}
public SomeFunction {
der1Initializer.init();
}
Der1Initializer der1Initializer;
}
public class DerivedClass2 : BaseClass {
public DerivedClass2 {
der2Initializer = Der2Initializer(new Factory2());
}
public SomeFunction {
der2Initializer.init();
}
Der2Initializer der2Initializer;
}
public class DerivedClass3 : BaseClass {
public DerivedClass3 {
List initializers = new List()
{
Der1Initializer(new Factory1()),
Der2Initializer(new Factory2());
};
der3Initializer = Der3Initializer(initializers);
}
...
Der3Initializer der3Initializer;
}
...
public class Der3Initializer {
public GroupInitializationFunction {
initializers[0].init(); //der1Initializer
initializers[1].init(); //der2Initializer
}
}
This is a vast oversimplification of the "problem". The purpose of this code is to reduce duplicate code and the need to reinitialize members that can be shared and to optimize performance.
I am aware that it isn't necessarily a good idea to give other classes access to members they aren't using.
I just thought this is an interesting problem regarding code separation vs. duplicate code.
I would not recommend initializing childs on the parent class as
Violates Open Closed Principle as the base class has the responsibility of initializing its children and there will always be the need to add new child classes and consequently modifying base class .
Violates Single Responsibility Principle as this is not the role for the base class (to initialize its childs )
Violates Inversion of Control as base class is tightly coupled to child class see this link
I created two abstract classes and tried to create a class that inherits from both. But I get an error message.
abstract class AbstractClassOne
{
public abstract void ShowMessage();
public abstract void DisplayName();
}
abstract class AbstractClassTwo
{
public abstract void ShowMessage();
public abstract void DisplayPlace();
}
class DerivedClass : AbstractClassOne, AbstractClassTwo // here under AbstractClassTwo it shows the error "cannot have multiple base classes:"
{
}
So a class can only derive from one abstract class?
If can derive from more than one abstract class, then what happens if both classes define the same method, as is the case above (abstract class one and two both have a method showmessage(), so which one will be in the derived class)?
Multiple inheritance is not allowed by C# but it is allowed by C++.
To answer your question regarding the ShowMessage() method that is a known problem in c++ with multiple inheritance called "The Diamond Problem". see: http://en.wikipedia.org/wiki/Multiple_inheritance
So basically you will have to excitability state to which method you are refereeing when calling it e.g. ParentA::ShowMessage()
if you want to have a type that is polymorphic to 2 other types than you should create two separate interfaces and implement them. and if you want to reuse the same methods than you will have to use compositions.
Interfaces example:
public interface ISomeInterface
{
public void ShowMessage();
public void DisplayName();
}
public class ClassOne : ISomeInterface
{
public void ShowMessage()
{
//implementation
}
public void DisplayName()
{
//implementation
}
}
public class ClassTwo : ISomeInterface
{
public void ShowMessage()
{
//implementation
}
public void DisplayPlace()
{
//implementation
}
}
Interface with reusable Show Message Method using composition:
public class ClassTwo : ISomeInterface
{
private ISomeInterface _MyPrivateReusableComponent = new ClassOne();
public void ShowMessage()
{
_MyPrivateReusableComponent.ShowMessage()
}
public void DisplayPlace()
{
_MyPrivateReusableComponent.DisplayName()
//implementation
}
}
In C# it's not allowed to inherit from more than one class. To do what you want here, you need to use interfaces.
abstract class AbstractClassOne
{
public abstract void ShowMessage();
public abstract void DisplayName();
}
Interface IClassTwo
{
void ShowMessage();
void DisplayPlace();
}
class DerivedClass : AbstractClassOne, IClassTwo
{
}
You can't inherit from more than one class (abstract or otherwise), but in your case the abstract classes are pretty much interfaces, so you can turn them into interfaces and inherit from them (you can inherit from any number of interfaces).
No, abstract class whether having all abstract methods or only some, makes no difference as far as inheritance in concerned. you can inherit only one class (in C#) and as many interfaces as you want.
i have another question open here on SO and after thinking about it, i may be approaching this in the wrong way.
i have 4 classes, that have the same properties and methods.
some of the classes, have their own properties and methods ( not overrides of the existing ones ).
currently i create each class as:
public class ClassOne
{
public ClassOne()
{
}
public int ID {get;set;}
// More properties here
public void Set(){
// Do Stuff to save this
}
// More Methods here
}
cant i create one class that will generate all of the 4 classes?
and in the classes themselfs i only create specific properties/methods for that class?
repeating the code seems very odd to me, im sure there must be a way to do this, just dont know how.
Your situation is one of the main reasons why inheritance was invented. So with that, you can write
public class Base
{
// Properties and methods common to all
}
public class ClassOne : Base
{
// Properties and methods specific to ClassOne
}
public class ClassTwo : Base
{
// Properties and methods specific to ClassTwo
}
public class ClassThree : Base
{
// Properties and methods specific to ClassThree
}
public class ClassFour : Base
{
// Properties and methods specific to ClassFour
}
As requested, more code, using interfaces and abstract classes:
An interface is just a blueprint, defining what properties and methods are required to be compatible with other "BaseClasses"
public interface IBaseClass
{
public int ID {get;set;}
public void Set();
}
Abstract classes can contain code, but can not be instantiated, they are form of starting point for a class, but not a complete class themselves.
public abstract class ABaseClass : IBaseClass
{
public int ID {get;set;}
public void Set(){
// Do Stuff to save
}
}
Each class inherits from the abstract class and can then override and implement whatever it wants, customizing it however is necessary.
public class ClassOne : ABaseClass
{
}
public class ClassTwo : ABaseClass
{
}
public class ClassThree : ABaseClass
{
}
public class ClassFour : ABaseClass
{
}
ps. not entirely sure if my syntax is 100% correct
Could you simply make a base class with your properties and inherit from that class?
Why not use inheritance??
public class ClassOne
{
public ClassOne()
{
}
public virtual int ID {get;set;}
// More properties here
public virtual void Set(){
// Do Stuff to save this
}
// More Methods here }
public class ClassTwo : ClassOne
{
public string ClassTwoString { get; set; }
}
public class ClassThree : ClassOne
{
public string ClassThreeString { get; set; }
}
Can you make them all inherit off of the same class? If so, that sounds ideal.
Barring the possibility of making them inherit, you could write an interface that describes the methods and properties which each of them use. Then you can call each instance of the class through the same interface.
Barring again that possibility, you could write a reflective assignor/accessor. But you shouldn't do that.