When we get to the end of our use of a class instance, we need to clean up after ourselves.  This is where destructors come into play.  They are similar to constructors in a mirror fashion.  While a constructor creates an instance, a destructor removes an instance. Destructors And Resource Release Many languages have a default destructor, much as they have a default constructor.  These methods likely free up some pointers behind the scenes.  However, we also have resources and properties or even notifications that may be needed as part of this process.  That leads us to a process that effectively undoes the creation and initialization steps.  We first release resources (reverse the initialization).  Then we remove the instance from... Read more

When we create an instance of a class, we often need to do some initialization.  Constructors and initializers achieve this goal.  These are two different ways to get our data into an instance and are an essential part of our design.  In this episode, we examine the design decisions we need to make as we decide how to use these common methods. Constructors And Initializers – The Distinction A constructor and an initializer method can be thought of in very similar ways.  However, there is one particular trait that differs between the two approaches.  A constructor returns an instance of a class, whereas an initializer sets values on an instance.  This may seem to be a minor difference.  It is... Read more

In this episode, we look at how to use static attributes and methods in our class design. These are important but can be over-used.  They can even be a supported way to break the object-oriented nature of our program.  We can “static” our way into a design that can not be extended.  Therefore, we need to use these sparingly and with consideration about how they may limit our solution. Static Attributes It always helps to set the stage for these types of discussions.  Static attributes and methods are not supported by all languages, nor is that always the proper terminology.  For our purposes, a “static” is a class level value or function.  Thus, there is only one version of these... Read more

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

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