Forem: Matt Moll

Object-Oriented Programming Fundamentals

Matt Moll — Wed, 23 Sep 2020 02:45:09 +0000

Object-Oriented Programming Fundamentals are key to all modern Software Developer. In this article, you will learn all the basics and some complex topics about them. If you prefer a more visual format here is a short video that covers all the topics:

Learn Object-Oriented Programming

Let's start with the definitions of the basic constructs of the paradigm: Object, Message, and Methods.

Object, Message, and Methods

An object is an entity, a representation of a concept. We create a model using objects and their interactions. They don´t necessarily have to be real objects, they can be conceptual. For example, if I owe money to someone that’s a debt, and it can be an object in our model even if it isn’t a tangible object in the real world.

The way objects interact between themselves is through messages. To send a message to an object first I need to know it. That will be done through references but we will touch base with that topic later on. Then, I need to know which messages the object understands, what can it do, I don´t care how it does it, but what it is capable of doing. For example, I know my cat can eat, play with cables, and purr, If I were to build a model of my cat those would be the messages the object would understand.

Then the object has definitions for every message it can receive, that is a method. You can think of it as a function or procedure if you are familiar with other paradigms. Basically, it is which actions to take to resolve the message received.

Let’s talk about how we know objects and how to handle state.

References, State and Properties

A reference is the way we know and access an object. It is basically a memory address that points to said object if we want to go low-level. Once you have a reference to an object you can send messages to it.

The state of an object is composed of all the attributes it has. This state can change over time or be constant. For example, if we have an object CoffeeCup its state could be its color, it’s capacity, and whether it is filled with coffee or not. Clearly its color and capacity won´t change over time, but whether or not it is filled with our delicious coffee will.

An object has properties as a way to let others access its state. Properties offer a get and a set method to retrieve a value or set it. It is the responsibility of the object to determine how it will offer these properties as an interface to its state to ensure correct and expected behavior. Following the previous example for our coffeeCup we would have a get property to show our beautiful color and to let the consumer know our capacity but we won´t allow them to set these values. Unlike filledWithCoffee which will offer a get and a set method to allow the consumer to change this value unless we want to tie this change of state to other actions, but that is a topic for another video!

Encapsulation, Scope, and Interfaces

The first fundamental pillar of Object-oriented programming is Encapsulation, so let’s talk about it. Encapsulation is the principle of making every object owner and responsible for its own state. Basically, we shouldn’t expose our state and allow others to modify it as they want. Instead, what this principle reinforces is to really think hard and come up with the minimum number of messages that our object has to understand and expose to the consumers. Of course, with those messages our object has to be able to maintain its own state and be useful, otherwise, this does not make any sense. There is no point in using Object-oriented programming and then making all our attributes public and allow consumers to change all our state without any validation or restriction.

Our next topic is scope. The scope is basically the reach level a variable or a property has. If you are inside of a method in your object all the variables you create In there can only be used inside of the said method. If you instead define a variable or attribute at the object level then it will be usable from all the methods of your object. Another branch of scope is for your property accessors, you can define from where can be accessed your properties in most languages. Some options here are private, public, and protected. Keep in mind you can control who can access those properties to help you out with the encapsulation of your object.

Lastly, we want to talk about interfaces. The interface of an object is the set of all the messages it can understand. This is very important and very powerful because we will later learn about the benefits of having different objects having the same interface and how that allows us to design and develop better solutions. It is worth mentioning that in typed languages like C#, Java, or typescript an Interface is an even stronger concept since it obliges to implement methods definitions for all the messages described in an interface, it is more like a contract.

Now its finally time to talk about how to create our precious objects.

Classes and Constructors

Classes are one of the most important concepts and construct of object-oriented programming. The idea is simple, a class is a blueprint for creating objects. In a class we will define all the properties we want our objects to have (its state) and all the messages it will understand with its corresponding implementation (methods). For example, I have 3 cats in my house. If I want to model this in an Object-oriented program, I would write a class Cat and then create 3 instances of the said class to have 3 objects, one for each cat. The class Cat would have properties like the age and the color and methods like eat, sleep, and purr. Then I would be able to interact with all my beautiful cats through those messages!

The next big topic is Constructor. A constructor is a unique and special method that every class has to define, that’s because the constructor has the definition of how an object of its class is created. In most languages, if you don’t provide a constructor your class would have one by default that doesn’t do anything specific for your class. Basically in this method, you would put any logic that is necessary for an object to be created and get a valid state. For example, if you remember our cute coffee cup, in the constructor of it we would ask for the color of the cup and its capacity.

