Advanced Coding — Using SOLID to Make Solid Code

The major downside to OOP is that many think that if they organize their code and stick to using class or function blocks, they’re going to produce excellent software. However, more often than not, this is false. As the old saying goes, “with great power comes great responsibility,” and in terms of OOP, this is true. When writing OOP code, you can often shoot yourself in the foot just as easily as you can produce the next technological wonder. For many, OOP is just programming with classes or, in the case of PLC programming, function blocks. Though concepts such as class/function block relationships do help clean up code, more often than not, inexperienced programmers are just as likely to make a mess out of object-oriented code as they are to develop quality code.

Up until this point, we have explored the power of OOP and how it can allow us to reduce the amount of code that we have to write. However...

Technical requirements

For this chapter, all you will need is a copy of CODESYS installed and working on your machine. The examples for this chapter can be found at the following URL:

https://github.com/PacktPublishing/Mastering-PLC-programming/tree/master/Chapter%2010.

As is standard for this book, you should download the code. Some of the code for this chapter will be a bit different from that of the other chapters. Much of the code in this chapter will be more akin to pseudocode that follows the IEC 61131-3 Structure Text syntax, as much of the code in this chapter will be used to merely demonstrate concepts. However, working examples will be provided, and these examples will either be noted or have screen outputs.

Introducing SOLID programming

When first introduced to SOLID programming, I was incredibly confused about its purpose. My young, inexperienced self simply could not fathom that OOP did not ensure quality code. After all, as long as you’re following proper OOP principles, you should be producing quality code, correct? Well, the answer to that is “Wrong.” Quality code stems from well-architected code. Essentially, a quality program is a program where things can be easily added or removed, bugs can be easily found, and code can be easily changed without the risk of breaking other code. This is where SOLID comes into play. SOLID programming is a set of general rules that, when followed, will drastically improve the quality of your program’s architecture.

So, what is SOLID programming? SOLID programming is a set of five object-oriented design (OOD) principles. SOLID is the brainchild of Rober C. Martin, a.k.a Uncle Bob. In short, Uncle Bob devised five principles...

Benefits of SOLID programming

As every automation engineer knows, automation systems can stay in production for decades on end. Also as every automation engineer also knows, during that time, the process will change, which will require new software, hardware will become obsolete and have to be replaced with new components, and so on, which, as you can guess, will require software modifications. As someone who has spent countless hours sifting through thousands of lines of code on customers' sites for hours on end for multiple different employers, I can say that when it comes to architecture, it is worth it to put in the extra effort. Even when you’re working on well-organized and architected codebases, you will find that tracking down a single error can be quite daunting. The task can become Herculean when the codebase is poorly designed.

With this in mind, it is best to think of SOLID as a series of general rules as opposed to hard standards that will produce code that...

The governing principles of SOLID programming

As we stated in the last section, there are five underlining principles that govern SOLID programming. They are as follows:

• S: Single-responsibility principle (SRP)
• O: Open-closed principle (OCP)
• L: Liskov substitution principle (LSP)
• I: Interface segregation principle (ISP)
• D: Dependency inversion principle (DIP)

The first, and in my opinion, the easiest and most important principle to explore is the SRP.

The single-responsibility principle

The SRP is, in my opinion, the most important of the five principles to implement. In short, the SRP states that a code module should do one thing and one thing alone, kind of like the way we defined what a function should do in Chapter 5. In short, this goes back to the one-sentence rule. If you have to use the word and to describe your module, you have violated the SRP and you should break the service out. Generally, this is a trick that many experienced developers...

Final project – a painting machine

Painting machines are often complex devices that have many moving parts. For our final project, we are going to build a simulated device that can move the part on a conveyor belt and paint a sentence on the part. For this project, we are going to set the following requirements:

• Drive the conveyor belt (belt on/off)
• Select between two paint APIs
• Paint a message on a part

With these requirements, we can formulate a design like the following:

Figure 10.15 – Painter design

Compared to other programs that have been presented in the book so far, this one has many more components and lines of code. As such, no code for this example will be displayed in the book. However, a working example can be found at the URL that was provided in the Technical requirements section. For this chapter example, the code can be found in the final project directory.

In this case, the PLC_PRG file is going...

Summary

As was seen in this chapter, SOLID can take some extra effort during the design phase. However, when done correctly, these five principles can ensure that your code is easy to fix and expand upon. In the fast-paced world of industrial automation, this is a must. You need to be in and out of a customer site as quickly as possible. As such, when implemented correctly, SOLID will support this.

Each of these principles will take some time to master but, once you do, the payback will be well worth it. At this point, you should have a good enough background to start expanding your knowledge and experience of these concepts. Hence, with all this in mind, we can now move on to another very important aspect of automation programming: HMI design.

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. What are common code modules?
2. What should you do if the word and appears in the summary of your module?
3. What is the Liskov substitution principle?
4. What is the interface segregation principle?
5. Name the five principles of SOLID.

Further reading

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

• SOLID: The First 5 principles of Object-Oriented Design: https://www.digitalocean.com/community/conceptual_articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design
• SOLID: https://en.wikipedia.org/wiki/SOLID
• Exploring the Liskov Substitution Principle: https://www.infoworld.com/article/2971271/exploring-the-liskov-substitution-principle.html
• LSP: https://medium.com/@gabriellamedas/lsp-the-liskov-substitution-principle-e43910b638bc
• SOLID Design Principles – Liskov Substitution Principle (LSP): https://medium.com/@gabriellamedas/lsp-the-liskov-substitution-principle-e43910b638bc