develpreneur podcast

Coupling – A Smaller Object Approach To Software Solutions

In object-oriented software, we talk about the concept of coupling.  Put simply; this is a small object approach to our solution.  It is the opposite end of the spectrum from large-object, or monolithic, designs.  In my experience, a developer’s bias towards cohesion or coupling often comes from their background.  Those that have come from functional languages and platforms are more comfortable with cohesion, while those that built components tend to use coupling. Coupling Strengths It is hard not to point to flexibility as a primary strength of this approach.  It stands to reason that the more points of adjustment available, the more flexible the solution.  This example is easy to see in physical objects.  Remove all of the joints in... Read more

develpreneur podcast

Cohesion – A Big Object Approach To Design

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... Read more

develpreneur podcast

Cohesion and Coupling in Object-Oriented Design

Cohesion and coupling are options that are often discussed in object-oriented design circles.  They are two ways to approach a solution.  On the one hand, the solution can be a larger, self-contained approach.  On the other hand, the solution can be a core that uses several “helpers” to achieve the objective(s).  These are important options for us to consider as part of the overall OOD discussion.  In this episode, we start with an overview of these common paths. Cohesion Defined There are many ways to think about Cohesion.  However, I find it best to start with a common form of definition like the one found on Wikipedia. In computer programming, cohesion refers to the degree to which the elements inside... Read more

develpreneur podcast

Property Design In An Object-Oriented System

One of the most prevalent topics of consideration in an object-oriented system is property design.  We can keep them simple or create more classes.  The first approach is simpler and faster to implement.  However, we can use objects to provide hooks we extensibility and scaling out our features.  There are trade-offs to be aware of, but we can use some guidelines to shorten the design process. Property Design Considerations For purposes of this episode, we will look at two paths available.  We can use a simple type (native) or use a class to define a property.  While we can also utilize collections as properties, those still boil down to one of these two paths.  You will either have a collection... Read more

develpreneur podcast

Class Relationships – When Has-A Shows a Relation

Our language can blur the distinctions of class relationships in designing our solution.  The “has-a” determination is often confused by how the English language can translate those words.  We also have to keep a context for assigning a class.  Likewise, reality allows for data to be multiple classes in some cases, so we need to examine how those might be a hierarchy of some sort. Class Relationships – “Have” As A Pointer The confusing aspect of the English language is that we can “have” a relationship and a property.  For example, you have an age, and you have a parent.  The age is a property of being you while the parent is a relationship.  This language blurring of properties can... Read more

develpreneur podcast

Is A and Has A Concepts in Object-Oriented Design

The ideas of “is a” and “has a” are often discussed as part of object-oriented design.  These concepts may seem simple and obvious.  However, they can often be confused, and complex systems can blur the lines between them.  We start a multi-part episode going over these concepts focused on how “is a” relationships work. Is A and Has A Defined These concepts boil down to simple grammar.  For two objects, A and B, here are the options. A is a B if A has all of the traits of B.  For example, a poodle is a dog because a poodle has the traits we equate to a dog.  A dog is not a poodle, as some dogs have traits that... Read more