There's already a nice answer but I noticed this part:
I might think of Interface as just multiple inheritance, but just that
we don't want to have the issues of multiple inheritance [...]
I'm guessing you're working in a language where the notion of "interface" is strictly stateless. I often find those somewhat heavy-handed and think multiple inheritance isn't quite as messy as some make it out to be.
Nevertheless, at a conceptual level, the stateless interface is often the most general, the most ideal from the contractual and maintenance point of view.
Robots With Wheels
For example, imagine I wrote a boatload of code using a robot interface which commanded robots to go to various places (rooms, buildings, countries).
If said interface included attributes like the idea that a robot has wheels, that would couple my requests to the notion that a robot has wheels. My requests would then only work for robots that have wheels (they might still be able to go to new locations using other means of transportation, but they would at least require possessing wheels to do it).
That degeneralizes the concept of a robot to one who at least possesses wheels, and likewise degeneralizes all the requests I've made for robots to go to new places which might span in the tens of thousands of lines of code, e.g..
Now let's say a new robot is introduced which has legs, or a jetpack, or a molecular transporter and really had no need for wheels at all. This spells trouble for all the existing robot classes and all the existing code using them through this interface. Now we're in a pretty awkward position of needing to rewrite a lot of code which we wouldn't be in if the interface/contract for robots was stateless.
Flexible Interfaces Allow Variety
In general, the most ideal interfaces from the standpoint of leaving code that is resilient to change will leave a lot of room for a rich variety of concrete implementations without violating the interface contract. Once state is introduced to an interface, it often very quickly degrades the richness and can significantly narrow the variety of possible solutions.
Should this be absolute forced in a language design? I don't know -- I'm biased as one who prefers languages that don't force this. Nevertheless, I think it's generally far better if we erred towards stateless interfaces. An attribute/state will far more quickly degrade the generality of your abstractions than functions.
But interface is only about methods, then how would we think about
adding attributes to the class due to interface?
These are implementation concerns. If the goal of a class that implements a Movable
interface is to move to new locations, you have all kinds of ways to implement it and also represent the data required to do so. Try to appreciate that flexibility/freedom.
Probably a concern here is that, after the dozenth class or so, you feel like you're duplicating a lot of the same kind of boilerplate to implement an interface. In that case, you can reach for an abstract base class potentially, or use composition (store a member which does a lot of the gruntwork), possibly static methods (maybe most gross, however, if it starts to look like nondescript helper functionality), etc.
But try to keep in mind how flexible the interface is as a result of it being stateless, of not mentioning such concrete details as part of its contract.
Moveable
interface and hence not being interested in theShape
, or using theShape
itself, which also provides you the access to theMoveable
interface.