98 episodes

This podcast is for aspiring entrepreneurs and those that want to become a designer and implementor of great software solutions. We look at the whole skill set that makes a great developer. This includes tech skills, business and entrepreneurial skills, and life-hacking so you have the time to get the job done while still enjoying life,

Develpreneur: Become a Better Developer and Entrepreneu‪r‬ Rob Broadhead

    • Technology
    • 5.0 • 1 Rating

This podcast is for aspiring entrepreneurs and those that want to become a designer and implementor of great software solutions. We look at the whole skill set that makes a great developer. This includes tech skills, business and entrepreneurial skills, and life-hacking so you have the time to get the job done while still enjoying life,

    Polymorphism Without Side Effects - Object-Oriented Clarity

    Polymorphism Without Side Effects - Object-Oriented Clarity

    We discussed in the previous episode how polymorphic behavior gives us a form of a common language for objects.  Thus we need to consider the idea of polymorphism without side effects, so we have clear and concise commands.  There is also a consistency required for this to be an approach that is truly useful.
    What Is Polymorphism Without Side Effects As always, we should start with a definition of terms.  In this case, our goal is clarity.  Polymorphism is a way to give a command each object responds to.  That means there should be similar results for each one.  As an example, if I tell several people to "get the mail," I should be able to assume they either check a physical mailbox or maybe an electronic one.  I should not have some people make me lunch or pay the bills as part of that command.

    The Danger of Intent
    This challenge revolves around intent.  In our mail example, there are logical assumptions that can be made.  These include scope and other restrictions.  When I ask someone to get the mail, it implies a one-time task and not something that will be done forever.  Likewise, it does not generally imply sending mail at the same time (or paying bills).  These unintended consequences can be described as side-effects.  They can be confusing and even damaging.

    The Power of Clarity
    We will look at several good habits that make object-oriented programming work well.  Clarity and consistency are two of these.  When we use the same command for different work, it becomes confusing and impacts the user experience.  Instead, we should aim for polymorphism without side effects by clearly defining actions and publicly visible properties.  We can do this by adding context (e.g., printToScreen, printToFile) or other descriptive terms (e.g. printAsXML, printAsJSON)

     

    • 14 min
    Polymorphism Overview - Reducing code size and a better user experience

    Polymorphism Overview - Reducing code size and a better user experience

    We start the next series of episodes with a polymorphism overview.  This is a core concept for proper object-oriented design.  Likewise, we will dig into several practical ways to use this.
    Polymorphism Overview - A Definition As with many topics, it seems best to start with a definition from Wikipedia.
    In programming languages and type theory, polymorphism is the provision of a single interface to entities of different types or the use of a single symbol to represent multiple different types. For our purposes, that symbol that is referred to can be considered a name.  The name can be a method, class, or property name.
    Class Vs. Object It is worth clarifying the difference between a class and an object.  We will be talking about these two terms a lot from here on out.  Therefore, let's remove any confusion.  A Class is the definition of a class.  Think of it as a set of rules or a template.  A simple pseudo-code example is below.
    Class MyExample { String name; String value; public whoAmI() { return this.name; } }

    An object or instance is an occurrence of a class.  In the example below, myPointer is an object (or instance) of the class MyExample.  These are simple examples.  However, the concept is simple.  In the real world, an example would be that there is a class called Mother, and your mom is an instance of that class.
    myPointer = new MyExample(); The General Concept And Examples Since this is a polymorphism overview, we now need to talk about examples.  In general, polymorphism allows us to provide commands to objects they can follow for their specific case.  We have examples of this throughout the real world via commands we give and questions we ask. 
    We can look at the request "tell me about yourself" as an example.  The response may be a name, a profession, a season of life, an entire life story, or countless other responses.  In this case, the object the person you are talking to will take that request and polymorphically respond.  It is polymorphic because the same command is understandable by each of us.  However, we will have different responses due to our personality (or class).
    In the code world, a command like this may be "save" or "print" or myriad other commands.  These allow us to "tell" a group of objects the same command and have each respond in a pertinent way. 

    • 14 min
    Data Hiding - Practical Accessors

    Data Hiding - Practical Accessors

    We have discussed the accessor levels of our data.  In most environments, the three levels are public, protected, and private.  In this episode, we go deeper into these concepts and a practical approach to data hiding.
    The Private Access Level This level of access should be our default.  It can be considered the critical step in data hiding.  Private hides our data and methods.  I find a physical example often works best for the goal of this approach.  When we purchase a physical device, we prefer fewer buttons and interface widgets over more.  The Apple iPod was a perfect example of this.  There were very few controls, so the interface was easy to understand.  Our software should follow the same principle of less is more.  When we do so, we keep things simple and avoid paralysis from providing too many options.


    Protected Access

    A well-designed object-oriented system will have helpers and relationships among objects.  Therefore, it requires an object to be able to modify values or have access to internal methods directly.  These are often "administrative" actions that we do not need to provide to the general public.  However, they are needed for classes to embrace all that their definition requires. 
    This situation most often shows up in inherited classes.  An object that is a subtype will still need to access core items.  This does not require a change to attributes.  We can keep those private while providing protected access via methods.  That is often the better approach as it allows us to make sweeping changes to a system via core classes without rewriting the children and helpers.


    No Data Hiding - Public Access

    The most open level of access is public.  This should be rare in most systems and well-defined.  A user should be able to understand the direct and ancillary impact of calling a public method.  Likewise, it should rarely have anything other than a direct impact on an object.  The simple interface is always the best approach.


     

    • 13 min
    A Practical Approach to Data Encapsulation

    A Practical Approach to Data Encapsulation

    We have developed many bad habits over the years as OOP has proliferated frameworks and tools.  In this episode, we look at the practical side of data encapsulation and access levels like private, protected, and public.


    Tools Are A Beginning

    Modern frameworks and tools provide ways to generate a general object-oriented solution quickly.  Therefore, the tools will give us a start, but not the best solution.  There are too many details the tools are not privy to that are essential to the best solution.  We will make the best use of tools when we remember this fact.  That means we can not only move forward with generated code.  We must review what is provided and extend or remove details to fit our needs.
    A perfect example of tools being a less-than-perfect fit is in data hiding.  There are general assumptions made for accessors like getters and setters that should be refined.  A solution does not know that you have a read-only property or one that should not be directly passed through on a request.


    Data Encapsulation in a Nutshell

    The goal of data encapsulation is for us to provide a form of just-in-time access to data within our system.  This approach can also be viewed as making attributes and methods available on a need-to-know (or need-to-use) basis.  Once we expose a method or value, we can not undo that.  There are plenty of examples in frameworks where a feature or value is deprecated.  That occurs when something was exposed that now should not be.  Thus, the author is warning users that the deprecated element will be disappearing in the future.  An ideal approach would be not to expose that feature in the first place.


     

    • 15 min
    Data Hiding - A Need To Know Software Approach

    Data Hiding - A Need To Know Software Approach

    Data encapsulation and data hiding are terms for keeping object properties from public consumption.  This concept is an essential part of object-oriented programming.  We need to be able to have internal processes and values that we can change without impacting users.  It also allows us to limit the impact of changes in large systems.  Thus, we will start our OOP season with a look at this somewhat simple concept.


    Data Hiding is more than properties.

    One important facet of this topic is that we use encapsulation for more than attributes or properties.  That may not be obvious in the frameworks you use.  Therefore, we need to look at these expanded options for encapsulation.  We also can use this as an opportunity for expanding on object-oriented design. The core point I want to make is that a method and a property are rough equivalents in the OOP world.  We (the consumer) make a request, possibly include parameters, and then expect a result.  When we deal with a property, we say, "give me that property."  A method is roughly "give me that calculated value."  Consider the case where there is no calculation required.  Thus, we have the idea of "getters" and "setters."  These are often simple passthrough functions.


    Expanding Complexity

    Now we have stumbled on why data encapsulation is useful.  Consider an attribute, a date, for example.  There are numerous Date formats and permutations.  We can include a time (or not), consider day or week (or not), and other options.  Thus, a method of getDate() can quickly evolve from returning a string of "Monday" to "2/3/2019" to "2/3/2019 08:33".  While the caller may want to handle those results differently, they do not want to change their code every time you change the underlying data type.  That means you may start with getDate() returning "Monday" and then can later store it as a date and add a getFullDate() method that returns a YYYY-MM-DD format for that same variable.


    Data Hiding in Practice

    The best way to think about data encapsulation is using a "need to know" approach.  There is no implicit benefit in exposing an implementation detail like a property type or helper method.  Therefore, please do not provide a public interface unless it is needed for consumers.  Otherwise, you are effectively providing users enough rope to hang themselves.  That will lead to them being unhappy when you are forced to change your internal design.

    • 13 min
    An Introduction to The Object-Oriented Programming Season

    An Introduction to The Object-Oriented Programming Season

    Object-Oriented Programming (OOP) and related concepts have become almost ubiquitous in modern software projects. It was a novel idea a few decades ago that has been incorporated into many frameworks and languages. We even have situations where OOP was "bolted on" to existing systems. However, all of that out of the box OOP design can hide it from us and keep us from fully embracing it. Therefore, this season will start from the OOP foundations and point to ways to embrace it in an intentional rather than accidental way.


    Avoid Duplication of Effort

    Software development is all about solving problems. The more we solve, the better we can serve our audience or customers. Thus, we want to avoid answering the same question multiple times. It is a waste of effort and a negative impact on maintenance. It can even hurt scalability. That is one of the core reasons for an object-oriented approach. The goal is to keep solutions contained in a way that makes them easy to re-use. Think of Lego blocks and how they can easily be connected to build small or large objects or even systems.


    A Model of The Real World

    The objects part of object-oriented programming are ways to model the real world. We can take problems defined in real-world terms and map them to a series of objects. Thus, an ATM solution can become a collection of customer, transaction, and bank account objects. This approach makes it easier to communicate ideas and break a considerable challenge down into smaller problems that are easier to solve.


    Practical Object-Oriented Programming

    OOP is a theory at its core. That means there are many ways to embrace it and put it into practice. Our goal for this season is to point to ways to use OOP concepts every day but can do so better. We will look at how to find a balance between theory and putting these ideas into action. If we have a better understanding of OOP along the way, then that is even better.

    • 13 min

Customer Reviews

5.0 out of 5
1 Rating

1 Rating

Goodman615 ,

Great advice.

I started a boot camp a couple months ago and found this podcast to listen to at my job when I’m not able to code. Even though I’m new this podcast is easy to follow and has some great advice. Thanks!

Top Podcasts In Technology

Listeners Also Subscribed To