CODEWITHSUNDEEP
c#oopinterface
wafers
wafers

Reputation: 1241

Is it a good practice to add public methods in a class which are not in Interface definition? When should I do that?

Not very clear with OOP concepts, could be a silly question, please ignore the silliness of it :-)

The question is related to the class below. There I have added a public method "TestMethod()", which is not defined in the interface (below).

  1. Is it a bad practice? Should all methods must be defined in Interface?
  2. In which cases am I allowed to implement a public methods/members in a class, but not in an Interface?

The Interface...

public interface IAnimals
{
    void MakeNoise(string noise);
    void Move();
    string Color
    {
        get;
        set;
    }
}

The Class Implementation...

class Animal : IAnimals
{
    private string color;
    string IAnimals.Color
    {
        get
        {
            return color;
        }
        set
        {
            color = value;
        }
    }
    void IAnimals.MakeNoise(string noise)
    {
        Console.WriteLine("Animal " + noise);
    }
    void IAnimals.Move()
    {
        Console.WriteLine("Animal moves");
    }
    public void TestMethod()
    {
        Console.WriteLine("test method in Animal class");
    }
}

The Program...

class Program
{
    static void Main(string[] args)
    {
        //Animal1 show methods and properties defined in the Interface
        IAnimals animal1 = new Animal();

        //Animal2 only shows the public method of Animal class
        Animal animal2 = new Animal(); 

        animal1.Color = "Red";
        Console.WriteLine("Animal's color is " + animal1.Color);
        animal1.MakeNoise("Barks");
        animal1.Move();


        animal2.TestMethod();

        Console.ReadLine();
    }
}

And The Output...

Animal's color is Red

Animal Barks

Animal moves

test method in Animal class

Upvotes: 2

Views: 165

Answers (3)

supercat
supercat

Reputation: 81207

In some cases, a class will exist primarily for the purpose of satisfying an interface; if a class exists for the purpose of implementing interface IWuzzler and the most natural description for an instance of the class would be "a Wuzzler", then it may be good to have the public face of the class match the interface as well as possible; the fact that a member would be useful in the class would suggest that it might be useful as a [possibly optional] part of the interface.

In other cases, however, a class will exist for its own purposes but will satisfy an interface so that it can be operated upon by code that isn't apt to care about most of the things the class does. For example, many collection types might implement IEnumerable<T> even though their primary purpose centers around things that most consumers of IEnumerable<T> would know nothing about. If the class implements an interface for the purpose of making instances usable by outside general-purpose code, then the type should be expected to have many members which are not present in those interfaces.

Upvotes: 0

Adam Houldsworth
Adam Houldsworth

Reputation: 64517

My approach would go something like this.

A class should aim to have one responsibility (Single Responsibility Principle), and its public contract (namely, publicly accessible members) should be relevant to the responsibility it fulfils.

I would not attempt to enforce a correlation between concrete class public members and interface public members. A class may have a public member in order to fulfil a cross-cutting concern that isn't pertinent to the interface contract it is implementing, but is entirely pertinent to the implementation detail. Or it may even be implementing multiple interfaces or some that don't mean anything to its responsibility (such as IDisposable).

It depends on how you expose this contract as to whether this is a potential issue or not. I tend to expose interfaces to offer behaviour, as it allows me to use DI containers etc to manage implementation configurations, which in turn allows me to either mock the interface or provide a test implementation for the purposes of unit testing. That said, if you are handing around concrete types (which are also valid "contracts") then the public face of that type forms an implied contract, so you need to be careful of changing that (just as you would be careful changing interface definitions).

I never particularly worry that I have a type that has more public members than the interface does, but I do try to pay attention to what the type is trying to do (and look out for when it is trying to do too much).

So I would answer that it is good practice to review what responsibilities a class is trying to cover and attempt to minimise that to one, but I would say this public member comparison isn't a relevant "code smell" alert, in my opinion.

Upvotes: 3

Patrick Hofman
Patrick Hofman

Reputation: 157038

The interface definition declares only the properties and methods that makes the implementation comply with the 'contract'.

You will almost never have only the properties and methods defined in the interface in your class, since the class usually needs some more that a general contract implementation.

A good example in a class definition that deviates from the interface is a class implementing ICloneable. You need to implement the Clone method, but that doesn't describe what the class actually does, it just implements that contract the class has with the interface.

Upvotes: 2

Related Questions