Coding blocks podcast is presented by Joe Zack, Michael outlaw and Allen Underwood. In this podcast episode, they squad begin by talking about components cohesions in architectural designs. Cohesion in software designing refers to the degree to which the elements inside a module belong together. In one sense, it is a measure of the strength of relationship between the methods and data of a class and some unifying purpose or concept served by that class. In another sense, it is a measure of the strength of relationship between the class’s methods and data themselves. Cohesion is an ordinal type of measurement and is usually classified under two categories, “high cohesion” or “low cohesion”. According to the team, there was a principal known as the fish bowl principal, this was employed in system building and architectural design for so many years. It was believed that the fish would eventually grow to fit the bowl it was placed in. But that has changed over time, with services like AWS and other cloud functionality, developing software of any size is easily manageable. Scalability is often handled by high performance systems that allocate resources to where is it needed most and vise versa when it’s not in demand. A big part of this new trend of software reuse is propelled by the open source project that currently runs the software industry. Building components or software in components also propels this new trend of code reuse. This is because in components, code is built to be self-dependent and sufficient to run on its own. It is viewed as a module that fits a part of the big puzzle. Testing for modules and components do not break the original code as it is tested as a single entity that interacts with the overall project. Another topic that gets discussed by the group is the common closure principal. The common closure principle consists of classes that change for the same reason and at the same time. This is similar to the single responsibility principle. This simply means that if the character of the class is changing, then the component is also gonna change. We need to make sure that the component is only changing for one reason only and if there is more than one reason, then there should be more than one component. Overall, this episode went very in-depth to technical practices and techniques that are used to develop components and architecture in software creation. This level of in-depth was a little too much for what we are studying but I felt it was necessary as it gets us thinking about how to build software in components and parts and start learning how to allocate functionalities to individual components.
Link – Episode 71