Yes it's clever but I probably wouldn't hire you as a developer :). Just think of somebody else having to fix a bug or implement a change in code like that!

I agree with forever young. The interfaces are not very well designed in my opinion. The entire solution can get rid of the Engine interface and class altogether and it would still work. TDD development dictates: Do the minimal amount of work possible in order to pass the tests. The redundancy is not needed.

No, it's just unnecessary duplication. The clean way to get the engine status is via engine.isRunning() and if you'd need the to know if the car is running car.isRunning() which would return engine.isRunning(). These extra status bools are just a burden to maintain.

A good reason why engineIsRunning is part of ICar is the Law of Demeter:

"The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents)"

Sorry for the late response.

Some users (also me) used them for their solution.
If you do not need them: Great! Then do not use it! I'm curious for your solution. :-)

Nice idea, but why all these redundant variables?

• Why are the variables 'fillLevel', isOnReserve' and 'isComplete' duplicated?

• Why is there a variable 'engineIsRunning' in ICar when this is already a property of IEngine?