Design Question
-
suppose I have a class A, and the interfaces I1 and I2. Interfaces I1 contains methods a,b Interfaces I2 contains methods a,b,c and d class A can implements I1 or I2 depending on how it is constructed. Question, what is the best structure to organize it? one solution is to create a base class for Class A which implements only I1, and make Class A derived implementing I2: Class BaseA:I1 Class A: I2, BaseA Do you know any smarter solution?
-
suppose I have a class A, and the interfaces I1 and I2. Interfaces I1 contains methods a,b Interfaces I2 contains methods a,b,c and d class A can implements I1 or I2 depending on how it is constructed. Question, what is the best structure to organize it? one solution is to create a base class for Class A which implements only I1, and make Class A derived implementing I2: Class BaseA:I1 Class A: I2, BaseA Do you know any smarter solution?
You should only use a base class where you want the exact same implementation in all derived classes. A an interface is a contract (no implementation unlike an abstract class) I don't really see the problem. This works just fine:
public interface I1
{
void A();
void B();
}
public interface I2
{
void A();
void B();
void C();
void D();
}
public class ClassA : I1, I2
{
public void A()
{ }
public void B()
{ }
public void C()
{ }
public void D()
{ }
}If you want differing implementations of A and B depending on whether usin I1 or I2 then use explicit declaration:
public class ClassA2 : I1, I2
{
void I1.A()
{ }
void I2.A()
{ }
void I1.B()
{ }
void I2.B()
{ }
public void C()
{ }
public void D()
{ }
}You will now need to cast the instance to either I1 or I2 to have access to methods A or B, but you can mix it up and provide the default implementation:
public class ClassA2 : I1, I2
{
public void A()
{
(this as I1).A();
}
public void B()
{
(this as I1).B();
}
void I1.A()
{ }
void I2.A()
{ }
void I1.B()
{ }
void I2.B()
{ }
public void C()
{ }
public void D()
{ }
}Dave
Binging is like googling, it just feels dirtier. Please take your VB.NET out of our nice case sensitive forum. Astonish us. Be exceptional. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) -
You should only use a base class where you want the exact same implementation in all derived classes. A an interface is a contract (no implementation unlike an abstract class) I don't really see the problem. This works just fine:
public interface I1
{
void A();
void B();
}
public interface I2
{
void A();
void B();
void C();
void D();
}
public class ClassA : I1, I2
{
public void A()
{ }
public void B()
{ }
public void C()
{ }
public void D()
{ }
}If you want differing implementations of A and B depending on whether usin I1 or I2 then use explicit declaration:
public class ClassA2 : I1, I2
{
void I1.A()
{ }
void I2.A()
{ }
void I1.B()
{ }
void I2.B()
{ }
public void C()
{ }
public void D()
{ }
}You will now need to cast the instance to either I1 or I2 to have access to methods A or B, but you can mix it up and provide the default implementation:
public class ClassA2 : I1, I2
{
public void A()
{
(this as I1).A();
}
public void B()
{
(this as I1).B();
}
void I1.A()
{ }
void I2.A()
{ }
void I1.B()
{ }
void I2.B()
{ }
public void C()
{ }
public void D()
{ }
}Dave
Binging is like googling, it just feels dirtier. Please take your VB.NET out of our nice case sensitive forum. Astonish us. Be exceptional. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)may be not clear my question: I2 has "a" and "b" methods that are the same of I1 So I2:I1 But the class A not always is able to implement I2. It depend on the constructor used in A. If A is instantiated using a contructor, then A implement I2, otherwise only I1. This is why I create a base class So: I2:I1 BaseA: I1 A:BaseA, I2 This is the herarchy, it works, but it looks a bit overkilling for the simple problem. I was only asking if there is a more elegant solution..
-
suppose I have a class A, and the interfaces I1 and I2. Interfaces I1 contains methods a,b Interfaces I2 contains methods a,b,c and d class A can implements I1 or I2 depending on how it is constructed. Question, what is the best structure to organize it? one solution is to create a base class for Class A which implements only I1, and make Class A derived implementing I2: Class BaseA:I1 Class A: I2, BaseA Do you know any smarter solution?
Why not make
I2
and abstract class so that whenI2
's methods are not implemented by ClassA the default empty implementation will work. here is some sample code: Note: ReplaceI2
withA2
andClassA
andClassA2
are two possible versions you could have forClassA
public interface I1 { void A(); void B(); } public abstract class A2 : I1 { public virtual void C() { //nothing in default implementation } public virtual void D() { //nothing in default implementation } #region I1 Members public abstract void A(); public abstract void B(); #endregion } // case 1 // fuction A and B will be there always // not implementing C and D public class ClassA : A2 { public override void A() { } public override void B() { } } // case 2 // fuction A and B will be there always // ALSO implementing C and D public class ClassA2 : A2 { public override void A() { } public override void B() { } public override void C() { } public override void D() { } }
Every now and then say, "What the Elephant." "What the Elephant" gives you freedom. Freedom brings opportunity. Opportunity makes your future.
-
suppose I have a class A, and the interfaces I1 and I2. Interfaces I1 contains methods a,b Interfaces I2 contains methods a,b,c and d class A can implements I1 or I2 depending on how it is constructed. Question, what is the best structure to organize it? one solution is to create a base class for Class A which implements only I1, and make Class A derived implementing I2: Class BaseA:I1 Class A: I2, BaseA Do you know any smarter solution?
TheGermoz wrote:
class A can implements I1 or I2 depending on how it is constructed
This is a dead giveaway for poor design. Inheritance hierarchies are telling you what operations you can do on an object, and you should be able to tell from the type of something what you can do with it. That is, an instance of A should always be treatable as an I2, or never. What you almost certainly want to do is:
interface I1 {
void A();
void B();
}interface I2 : I1 {
void C();
void D();
}class A : I1 {
// Implementations of the I1 functionality, and the I1 type constructor
public virtual void A() {}
public virtual void B() {}
}class A2 : A, I2 {
// Implementations of the I2 functionality, and the I2 type constructor
public void C() {}
public void D() {}// You can also override implementations from A
public override void A() {
base.A();
// other stuff
}
} -
Why not make
I2
and abstract class so that whenI2
's methods are not implemented by ClassA the default empty implementation will work. here is some sample code: Note: ReplaceI2
withA2
andClassA
andClassA2
are two possible versions you could have forClassA
public interface I1 { void A(); void B(); } public abstract class A2 : I1 { public virtual void C() { //nothing in default implementation } public virtual void D() { //nothing in default implementation } #region I1 Members public abstract void A(); public abstract void B(); #endregion } // case 1 // fuction A and B will be there always // not implementing C and D public class ClassA : A2 { public override void A() { } public override void B() { } } // case 2 // fuction A and B will be there always // ALSO implementing C and D public class ClassA2 : A2 { public override void A() { } public override void B() { } public override void C() { } public override void D() { } }
Every now and then say, "What the Elephant." "What the Elephant" gives you freedom. Freedom brings opportunity. Opportunity makes your future.
Is there a plus in this design with respect my one?
-
TheGermoz wrote:
class A can implements I1 or I2 depending on how it is constructed
This is a dead giveaway for poor design. Inheritance hierarchies are telling you what operations you can do on an object, and you should be able to tell from the type of something what you can do with it. That is, an instance of A should always be treatable as an I2, or never. What you almost certainly want to do is:
interface I1 {
void A();
void B();
}interface I2 : I1 {
void C();
void D();
}class A : I1 {
// Implementations of the I1 functionality, and the I1 type constructor
public virtual void A() {}
public virtual void B() {}
}class A2 : A, I2 {
// Implementations of the I2 functionality, and the I2 type constructor
public void C() {}
public void D() {}// You can also override implementations from A
public override void A() {
base.A();
// other stuff
}
}yes this is my degign I propose, I was wandering if it is ok
-
Is there a plus in this design with respect my one?
Strictly talking from a designs standpoint - Yes there is. You see when we have an interface we are saying that we are defining a contract and all the classes implementing this interface should implement this contract i.e. methods. We cannot then say that we need to selectively implement the methods. The abstract class says that, I am providing a default implementation and the derived class is free to have his own IF it needs to. So in your case you needed some functions to be implemented selectively and some mandatory so following the design principle, I moved the mandatory ones in the contract i.e. the interface and the optional ones in abstract class. and in this particular case the default implementation of optional methods is to do nothing. I hope i am able to convey my thoughts clearly. Do let me know if not. I am also open to counter arguments as they will only enhance my learning. (counter arguments == brainstorming) i.e. always beneficial :)
Every now and then say, "What the Elephant." "What the Elephant" gives you freedom. Freedom brings opportunity. Opportunity makes your future.
-
TheGermoz wrote:
class A can implements I1 or I2 depending on how it is constructed
This is a dead giveaway for poor design. Inheritance hierarchies are telling you what operations you can do on an object, and you should be able to tell from the type of something what you can do with it. That is, an instance of A should always be treatable as an I2, or never. What you almost certainly want to do is:
interface I1 {
void A();
void B();
}interface I2 : I1 {
void C();
void D();
}class A : I1 {
// Implementations of the I1 functionality, and the I1 type constructor
public virtual void A() {}
public virtual void B() {}
}class A2 : A, I2 {
// Implementations of the I2 functionality, and the I2 type constructor
public void C() {}
public void D() {}// You can also override implementations from A
public override void A() {
base.A();
// other stuff
}
}This is good. +5. P.S. We might do away with the interface containing the optional functions as these are not a part of the contract. Also we can make class A as abstract to make sure no one is able to create it directly as its only purpose is to facilitate default implementation for optional functions. I tried to do this design this way. I would love to hear your opinion on it: http://www.codeproject.com/Messages/4429095/Re-Design-Question.aspx[^]
Every now and then say, "What the Elephant." "What the Elephant" gives you freedom. Freedom brings opportunity. Opportunity makes your future.
-
This is good. +5. P.S. We might do away with the interface containing the optional functions as these are not a part of the contract. Also we can make class A as abstract to make sure no one is able to create it directly as its only purpose is to facilitate default implementation for optional functions. I tried to do this design this way. I would love to hear your opinion on it: http://www.codeproject.com/Messages/4429095/Re-Design-Question.aspx[^]
Every now and then say, "What the Elephant." "What the Elephant" gives you freedom. Freedom brings opportunity. Opportunity makes your future.
Since we don't know what the interfaces or the class 'A' represent we can't be sure what the contracts needed are. But as the question has two interfaces in it, it seems likely that he needs both, and publicly instantiable classes that implement each.
Rahul Rajat Singh wrote:
Also we can make class A as abstract to make sure no one is able to create it directly as its only purpose is to facilitate default implementation for optional functions.
I don't think that's true. The original question suggests that it is possible to construct an A which is fully functional but only supports the I1 operations, and that it's also possible to construct an A which additionally implements I2. That means you need a concrete class and a concrete subclass.
-
suppose I have a class A, and the interfaces I1 and I2. Interfaces I1 contains methods a,b Interfaces I2 contains methods a,b,c and d class A can implements I1 or I2 depending on how it is constructed. Question, what is the best structure to organize it? one solution is to create a base class for Class A which implements only I1, and make Class A derived implementing I2: Class BaseA:I1 Class A: I2, BaseA Do you know any smarter solution?
Is there a reason why you are using interfaces? Too many .NET programmers make the mistake of thinking they need to use interfaces everywhere. Just like any other technology/construct/etc., you should only use interfaces when appropriate. Is anybody using your class external to your app? Based on the information you provided in your post, your design should be: class A { virtual void a(); virtual void b(); } class B : A { virtual void c(); virtual void d(); } why over complicate? KISS.
-
suppose I have a class A, and the interfaces I1 and I2. Interfaces I1 contains methods a,b Interfaces I2 contains methods a,b,c and d class A can implements I1 or I2 depending on how it is constructed. Question, what is the best structure to organize it? one solution is to create a base class for Class A which implements only I1, and make Class A derived implementing I2: Class BaseA:I1 Class A: I2, BaseA Do you know any smarter solution?
Make interface I1 an abstract class instead (A1) or just create the class, whichever makes more sense, and inherit from A1 when you implement I2. Probably no reason to have the interface and the base class A1
-
Is there a reason why you are using interfaces? Too many .NET programmers make the mistake of thinking they need to use interfaces everywhere. Just like any other technology/construct/etc., you should only use interfaces when appropriate. Is anybody using your class external to your app? Based on the information you provided in your post, your design should be: class A { virtual void a(); virtual void b(); } class B : A { virtual void c(); virtual void d(); } why over complicate? KISS.
Yes really there is a reason, the example was a very simplify version of may real problem. Anyway I appreciate your answer