Develpreneur: Become a Better Developer and Entrepreneur

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)  

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. 

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.  

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.  

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.

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.

We decided that it is a good idea to start a new year with a habit building challenge.  Therefore, we have created exactly that.  The objective of this challenge is to pick something you will work on every day.  The something you work on should be do-able in fifteen minutes or less.  After twenty-one days, a new habit should be established, and your year off to a successful start.  The idea of 21 days guaranteeing a habit may be a myth.  However, this is a solid start on that goal. A New-Year Resolution That Sticks We often talk about using natural transition times to launch a new idea or product. There is no better time like this than the new year. As part of our turning the corner into 2021, we have come up with the 21-day challenge. It is simple, free, and may change your business or even your life. The Habit Building Challenge The basis for 21 days is to build a habit. We like to focus on turning the small into something big so here are the ground rules. Be ready to start on January 1st. You can start later, but why wait? Select a goal for your year ahead, it may be a New Year’s Resolution, or maybe it is a skill or product you want to tackle in the year ahead. Create a plan to work on that skill or goal 15 minutes a day. That is all, no more, preferably no less. Also, this will be for 21 days straight. You are not going to take weekends off. Repeat for 21 days. We will send an email each day to help “remind” you of the challenge. Send us an email at Develpreneur.com with your goal if you would like a more personal daily update. You can even ask to stay anonymous, and we will use the goal to help others with a plan. Food For Thought If you need an idea, here are some to get you started. Learn a new spoken language (try Duolingo for 15 minutes/day) Start a blog (write 15 minutes a day) Start a podcast (record yourself or outline topics each day) Get healthy (walk, jog, or exercise 15 minutes a day) Find balance (meditate or pray 15 minutes a day) Learn a new code language or library (15 minutes a day coding in that tool) Become a better leader (spend time reading or listening to leadership content) Learn a skill (juggle, cook, sleight of hand, etc. practice 15 minutes a day) All suggestions are welcome if you want to add them to our list of items for the habit building challenge!

Sooner or later, a task we work on will reach successful completion.  That is the goal, and yes, sometimes (hopefully often) we do achieve goals.  There is value in resting in that success for a time.  However, time marches on, and we need to plan for our next goal or goals. Damage Assessment We often have a push near the end of a goal that earns us that successful completion.  It is useful to assess the damage done in that final push.  We may be tired and need a little time to recover.  On the other hand, we might have burned ourselves out, achieving that goal.  Likewise, this is the best time to measure whether the cost was worth the achievement.  These thoughts are essential in determining whether we build on this victory or decide to move on to something different. The Momentum Is There We often talk about the momentum we build in moving towards a goal.  This impact is seen in losing the wind in our sails once we hit a goal that we pushed hard to achieve.  I liken this to Christmas morning right after gifts are all open.  There was a push (and anticipation) for weeks built up to that moment that just passed.  That often leaves us with a "now what" feeling.  It is not so much negative sentiment as it is a vacuum left where we have momentum without direction.  An excellent physical example is a drag racer that crosses the finish line and pops the parachute. A Gentle Transition or Total Pivot The momentum, drive, or general energy that got us across the finish line can be exhausted.  We just barely got across the finish line.  The momentum died at that moment.  In those cases, we should rest and spend a little more time evaluating where to go next.  However, the cases where we have momentum provide us energy after a successful completion that can be used for our next objective. We need to assess where to go next while being aware that we have excess energy to jumpstart our next endeavor.  Therefore, we will be further along the road to our next goal if we work with that momentum.  Likewise, it will take an effort to redirect the momentum if we go in a completely different direction.

It is not hard to find a movie or show during the holidays that shows the weight of waiting until the last minute to get things done.  It often is shown in terms of delaying your gift purchases.  However, we can see other examples of how challenges impact when we are already spread thin.  We feel the pain of unexpected events much more when we have a full schedule than when we have some buffer built-in. Working Well Under Pressure These examples can be applied to all areas of our life.  Nevertheless, many of us work better under pressure.  Or at least we claim to do so.  There is a burst of energy we get when under pressure.  This chemical rush can help us get across a finish line.  On the other hand, it is easier to get derailed when you have little room for failure.  There is also a sense in many cases that people who claim to work better under pressure are similar to those that claim to drive better after a little alcohol. Heavier Obstacles Add To The Weight of Waiting I am not immune to the idea of getting to "crunch time" and knocking a task out at the last minute.  Thus, I know that the little things that are more common than we would like are more impactful during these times.  For example, think of a child asking questions as they tend to do.  This distraction can easily be taken in stride when we have no deadlines weighing heavy.  However, this same behavior may incite a gruff response when a deadline is imminent. There are even impossible situations that can arise.  We all have had that project that requires a certain item or materials that are readily available.  Yet, when we get to that crunch time, we cannot get access to the needed items.  I can think of times when all I needed was an inch of scotch tape and could not find any.  It was also late, so the stores I could have gone to for the tape were all closed. Planning Over Scrambling These examples lead us back to getting better in many ways.  This concept is not just for improving as a developer.  It goes to being able to get more done regularly—plan for your tasks.  Consider what items or people might be required to get that done.  Let them know, get your needed materials.  Your blood pressure will thank you.  That means we need to be more intentional about starting tasks.  When we know something needs to be done, we should spend a little time (at least) thinking about the requirements.  There are related items we might need to set in motion.  Also, we might see opportunities to advance multiple tasks simultaneously, much like the kill two birds with one stone concept.

We have calendars full of tasks and items to be done.  However, we must take time and celebrate achievements.  Whether we have successes daily or rarely, it is worth our time to revel in the positive feelings from a job well done.  No time is better for this bit of "self-indulgence" than year-end review and planning.  Looking forward and planning for the new year is important.  However, we can learn a lot and build confidence by embracing what we accomplished in the prior year. Why We Celebrate Achievements One can argue that getting something done is not worth a celebration.  Do you celebrate brushing your teeth or making your bed?  No, we do not.  However, we could achieve a little boost of positive feelings if we did.  There are plenty of examples in daily life.  We see people achieve something that might seem small to us, but they are drunk with joy. For example, consider the "Rudy" story in youth sports.  There are many instances where a child struggles in a sport.  They are the ones that rarely score or find success.  Think of them as the underdog.  It is not uncommon for the crowd to go wild when these players achieve success.  What would happen if we saw that sort of celebration more often in our lives? Keep It Special Too much of anything is not good.  That includes celebration.  Thus, it would be exhausting to throw a party celebrating every little achievement.  Nevertheless, it is good to mark victories regularly.  This action will help drive us forward and keep up morale.  The challenge is that many of us are so focused on the next problem to solve that we move on from a victory without spending time enjoying it.  A sports example would be a team winning a championship, and they immediately go to practice for the next game.  Sizeable victories are valuable motivational tools, so we need to embrace them. Learning From Past Achievements This podcast (and site) is focused on becoming better developers.  However, motivation is nice but is not a direct path to getting better.  Therefore, we should also look to past victories for examples of future success.  Much of our experience is an exercise in learning what not to do.  I would argue that the vast majority of our time in life is spent working through failures to find success.  That brings us to the value of those rare successes.  It is much faster to reach a destination by knowing where to go instead of where not to go.  That is why success breeds success. It is not self-indulgence to sit in a victory for a while or to relive it during our annual reviews.  Instead, it is an opportunity to highlight direct paths to success that can be used to plan for more of those situations in the year ahead.