0

I have an interface and two data sources that populate concrete instances of objects that implement the interface. The interface exposes methods that only one of the two instances can satisfy in a meaningful way.

public interface IFoo {
    public int getValueA();
    public int getValueB();
}

public FooFromFile implements IFoo {
    int a;
    int b;
    ...
    public int getValueA() {
        return a;
    }
    public int getValueB() {
        return b;
    }
}

public FooFromNetwork implements IFoo {
    int a;
    ...
    public int getValueA() {
        return a;
    }
    public int getValueB() {
        return 0; // return 0 because FooFromNetwork never gets value b.
    }
}

Every code base I've worked on has code like this and I find it usually stems from a desire to apply 'is-a' relationships where something else may be more appropriate. I have some time to refactor the code base on which I am currently working. What would be some good modeling solutions for situations like this? The actual code is much more complicated than this but solving the toy issue here, with a robust pattern that scales, would go a long way.

user1332148
  • 1,256
  • 2
  • 11
  • 24
  • The problem with your toy problem is that there is no difference in behavior between the classes. As such, they should be rolled into a single class and be done with it. The problem needs to be more complex before an OO solution becomes reasonable. – Daniel T. Nov 28 '15 at 02:06
  • To put it another way... An OO solution almost invariably revolves around the setters of a class rather than the getters. If you want to find a good OO solution, you will have to focus of how `a` and `b` are *set* and how that setting is different between the two classes... – Daniel T. Nov 28 '15 at 02:12
  • @DanielT. could you link to a supporting article or documentation for the assertion that OOP revolves around setters? I have never heard that before. – jaco0646 Nov 28 '15 at 16:37
  • Look at any book that discusses OO theory for eg "Object-Oriented Analysis and Design" by Booch or even "Design Patterns" by the GoF. They don't actually *make* the assertion (the assertion is mine) but if you study the theory and examples, you will find that there is a heavy focus on methods that *don't* return data. Rather the methods *do something*, usually by changing object state. – Daniel T. Nov 28 '15 at 16:43
  • I'd love to have a conversation about it, but stack exchange is not a good forum for such talks... If you know somewhere that we could discuss it, I'm happy go into more detail. My email address is danielt1263 at gmail. – Daniel T. Nov 28 '15 at 16:46
  • Cpuld you give some more context, e.g. what the interface models and what the methods do? – Jens Nov 28 '15 at 20:50

1 Answers1

0

The problem described here "is a" (pun intended) violation of the Liskov Substitution Principle. There are many solutions to LSP violations, but nothing is one-size-fits-all. For example, depending on context you may choose to favor composition over inheritance or apply interface segregation.

Community
  • 1
  • 1
jaco0646
  • 15,303
  • 7
  • 59
  • 83