It looks like the answers on both sides of the fence can be summed up in this:

Design well, and put interfaces where interfaces are needed.

As I noted in my response to Yanni's answer, I don't think you can ever have a hard and fast rule about interfaces. The rule needs to be, by definition, flexible. My rule on interfaces is that an interface should be used anywhere you're creating an API. And an API should be created anywhere you're crossing the boundary from one domain of responsibility into another.

For (a horribly contrived) example, let's say you're building a Car class. In your class, you'll certainly need a UI layer. In this particular example, it takes the form of an IginitionSwitch , SteeringWheel , GearShift , GasPedal , and BrakePedal . Since this car contains an AutomaticTransmission , you don't need a ClutchPedal . (And since this is a terrible car, there is no A/C, radio, or seat. As a matter of fact, the floorboards are missing too - you just have to hang on to that steering wheel and hope for the best!)

So which of these classes need an interface? The answer could be all of them, or none of them - depending on your design.

You could have an interface that looked like this:

Interface ICabin Event IgnitionSwitchTurnedOn() Event IgnitionSwitchTurnedOff() Event BrakePedalPositionChanged(int percent) Event GasPedalPositionChanged(int percent) Event GearShiftGearChanged(int gearNum) Event SteeringWheelTurned(float degree) End Interface

At that point, the behavior of those classes becomes part of the ICabin Interface/API. In this example the classes (if there are some) are probably simple, with a few properties, and a function or two. And what you are implicitly stating with your design is that these classes exist solely to support whatever concrete implementation of ICabin you have, and they cannot exist on their own, or they are meaningless outside of the ICabin context.

It's the same reason that you don't unit-test private members - they exist only to support the public API, and thus their behavior should be tested by testing the API.

So if your class exists solely to support another class, and conceptually you view it as not really having it's own domain then it's fine to skip the interface. But if your class is important enough that you consider it grown up enough to have it's own domain, then go ahead and give it an interface.

EDIT:

Frequently (including in this answer) you'll read things like 'domain', 'dependency' (frequently coupled with 'injection') that don't mean a thing to you when you're beginning to program (they sure didn't mean anything to me). For domain, it means exactly what it sounds like:

The territory over which dominion or authority is exerted; the possessions of a sovereign or commonwealth, or the like. Also used figuratively. [WordNet sense 2] [1913 Webster]

In the terms of my example - let's consider the IgnitionSwitch . In a meatspace car, the ignition switch is responsible for:

Authenticating(not identifying) the user (they need the correct key) Providing current to the starter so it can actually start the car Providing current to the ignition system so it can continue to operate Shutting off current so the car will stop. Depending on how you view it, in most (all?) newer cars there's a switch that prevents the key from being removed from the ignition while the transmission is out of Park, so this could be part of its domain. (Actually it means I need to rethink and redesign my system...)

Those properties make up the domain of the IgnitionSwitch , or in other words, what it knows about and is responsible for.

The IgnitionSwitch is not responsible for the GasPedal . The ignition switch is completely ignorant of the gas pedal in every way. They both operate completely independent of one another (though a car would be fairly worthless without both of them!).