CODEWITHSUNDEEP
c#interface
Syed
Syed

Reputation: 931

Is it not breaking design principle of interface in c#?

When I googled to find the related topics about interface, I found this from MSDN website:

For example, an interface might declare a property that has a get accessor. The class that implements the interface can declare the same property with both a get and set accessor. from MSDN

Now I have a doubt. When we specifically mentioned that the property should be read only(only 'get' accessor in the interface) why is it allowed to implement 'set' accessor also?

Upvotes: 4

Views: 196

Answers (10)

supercat
supercat

Reputation: 81347

It may be helpful to think in terms of three types of things: an abstract ReadableFoo class (or IReadableFoo interface), along with concrete ImmutableFoo and MutableFoo classes (or IImmutableFoo and IChangeableFoo interfaces). Someone who receives a parameter of type ReadableFoo will be able to read it, but will not be able to set it, and will not be able to reliably persist the data therein merely by persisting a reference. Someone who receives a parameter of ImmutableFoo would be able to reliably persist the data by persisting the reference, but would not be able to change it. Someone who receives a parameter of MutableFoo will be able to change the data, but not reliably persist data by persisting the reference.

Upvotes: 0

Maciej
Maciej

Reputation: 7971

Interface is a minimum set of requirements that needs to be implemented but you can implement more. In this case read-write property is more than just read-only one.

Besides extending beyond requirements of a contract you can add any other methods and/or properties and also implement other interfaces in the same class.

Upvotes: 3

KeithS
KeithS

Reputation: 71591

What Felix said is correct.

In more detail, an interface defines a minimum set of functionality that must exist on any object defined as implementing said interface. That provides a "common" set of functionality among all implementations of the interface, so you know that if an object implements the interface, you can call X, Y, and Z on it. Just because something is IDisposable, for instance, doesn't mean that's ALL the object can do. In fact that would make interfaces rather pointless, if they also defined a maximum amount of functionality. That's just all you care about if and when you are working with the object as an implementation of the interface; if all you need is an IDisposable, you only care about calling Dispose(), regardless of what additional members a particular IDisposable implementation may have.

Back to your example, the interface defining the property is stating that it must have a public get accessor. It does not, and cannot, say that it cannot have a public set accessor; it simply doesn't care either way. The set accessor could be public, internal, protected, private, or nonexistent; what consumers of the interface will expect, and thus what implementors of the interface will need, is the get accessor.

Upvotes: 0

qxn
qxn

Reputation: 17594

public interface IFoo {
    string Name { get; }
}

class FooImplementation : IFoo {
    public string Name { get; set; }
}

public class FooWorker {
    public void WorkOnFoo(IFoo foo) {
        if (null == foo) throw new ArgumentNullException("foo");
        Console.WriteLine(foo.Name);
    }
}

public class Program {
    public void Main() {
        IFoo foo = new FooImplementation { Name = "Foo" };
        new FooWorker().WorkOnFoo(foo);
    }
}

As far as FooWorker is concerned, the foo parameter only has a get accessor for the Name property.

It's probably important to remember that that the Name property may still be set on foo via reflection or a cast.

Upvotes: 0

JaredPar
JaredPar

Reputation: 755587

The interface though is just a declaration of how the object should be used by consumers. It doesn't make any specifications about the implementation. There's no inconsistency there.

Upvotes: 0

tbddeveloper
tbddeveloper

Reputation: 2447

The class is meeting the requirements of the interface, anything else is an implementation detail of the class itself. If you're referring to the object through the interface, you're only going to see the get. So, no, it's not really breaking it, it's as intended.

Upvotes: 0

moribvndvs
moribvndvs

Reputation: 42495

Think of an interface as a contract. Implementers promise to at least comply to the behaviors defined in that contract, but are not restricted to it. Interfaces allow components to interact without being tightly coupled. Therefore, an implementation may allow both get and set, but at the very least must honor the get.

Upvotes: 0

BlueM
BlueM

Reputation: 6898

The code which uses the interface does not know that there is a set and so can't use it.

Upvotes: 2

Reed Copsey
Reed Copsey

Reputation: 564931

Now I have a doubt. When we specifically mentioned that the property should be read only(only 'get' accessor in the interface) why is it allowed to implement 'set' accessor also?

There's a difference - when you use an interface, you're not "specifying that the property should be read only", but rather specifying that the contract defines a "readable property" of that specific name and type. Basically, the interface defines the minimum requirements for a contract, not the absolute requirements.

If you cast the object to the specific interface, the property setter will not be available. It's really no different than having extra properties or methods on the object that aren't available via the interface.

Upvotes: 12

Felix K.
Felix K.

Reputation: 6281

You can't access the set property from a interface reference, so it doesn't matter if it's implemented or not when revealing the interface to the public.

Of course it's sometimes necessary to implement a set accessor on class side, i.e. when working with a class which allows access of classes which are in the same assembly.

Upvotes: 3

Related Questions