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

develpreneur podcast

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

develpreneur podcast

Inheritance – Polymorphism In A Hierarchical Manner

We switch gears in this episode and start to look at inheritance.  This is a core feature of object-oriented design and the most recognizable attribute.  Child classes are utilized through polymorphic support.  Thus, we have a natural transition into this popular usage of object-oriented solutions. A Lowest Common Denominator We have discussed the idea of building on methods where possible.  When we do, we are creating a lowest common denominator approach to functionality.  This is what makes a system logical in its design.  Whenever a user (developer) uses a method or attribute there are certain things they can expect that are included. For example, when I have “save” methods in classes, the user expects the class supports persistence.  They also... Read more

develpreneur podcast

Interfaces – An Object-Oriented Contract For Usage

This episode, we look at interfaces.  These are not supported by all languages.  However, when they are supported, they are very useful.  The interface specification allows us to provide language-based constraints for our method signatures.  It also is an excellent way to enforce consistancy. Interfaces As A Tool For Consistency The most important result of using interfaces is that they enforce a consistent way to communicate with developers.  Any class that uses one of these items will be forced to comply with the defined signatures.  The language compiler or validations will let the developer know when they are not following the rules.  While there might be empty methods allowed, the developer must specifically handle the method and return an empty... Read more