3

I have the following interface:

interface IExcelServices
{
    Dictionary<string, string[]> FilterFields(Dictionary<string, string[]>  excelContent);
    Dictionary<string, string[]> ParseExcelFile(string path);
}

Which is implemented by the following class:

public class ExcelServices : IExcelServices
{
    public Dictionary<string, string[]> FilterFields(Dictionary<string, 
       string[]>  excelContent)
    {
        //somecode
    }

    public Dictionary<string, string[]> ParseExcelFile(string path)
    {
        //somecode
    }

    private void ReleaseObject(object obj)
    {
        //somecode
    }
}

My code compiles without any problem but I was wondering whether adding a private method (or in general any method) which is not in the interface definition is a good OO programming practice or not.

double-beep
  • 5,031
  • 17
  • 33
  • 41
CiccioMiami
  • 8,028
  • 32
  • 90
  • 151
  • yes, allowed, and used commonly, good programming practice too, but when u'll use design patterns, try to avoid that – MLS May 27 '11 at 09:39
  • 2
    @MLS, I can't see any good reason to avoid that... especially if the extra members are private! – Thomas Levesque May 27 '11 at 09:43
  • @MLS: may you please specify which design patterns do not allow this class design? Thanks – CiccioMiami May 27 '11 at 09:46
  • @Franscesco: i refered to mvc, @Thomas Levesque: u r right, but public methods were in my mind at that time – MLS May 27 '11 at 09:56

6 Answers6

10

Of course it is OK to add other members in a class that implements an interface. An interface is just a contract that specifies what the class must implement, but it can also add any members it needs (actually most classes have more members that the ones declared in the interface)

Thomas Levesque
  • 286,951
  • 70
  • 623
  • 758
4

The idea behind an interface is that the classes implementing it must include the functionality of the interface. This doesn't mean they have to be limited to what is in the interface, you can extend on it as much as you like, it's perfectly reasonable to have methods that aren't part of the interface. Likewise, you could implement more than one interface.

TabbyCool
  • 2,829
  • 1
  • 24
  • 36
2

Yes, that's fine - but your methods implementing the interface either have to be public or have to implement the method explicitly, e.g.

public Dictionary<string, string[]> FilterFields(...)

or

Dictionary<string, string[]> IExcelServices.FilterFields

Your current code will fail to compile, as the default visibility for methods is private.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
1

Good OO Programming practice would not inhibit implementing beyond an interface. Infact, the purpose of an interface is to be complimentary to the rest of a classes implementation.

EDIT

Furthermore, it is impossible for a non abstract class to be limited to just an interface and be useable. Interfaces do not define contructors which a creatable class must have.

Jodrell
  • 34,946
  • 5
  • 87
  • 124
1

It's the default for me: implementing some inferface makes sure others can use your class in a simple way and that your object (class) can be taken as single parts (interfaces).
But to work a class could need extra operations that you implement with private methods.
Be careful: methods implementing interfaces methods MUST BE public!!

Marco
  • 56,740
  • 14
  • 129
  • 152
0

Yes, this is possible. All the methods in the interface are required to be implemented though.

Sahil
  • 75
  • 2
  • 9
  • This is already covered by [the accepted answer](https://stackoverflow.com/a/6150383/1364007). Duplicate answers should not be posted and will be deleted. [From Review](https://stackoverflow.com/review/low-quality-posts/25497754). – Wai Ha Lee Mar 02 '20 at 07:32