All,

I have started my journey into learning about Object-Oriented Design Patterns by using the Head First Design Patterns book from O'Reilly and Eric Freeman (recommended by @benhar-dev).

Along with reading the book, I have been following along by doing the examples in the book in both Java (using the BlueJ IDE) and Structured Text (using TwinCAT 3), as well as using the Christopher Okhravi video series that goes along with the book ( https://www.youtube.com/playlist?list=PLSNcnAVbxuL8J0xq7qIniVFLIXBEFa3Ah) (also a recommendation from @benhar-dev).

I finally got around to starting to read it and I wanted to show what I have learned so far. The first chapter start off with the Duck example and how the developer eventually works his way towards using the Strategy Pattern in order to solve his development issues.

As the book defines it....

"The Strategy Pattern defines a family of algorithms,
encapsulates each one, and makes them interchangeable.
Strategy lets the algorithm vary independently from
clients that use it."

For the example, the client is any Duck in the Duck simulator. The developer wanted to add different kinds of Ducks that had different kinds of quacking and flying behaviors. The problem he ran into was that on every attempt, he learned that as he created more and more unique Ducks, the methods inside those ducks needed to be changed if they were different. 

This example showed the most important thing that I learned from the chapter, which is: "take the parts that vary and encapsulate them, so that later you can alter or extend the parts that vary without affecting those that don’t."

The developer took the parts that varied and encapsulated them using interfaces and separate classes, then eventually created ducks that dynamically set the fly and quack behaviors and left the display() method the same for all ducks.

In my work, I recreated the Duck simulator using Java and TwinCAT, below are the matching UML diagrams for each:

In the Java example from the book, the methods fly() and quack() output messages to the console using System.out.println(). In order to replicated this in TwinCAT, I used the ADSLOGSTR() function block and added an input BOOL called test to each method, which would come from the .Q bit of an R_TRIG in the main method that would allow the message to output only once every time I manually turn on and off a test bit.

Below are the interfaces for the QuackBehavior:

and the Fly Behavior:

For these behaviors, I made a method in the abstract Duck class called setBehavior, along with creating internal variables called fb and qb that would allow for the MAIN program to dynamically set which behaviors the duck objects will use.

Then the MAIN method is the following with the results:

What I have loved about the learning process so far is that both the created Duck subclasses derived from the main abstract class Duck don't have anything in them in both languages, yet the still have the same function as the Duck abstract class.

The only thing I did not like and I do not know is that in TwinCAT, you have the explicity call out the function blocks (objects) for the behaviors, while in Java I can just call them inside the instance where I am setting the behaviors.

this

 vs
this

Just through the first chapter alone, I am seeing how powerful this is if you know how to correctly use the principles with the patterns. I could definitely see the Strategy Pattern being used on a project where there are multiple servo motors of different sizes and you want to be able to swap out different sizes that have behaviors that are similar and that are different.

Let me know your thoughts and suggestions below.

Shoutout to @twinControls, @runtimevictor and @raoliveira for being helpful on the forum as well for OOP.

-Evan H.