Quote:
Originally Posted by BlackEleven
There is no difference there. Those two things are functionally equivalent.
But to the second example I could add something like
protected String food;
Because my variable is protected I can control access to it. For example, I could make sure that the Eat method is the only way the dog's food can be consumed. I don't have to worry about some idiot using my class using dog.food to screw things up for me.
I don't have anyway of doing this with an interface where everything is public.
|
I think this is the wrong way about thinking of things. As developers we're typically not building libraries that are meant to be extended. Interfaces should be thought of as contracts or facades that consumers use. The fact that the details are hidden from consumers is just a byproduct.
Granted the example given, there is not much of a difference. It all depends on a larger context. Are animals being used somehow by other components of the system? It may make sense to go with the interface approach if IAnimal is used in the right context.
As my earlier image suggested it's hard to know when you're just starting to learn about these concepts. It takes years of experience before it starts to make sense, that's just the reality.