This is because we cannot create a cup without knowing its color and capacity, it doesn’t make any sense, and we could also default the value of filledWithCoffee to false since we just created the cup. Later on, the consumer of the object would be able to get the color and capacity and get or modify the value of filledWithCoffee.

Inheritance, self & super and Method lookup

Inheritance is the second fundamental pillar of Object-oriented programming. The idea is to create class hierarchies based on the relationship of “is a”. For example: if we want to model payments, we could have a Check class and an Electronic Fund Transfer class, both would inherit from a payment class. Both a check and an EFT are payments, but they are different from one another and will probably have different states and behavior while also sharing some characteristics and an interface. We say that the class payment is a superclass and the ones that inherit from it are subclasses.

With this in mind, we have to start thinking about how are we going to handle context, because now when we are inside of a class I have access to properties and methods that are inside of my class but also in my superclass (and the superclass of the superclass and so on). The standard way to solve this is to have a keyword to reference its own context, that would be this or self in most languages, and another keyword to access things in the context of my superclass and that would be super or base.

Now, let's move to Method lookup. Now we have hierarchies and when an object receives a message it has to look for the definition of a method with a signature that matches this message, potentially, in all the hierarchy. The process of finding this definition is called method lookup and it is basically from the bottom up. We will start on the class of the instance that received the message and if there is no definition in this class it will go and search in its superclass and so on until it finds a definition or reaches the end of the hierarchy in which case it would produce an exception.

Design Diagrams (UML)

Something great about Object-oriented Programming is that it allows us to convey ideas through objects and class diagrams. By now you should be comfortable thinking about classes and objects, so lets put them on paper with a set of rules and standard drawings known as UML. UML is Unified Modeling Language and its purpose is to give us tools to share design and put ideas down to earth without having to code everything.

UML Standard Object diagrams can be somewhat easily confused with class diagrams that’s why I have found a pseudo standard that fits better. In this variation, an object will be drawn as a circle with a name and the attributes we want to have in it linked to other objects through references. A reference will be drawn as an arrow. With this, we can create object graphs to visualize relationships and a possible scenario with a given state for our system.

Then we have the class diagrams. For classes we will use rectangles, with the name on top, then a section for attributes, and lastly a section for methods. This can be as detailed or as abstract as the diagram needs. Usually, it is better to only put what is really necessary and leave details for later when we want to implement this. But on occasions, we might want to have a clear full interface for an important class. We will connect classes that have a reference to another class with an arrow filled. And we will draw relationships of inheritance with an arrowhead empty. This way we can create complex designs with hierarchies and references between classes in a visual and convenient way.

That will be all for this full article on Object-Oriented Programming Fundamentals! To get more of this content subscribe to my Youtube channel here.

The Social Dilemma, a wake-up call to society

Matt Moll — Thu, 17 Sep 2020 03:19:55 +0000

Today, I want to encourage you to take the time and watch the latest documentary on Netflix: The Social Dilemma. If you ever wondered whether or not AI was going to take on, how social media affects the youth, or the impact of fake news and polarization in our society, this movie is for you.

Review and Reflection

Before I quickly summarize the most important topics that the movie cover, if you want to watch my full review and take on this documentary, you can watch my video here:

A wake up call

The movie is presented in an interview-like fashion, with several experts from the top of the hierarchy of some of the most important companies in the industry raising their concerns and sharing valuable insights. This gives the documentary authority over the topic and separates it from being just a fictional or over-exageration presentation of the topic, which has happened before.

The main topics that are covered in the movie are:

How powerful the social nets are and how much data and efficient models they have of every user.
Their motivations and how they study, plan and develop strategies to maximize the time you spend on their products to monetize you.
The psychological impact this all has on individuals, and particularly in teenagers and children.
The consequences of fake news and polarization that we already see on society today.

All these topics and more are covered both from an interview base format and through the storyline of a family that is impacted in different ways from social media and its ramifications.

If you, like myself, think these are very important topics both for us as individuals and as members of society I would encourage you to take the time, watch the movie (its only 1:30 hrs) and reflect on it. After that, you can see how you feel about it and which actions you can take to minimize the negative impacts that social media has on you.

Thanks for reading and I will see you in the next article!

Design Patterns - The holy grail?

Matt Moll — Mon, 24 Aug 2020 01:18:09 +0000

In this article I will present to you the concept of Design Patters, why were they created, which problems they solve, and how YOU can be a better developer if you learn about them. Let´s get started!

What is a Design Pattern?

Let´s see some "formal" definitions from my favorite book about this topic (Design Patterns: Elements of Reusable Object‑Oriented):

