Granular Interfaces - How Much OO Is Practical?

The ideas of cohesion and coupling point us to paths that either place functionality in smaller or larger classes.  We discuss granular interfaces in this episode as an introduction to those "right-sizing" discussions.  Not all OO designs are created equal. Granular Interfaces - Bricks or Sand The best example I have come across in considering how to approach our design's granularity is comparing sand to bricks.  We can construct a building by starting from sand, making blocks of concrete, and then moving on to the structure.  However, it is easier when we can start from the blocks or bricks. The Lego Example We can similarly look at the children's toy Lego bricks.  There are various sizes of bricks available.  Therefore, we can build almost any structure we can imagine.  The challenge is that we can build it out of combinations of larger bricks or work only with the one-by-one size bricks.  The faster path will be to use larger bricks.  The trade-off is that there are fewer customizations as we move to larger blocks. We see this in software design as well.  The more granular our approach, the easier it is to customize.   On the other hand, we do not want to a la carte our users into confusion.  They should not have to hand-pick every single method or feature.  Instead, we need to provide properly designed granular interfaces that group features that are best handled as a group. Grouping Methods While all assumptions will not hold in 100% of the cases, we can make assumptions to reduce our application's complexity.  For example, we can assume that a need to save a class includes a need to load.  Thus, we can take the CRUD functions and group them.  In business instances, we will see a lot of the same natural groups.  A customer contact feature will need to provide ways to create a customer, contact them, and track contact history.  Therefore, a customer interface is naturally going to be easier to use if it includes all of those methods.  These also help remind the developer (when using an interface) of functionality that should probably be implemented.  At an application level, we can think of features like security, registration, help, and session management.  These are not always needed.  However, it is worth our while to intentionally determine whether our application can skip one or more of those.