Asked  7 Months ago    Answers:  5   Viewed   32 times

This may be a generic OOP question. I wanted to do a generic comparison between an interface and an abstract class on the basis of their usage.

When would one want to use an interface and when would one want to use an abstract class?



I wrote an article about that:

Abstract classes and interfaces


When we talk about abstract classes we are defining characteristics of an object type; specifying what an object is.

When we talk about an interface and define capabilities that we promise to provide, we are talking about establishing a contract about what the object can do.

Tuesday, June 1, 2021
answered 7 Months ago

As with most things you should pick which to use based on the context and what is conceptually the correct way to go. A switch is really saying "pick one of these based on this variables value" but an if statement is just a series of boolean checks.

As an example, if you were doing:

int value = // some value
if (value == 1) {
} else if (value == 2) {
} else {

This would be much better represented as a switch as it then makes it immediately obviously that the choice of action is occurring based on the value of "value" and not some arbitrary test.

Also, if you find yourself writing switches and if-elses and using an OO language you should be considering getting rid of them and using polymorphism to achieve the same result if possible.

Finally, regarding switch taking longer to type, I can't remember who said it but I did once read someone ask "is your typing speed really the thing that affects how quickly you code?" (paraphrased)

Thursday, June 3, 2021
answered 7 Months ago

Why does the error go away as soon as I change IMsg to an abstract class instead of an interface?

Good question!

The reason this fails is because you are relying upon formal parameter contravariance in the conversion from the method group to the delegate type, but covariant and contravariant method group conversions to delegates are only legal when every varying type is known to be a reference type.

Why is the varying type not "known to be a reference type"? Because an interface constraint on T does not also constrain T to be a reference type. It constrains T to be any type that implements the interface, but struct types can implement interfaces too!

When you make the constraint an abstract class instead of an interface then the compiler knows that T has to be a reference type, because only reference types can extend user-supplied abstract classes. The compiler then knows that the variance is safe and allows it.

Let's look at a much simpler version of your program and see how it goes wrong if you allow the conversion you want:

interface IMsg {}
interface IHandler<T> where T : IMsg
    public void Notify(T t);
class Pub<T> where T : IMsg
    public static Action<T> MakeSomeAction(IHandler<IMsg> handler)
        return handler.Notify; // Why is this illegal?

That's illegal because you could then say:

struct SMsg : IMsg { public int a, b, c, x, y, z; }
class Handler : IHandler<IMsg> 
    public void Notify(IMsg msg)
Action<SMsg> action = Pub<SMsg>.MakeSomeAction(new Handler());

OK, now think about what that does. On the caller side, the action is expecting to put a 24 byte struct S on the call stack, and is expecting the callee to process it. The callee, Handler.Notify, is expecting a four or eight byte reference to heap memory to be on the stack. We've just misaligned the stack by between 16 and 20 bytes, and the first field or two of the struct is going to be interpreted as a pointer to memory, crashing the runtime.

That's why this is illegal. The struct needs to be boxed before the action is processed, but nowhere did you supply any code that boxes the struct!

There are three ways to make this work.

First, if you guarantee that everything is a reference type then it all works out. You can either make IMsg a class type, thereby guaranteeing that any derived type is a reference type, or you can put the "class" constraint on the various "T"s in your program.

Second, you can use T consistently:

class Pub<T> where T : IMsg
    public static Action<T> MakeSomeAction(IHandler<T> handler) // T, not IMsg
        return handler.Notify; 

Now you cannot pass a Handler<IMsg> to C<SMsg>.MakeSomeAction -- you can only pass a Handler<SMsg>, such that its Notify method expects the struct that will be passed.

Third, you can write code that does boxing:

class Pub<T> where T : IMsg
    public static Action<T> MakeSomeAction(IHandler<IMsg> handler) 
        return t => handler.Notify(t); 

Now the compiler sees, ah, he doesn't want to use handler.Notify directly. Rather, if a boxing conversion needs to happen then the intermediate function will take care of it.

Make sense?

Method group conversions to delegates have been contravariant in their parameter types and covariant in their return types since C# 2.0. In C# 4.0 we also added covariance and contravariance on conversions on interfaces and delegate types that are marked as being safe for variance. It seems like from the sorts of things you are doing here that you could possibly be using these annotations in your interface declarations. See my long series on the design factors of this feature for the necessary background. (Start at the bottom.)

Incidentally, if you try to pull these sorts of conversion shenanigans in Visual Basic, it will cheerfully allow you to. VB will do the equivalent of the last thing; it will detect that there is a type mismatch and rather than telling you about it so that you can fix it, it will silently insert a different delegate on your behalf that fixes up the types for you. On the one hand, this is a nice sort of "do what I mean not what I say" feature, in that code that looks like it ought to work just works. On the other hand, it is rather unexpected that you ask for a delegate to be made out of the method "Notify", and the delegate you get back out is bound to a completely different method that is a proxy for "Notify".

In VB, the design philosophy is more on the "silently fix my mistakes and do what I meant" end of the spectrum. In C# the design philosophy is more on the "tell me about my mistakes so I can decide how to fix them myself" end. Both are reasonable philosophies; if you are the sort of person that likes when the compiler makes good guesses for you, you might consider looking into VB. If you're the sort of person who likes it when the compiler brings problems to your attention rather than making a guess about what you meant, C# might be better for you.

Thursday, August 12, 2021
answered 4 Months ago

The need for an inheritance chain is questionable, in general.

However the specific scenario of combining an abstract base class with an interface.. I see it this way:

If you have an abstract base class like this, you should also have a corresponding interface. If you have an interface, then use the abstract base class only where the inheritance chain is sensible.

That said, if I'm writing a library and this is part of my API/Framework, I will generally include a "default implementation" that can be used as a base class. It will implement the interface methods in a naive, general way, where possible, and leave the rest for inheritors to implement/override as needed.

This is just a convenience feature of the library though, to assist people who want to implement the interface by providing a functional example that may cover most of what they need to implement already.

In short, the interface is more valuable than the base class, but a base class might save a lot of time and reduce buggy interface implementations.

Wednesday, September 15, 2021
answered 3 Months ago

I am also Ruby starter. From my understanding, there is a closer rival for abstract classes in ruby. that is module. you can't create any instances of module but you can include with another class. So a target class will get the whole functionality of parent

  module Log
    def write

  class EventLog
    include Log

    def Prepare

In statically typed languages like java/C# , Interfaces enforce the classes to have all the methods at compile time. Since Ruby is dynamic, there is no meaning in it.

For more clarity, check these posts why dynamic languages don't require interfaces..

  1. why-dont-we-require-interfaces-in-dynamic-languages
  2. why-do-dynamic-languages-like-ruby-and-python-not-have-the-concept-of-interfaces


Sunday, September 26, 2021
answered 3 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :