This episode focuses on cohesion and the idea of using fewer large objects to solve a problem. This approach is often considered the opposite of using more smaller objects. We will find out that there are ways to combine these two different approaches as a best-fit method.
Cohesion Strengths
We have already defined and provided a summary of cohesion. Therefore, we can dive right into some specifics and strengths of this approach. I find simplicity to be one of the most apparent strengths of these solutions. While it provides a sort of “junk-drawer” approach in some cases, it also means we do not spend time deciding what goes where. When done properly, we can see this approach as having all of the important things you are working on sitting on your desk. Nothing is filed away. Thus, access is quick and easy.
The Performance Aspect
The lack of a need to “find things in your file cabinet” provides us efficiencies. In the code context, we have fewer abstraction layers to dig through for a value or function. Everything is readily available to the code, and permissions are a non-issue. This configuration provides for improved performance. Think of it as the best way to get something done is to do it yourself. Some developers see it as getting a task done quickly rather than creating classes to break the task into smaller pieces.
Power In Simplicity
There is power, as well as beauty, in simplicity. The product lines of Apple are a commercial example of this concept. We can remove a lot of time and decision points by limiting options. In the cohesion context, this comes from us knowing where a property or method belongs. We also spend less time worrying about what we should be able to see an attribute or method. When we take this to an extreme, we can see a near return to the old single file, functional approach to designing a software solution. We get to focus on functions over where they “live.” When the solution is small, this all will make complete sense. Why complicate a solution needlessly?
