Interface properties implementation

Question

As the code below, class Foo1 implements interface IFoo, which has a property of IData.

public interface IFoo
{
    public IData Data { get; set; }
}

public interface IData { ... }

public class DataA : IData {...}
public class DataB : IData {...}

public class Foo1 : IFoo
{
    private DataB _data;
    public IData Data
    {
        get { return _data; }
        set { _data = new DataB(value); }
    }
}

If the user assigns the Data property of Foo1 with an object of DataA, and then gets the property value back later. He will get an object of DataB instead of DataA. Does this violate any OO principles? Thanks.

Answer 1

No, you are not violating any OO principles. Least of all because properties are not an OO concept.

There is also no rule that states that you must be able to retrieve from a property exactly the value that you stored in it.

Without better names or more documentation, you might be violating the "principle of least astonishment" but that is hard to tell from such a contrived example. And it is not an OO principle, but a general programming one.

Answer 2

Yes this may be violating OO principles. There is not enough of the design shown to say with certainty but what I see is a code smell.

A good class exposes functionality and hides state. When a property is exposed rather than a functional method using that state then take a good hard look. When exposing a naked, as it were, substantially complex data object then client manipulation code spreads like cancer among the using classes. It's becomes a real face palm situation with inheritance where the problem grows exponentially for want of encapsulation.

I'm not anti data transfer object (DTO) at all. However one should strive for design that conveys intent and also restricts usage by encapsulating DTOs in functional classes.

---

He will get an object of DataB instead of DataA. Does this violate any OO principles?

I get the impression that these days inheritance is somehow considered a violation of OO principles. The following is very OO:

public class B : A {  }

A myThing = new B(dataThingy);

Now myThing can behave as an A or B. This is a very good thing if it fits in a design that supports requirements.

Capital I interface, composition, and inheritance should be thought of as co-equal siblings that taken together make for flexible, expressive, and OO compliant design.

---

Answer 3

The line,

set { _data = new DataB(value); }

definitely violates the principle of least surprise/astonishment. It totally disregards the value passed to it and just creates a new DataB instead. So the setter serves no purpose other than to confuse the developer.

One solution to this is just to remove the setter from the interface:

public interface IFoo
{
    public IData Data { get; }
}

and likewise to not have a setter for Foo1.Data either. If the developer can't set the value via the property, don't provide the setter in the first place.