"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice". Later on, they say that every pattern has 4 essential elements: A name, a description of the problem it solves, the solution itself, and the consequences.

If we look online for another definition to not rely only on one source we can find something like this: "In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. Rather, it is a description or template for how to solve a problem that can be used in many different situations."

OK, so with those definitions in mind, let's do a summary more down to earth and easy to understand. Design patterns are solutions for repetitive problems we find while developing software. Each pattern has a name for reference, the problem for which it should be applied, and a high-level solution that you have to adapt and implement to your system.

GREAT! You already have an idea of what a Design Pattern is. Before moving on I want to recommend you read the whole book because it is a great lecture and you will learn so much from it.

The book is: Design Patterns Elements of Reusable Object‑Oriented from Gamma, Helm, Johnson and Vlissides

Why do we need Design Patterns?

The short answer is to make our life easier. A more explanatory answer is to avoid losing time re-inventing the wheel and discussing how to solve problems that are well documented and have standardized and proven solutions.

Why should YOU invest time learning them and/or teaching them to your team? Because it adds another level of abstraction. Once you have a team of devs that know Design patterns you will be able to talk about problems and solutions at a higher level of Software design. You don´t have to go to low-level design details like: "We will need a superclass for the standard behavior of clientsDebt and then subclasses for each type of client with its particular logic and compose that to our client class" instead you can just say: "Here, for calculating clients debt we will implement a strategy" and everyone will have in mind what that means without going into details, and there is also almost no space for misconceptions or errors in translating that design idea to implementation. This saves time, analysis, complexity, and will also make your solution cleaner and more scalable if the patterns are applied correctly of course.

How to learn Design Patterns?

I hope by this point you already see the great value that Design Patterns can add to you so the next logical step is to learn them. Of course, I won´t be able to do a summary of a 400 pages book in 1 article but I will give you some introduction here and pointers so you can dig deeper into this fascinating topic.

Design patterns can be classified into 3 classes:

Creational Patterns: They are used to abstract the instantiation process. They make a system independent of how its objects are created, composed, and represented.
Structural Patterns: These are concerned with how classes and objects are composed to form larger structures. They add flexibility and are great for making independently developed libraries work together.
Behavioral Patterns: The last category is concerned with algorithms and the assignment of responsibilities between objects. These not only focus on objects or classes but also the patterns to communicate them. They are characterized by complex control flow that´s difficult to follow on run-time.

Now we can go through a list of the design patterns I like the most with a short definition and use cases. You can use this as a guide to see which design patterns you find the most useful to then dig up a little and fully understand them and hopefully implement them very soon ;)!

My 8 favorite Design Patterns for starters

Builder (Creational)

Separates and encapsulates the construction of a complex object. Builders will expose the different steps to create said complex object and each builder type will have its specific configuration. Reduces coupling, centralizes and isolates the construction code, only when all the steps are done the user can access the final built product.

Singleton (Creational)

Ensures a class only has one instance. Provides a global point to access it. This one is "easy" commonly used and some consider it an anti-pattern (not good practice). Be aware of it!

Adapter (Creational)

Converts the interface of a class into a new interface that matches what a client object expects. It allows classes to work together that otherwise couldn´t because of incompatible interfaces.

Decorator (Structural)

Attachs additional responsibilities, features (decorators) to an object dynamically. It allows us to add functionality to objects without having access to their class definitions. This pattern is a little complex but helps you a lot to get your head around patterns in general and complex designs. Please give it a read and try implementing it!

Proxy (Structural)

Provides a placeholder for another object to control access to it. It´s like a middleman that will provide access to another object by passing the message to it. This pattern allows us to defer the cost of the creation of an object, encapsulate some validations and other similar use cases.

Command (Behavioral)

Encapsulates requests or actions (commands) as objects, letting you parameterized clients with different requests, defer the moment of creation from the moment of execution of said actions and support undoable operations.

Observer (Behavioral)

Defines a model with an observable object and interested observers and when the state of the observable changes all the observers are notified of said change to take action.

Strategy (Behavioral)

Defines a family of algorithms, encapsulate each one, and make them interchangeable by having a common interface to the client. This is my favorite pattern for starters, it has many many use cases and improves your code a lot. Please give it a try!

To learn more about these patterns or all the others that developers and designers use, go ahead and search in Google/Youtube for more details or read the recommended book. But most importantly don´t only watch and read, APPLY IT. The pattern will fully click in your brain once you implement it and see it working.

That will be it for this article, I hope you liked it and learned a couple of things. Let me know if you enjoyed it and would like me to go into further details about this topic. You can also connect with me on Twitter where I´m active every day producing programming-related content. Thanks for reading!