OOP — The Power of Objects

For some, including developers that are developing traditional applications with traditional languages, Object-Oriented Programming (OOP) is just programming with classes, or in our case, function blocks. OOP can be described as a paradigm. OOP is a way of doing things, not just programming with classes. Though classes or function blocks are the backbone of object-oriented programs, there are many principles and features that govern the paradigm.

Compared to the last few chapters, the concepts in this chapter are going to be much more abstract. If you are a traditional PLC programmer who has only worked with basic structured text and ladder logic, the concepts in this chapter will seem difficult to understand and, at times, counterproductive. However, these concepts will help you produce quality, maintainable code. Whereas the last few chapters have been about organizing code, this chapter is about the concepts that govern the design of properly...

Technical requirements

Though we are dealing with complex programming, there are no extra plugins needed to follow along with the examples. As usual, to follow along, you will need a copy of CODEYSYS installed on your computer. The code for the examples can be found at the following GitHub URL: https://github.com/PacktPublishing/Mastering-PLC-programming/tree/master/Chapter%207.

Understanding access specifiers

Until this point, all of our methods have used a public access specifier. Multiple other access specifiers can be used that allow different levels of access to function block attributes. In terms of what we have been using thus far, the public access specifier means that any file from anywhere in the program can access the attribute as long as it has access to an object variable that references the function block.

Generally, you want as few public attributes as possible. The only reason we have been setting our methods to public is for the sole sake of example. In OOP, you want your attributes to be as hidden as possible. In other words, the fewer files that can access a function block, the better off your program will be. Essentially, by properly hiding attributes, your program will be easier to maintain, with less possibility of code corruption. This is a concept that we will explore when we look at abstraction in the following section.

For now...

Exploring the pillars of OOP

Depending on who you talk to, OOP is governed by four pillars: encapsulation, abstraction, inheritance, and polymorphism. Some sources will cite only three pillars due to some developers grouping abstraction and encapsulation as a singular concept. Academia usually teaches that there are four pillars, and it is more common to hear about four pillars as opposed to three. For this book, we will explore the four pillars.

Encapsulation versus abstraction

In OOP, we want to hide as many of the attributes as possible. We do this so attributes outside of the function block can’t accidentally use them and cause issues. This will make the program easier to troubleshoot and maintain in the long run. However, there are some attributes that do have to be used by outside attributes. In this case, we need to provide the bare minimum to the outside function blocks, that is, we need to expose only as much as is needed of the process outside of the function...

Inheritance versus composition

Inheritance is a very important concept and is, without a doubt, a great way to recycle code under the right circumstances. However, many new or inexperienced programmers will often use inheritance as a means of importing code. This is a bad practice because instead of producing clean organized code, they produce jumbled-up code that has no true relationship between function blocks. When developing object-oriented code, it is very important to consider the relationships between function blocks. One very common way to implement object-oriented relationships is with a concept known as composition.

When to use composition

For many inexperienced, traditional programmers, composition is often an ill-understood but, ironically, often-used concept. Composition is where you include object references from one function block in another. In other words, composition allows us to assemble things. Whereas inheritance consists of an is a relationship between functions...

Examining interfaces

If you read a textbook on a traditional language such as Java or C#, you will see that interfaces are often referred to as contracts. When you opt to use an interface, you are telling CODESYS that you agree to, at the very least, implement all the methods prototyped in the interface. However, in my opinion, this is a little confusing.

Generally, when I describe an interface to a new programmer, I usually describe them as a model for something. For example, if we are building an airplane, we will need certain things such as wings, an engine, and a cockpit regardless of whether we are building a prop plane or an F-35 jet fighter. Obviously, for each type of plane, these parts are going to be different. As such, when we implement an interface, we are telling our function block that we are going to use the methods that are declared in the interface but those methods may have different implementations.

To demonstrate how an interface works, let’s implement...

Getting to know design patterns

Design patterns are solutions to common problems. You will mostly see design patterns in OOP to solve a wide variety of problems such as adding abstraction to method calls, creating single object references, and others. If you have a web development background, you may be familiar with the MVC design pattern, or the MVVM pattern if you’ve developed WPF applications in the past; however, there are many other patterns. Outside of the MVC and MVVM patterns, common patterns are as follows:

• Singleton
• Factory
• Builder
• Facade

Each one of these patterns has a different purpose and solves different problems. Whole books are dedicated to patterns; however, as an automation programmer, the one pattern that I used to gravitate to the most was the facade pattern.

The facade pattern is one of the most powerful patterns an automation programmer can use. In automation programming, doing things as simple as turning a machine on or...

Final project – creating a simulated assembly line

Our final project will consist of a production line. The line will consist of a function block for a facade and another function block that will have the following methods:

• Turn on the motors
• Home the motors
• Start the motors

The first thing that we will want to do is create the mentioned methods with an access specifier of Public and a return type of BOOL. Once that is done, create a GVL called outputs and set the following variables:

{attribute 'qualified_only'}
VAR_GLOBAL
     motorState  : WSTRING;
     startMotors : BOOL;
     MotorsOn    : BOOL;
END_VAR

The HomeMotor method will consist of the following:

outputs.motorState := "motors homed";

The StartMotors method will consist of the following:

outputs.startMotors := TRUE;

Finally, the TurnMotorsOn method will...

Summary

This chapter has explored the more advanced features of OOP. OOP is a very powerful and new concept in the PLC world. When fully embraced and mastered, your complex project can become greatly simplified. As you become more familiar with OOP and the associated pillars, you will have no redundant code and will have a very maintainable codebase. As you master these concepts and learn how to integrate patterns into your code, you will be able to do more with less code.

Now, that we have a grasp of OOP, we can focus on creating portable code projects that can be used in many different projects.

Questions

Answer the following questions based on what you've learned in this chapter. Cross-check your answers with those provided at the end of the book, under Assessments.

1. List the four pillars of OOP.
2. Is there a limit on the number of interfaces you can implement?
3. How many function blocks can you inherit from?
4. What is the difference between Private and Public?

Further reading

Have a look at the following resources to further your knowledge:

• CODESYS interface documentation: https://help.codesys.com/api-content/2/codesys/3.5.12.0/en/_cds_obj_interface/
• CODESYS object methods: https://help.codesys.com/api-content/2/codesys/3.5.13.0/en/_cds_obj_method/#e4507ebe4233ac0c0a8640e00a37b12-id-3375759d0dd23b38c0a864630d4cd159