Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
We have the aforementioned set of expectations as developers. Those lead us to look at a hierarchy as something that grows as it goes. That means we should extend functionality as we inherit. We should avoid rewriting what the parent does. While we can change or even block behavior in child classes, that is rarely a good design. It is highly frustrating for a developer to have a method available to the parent that is no longer relative (rewritten or unavailable) further down the chain.
Think of each step in the hierarchy as a way to build on the parent features. The base class supplies a foundation. The child classes add to that foundation without impacting what has been built in the prior layers. This approach will help your hierarchy help the developers that use it.
-->Listed in: Technology
The typical methods and functions we have mentioened throughout this season are going to often end up in an interface. We see this in frameworks where there are numerous helper objects in the system. For example, there may be interfaces to save, print, load, export, or compare instances. These consistant interfaces allow us to treat a broad range of disparate objects the same.
One such example would be sorting a list. We all can imagine sorting a list of names. On the other hand, how would we sort a list of cars? We can implement a compare interface in the car class. That can provide a process for comparing two cars and deciding an order to them. Once that has been implemented, we can display a list of cars and provide a sort option.
-->Listed in: Technology
One thing to keep in mind with these hooks that you supply is including restrictions. For example, we can use enumerated types and exceptions to ensure users stick within reason for parameters. This approach allows us to leave room for growth while still requiring code to work within the given framework. We can have a print that takes a parameter for output type that only works when the type is within a collection to enumeration. Then the set of valid options can be extended as needed.
The simplest way to think about this need for some flexibility, but not too much, is as ground rules. There are certain things your code will expect to be available. Thus, exceptions will be thrown when those requirements are not met.
-->Listed in: Technology
Listed in: Technology
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.
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)
-->
Listed in: Technology
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();
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.
-->Listed in: Technology
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.
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.
-->
Listed in: Technology
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.
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.
-->
Listed in: Technology
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.
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.
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.
-->Listed in: Technology
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.
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.
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.
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.
-->Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology
Listed in: Technology