One principle I have seen when it comes to Agile Development practices is to design the simplest thing necessary to completing the objective. Now, I take this with a grain of salt because I could easily create a straightforward application that is highly coupled, non-cohesive and overall difficult to maintain in a real-world environment of ever-changing requirements.

So, given that I will at least put in the effort to use good OO design while still doing the simplest thing to reach my objective, I feel that there are times when adding a little abstraction to your designs is a simple task that can benefit you greatly down the road.

As a rule of thumb, I almost always stick at least one controller class in my business tier to mediate between my business objects and my user interface layer (or persistence layer, for that matter), regardless of the size of the application. There are several benefits to doing this:

• It is a better place to keep business rules than in your UI, especially if the business rule applies to several screens. This helps in lowering coupling between objects.
• It lowers the overall responsibility of your business classes, keeping them highly-cohesive.
• If When your business rules change, there will be fewer places that you’ll need to make your changes (ideally, only one spot: a method in your controller class).

To paraphrase one of my old college professors: It is better to have too many (software) classes than too few.