Taking the Next Step with Object-Oriented Programming in MATLAB

Beyond just objects, classes, properties, and methods, there is a multitude of other object-oriented programming concepts just waiting to be discovered. So today, let's pull back the curtain on how you can take full advantage of MATLAB to optimize your object-oriented programs. We'll be using an example in MATLAB to showcase how the MATLAB language grows as you need it.

If you're not too familiar with objects and classes in MATLAB, or if you just want a refresher on the basics, pause this video now and check out "What Is Object-Oriented Programming in MATLAB" link in the description. There you'll get an introductory walkthrough of the essential concepts we'll be building on today. Hopefully, by the end of this video, we'll be confident in our ability to take the next step with object-oriented programming in MATLAB.

Today, we'll be using an example featuring orienteering to orient ourselves with object-oriented programming. Orienteering is a sport in which participants use a map to find their way through the wilderness to a series of waypoints as quickly as possible. These participants carry an electronic ID stick, which records their visits to each waypoint. This example is featured in the MATLAB Object-Oriented Programming Onramp Tutorial, and we'll be using a simplified version of it today.

We need to refine our system, where participants in an orienteering competition can register for a specific course, and then log their progress using ID sticks. In this video, we'll be working with a few interacting classes-- course, which describes a specific course, ordered course and scored course, which describes certain types of courses, and ID stick, which will track participants' progress through the course. By the time we're done, we'll have taken a basic orienteering system and optimized it to be more user friendly, versatile, and expandable. Let's dive in.

One of the most valuable ways you can enhance your MATLAB object-oriented systems is understanding the difference between value and handle classes. Value is the more common type of class in which each variable we create makes a copy of an object and refers only to this copy. In a MATLAB handle class, multiple variables can reference the same object. A value class behaves like a normal MATLAB variable, like a struct or a double array, whereas a handle class is helpful when its object represents a physical entity, like a hardware device that cannot be cloned.

In our example, we can correctly write ID stick representing a physical thing as a handle class. Each physical ID stick has its own unique identity and cannot be copied. Thus, a handle class is the best fit so that every object created is not a generic copy, but rather directly references one specific ID stick, so there's no confusion as to whose ID stick is whose.

With a value class, you must return the object if you want any changes made within the method to persist. That's because the object passed as input into a method is a copy, where the method gets a new copy of that object. With a handle, you don't need to return the object because all the references are pointing at the same underlying object. So if we change any reference to the ID stick handle object, that change will be reflected in all variables referencing that ID stick.

Since multiple references to a handle class can refer to the same object, there needs to be a way to get rid of these object references when they are no longer needed. Enter the destructor. A destructor method in MATLAB manages our object cleanup and handle classes, and is represented by a method named delete. Delete takes a single input argument, the object sentence for destruction, and returns no outputs. We can call delete explicitly to destroy all remaining handle variables, or to free up resources, like when you need to close a file when a handle object is deleted, or MATLAB will call it implicitly when certain actions occur, like when all variables which reference that handle object are cleared.

We've seen multiple factors that make a handle class so important, but how do we indicate a class is actually a handle? The syntax is simple. All handle classes inherit from the handle superclass, so we just need to add less than handle after the class Def name. This simple tweak shows the ease of achieving the design you need with handle classes.

Inheritance is an effective tool to make your code more robust, structured, and reusable. Let's explore inheritance beyond just creating our own custom super and subclasses. We just saw we can use inheritance to define handle classes. In addition, through inheritance, we can use mixins, which are pre-built abstract classes that allow you to customize certain behaviors of your class. Our course class inherits from the mixin custom display, which allows course objects to have customizable display options.

With all these useful ways we can utilize inheritance, thankfully, classes aren't limited to inheriting only from one other class. By using the ampersand symbol, we can add more superclasses to a class definition. So our scored course subclass can inherit both from our course superclass and from custom display at the same time.

One of the most powerful traits of inheritance in MATLAB is overriding. By overriding, you can really make subclasses your own by distinguishing them from the superclass. In our ordered course and scored course subclasses, we've added properties and methods to represent their attributes and behaviors distinct from the course superclass. But through overriding, we can go a step further by customizing the functions inherited in the subclasses.

Ordered course adjusts the inherited function check waypoint to account for its additional requirement of the waypoints being in the proper order. And scored course adjusts the function to account for its timing requirements. If it wasn't for these adjustments, both of these check waypoint functions would just be copies of the version inherited from the superclass. This level of fine tuning with subclasses is only possible with overriding.

In addition to inheritance, we can make our classes easier to use by adding helpful guardrails called attributes and restrictions, both at the class level and at the property and method level. At the class level, we can apply a variety of attributes. If a class is abstract, you cannot create an object of that class, like the mixins we just discussed. An abstract class is a building block which defines all the properties and methods that its subclasses will use, but it's only through the subclasses that we can create an object of that class.

In contrast, adding the sealed attribute to a class makes it unable to be a superclass. A sealed class cannot be inherited, and objects must be created directly from it. For our course class, we would want to make it abstract in a scenario where every orienteering course created needs to be explicitly and ordered or scored course. So the course superclass itself shouldn't have objects created from it.

As we discussed earlier, the abstract course class would provide common operations that ordered course and scored course need to utilize in different ways through overriding. Alternatively, we could use the sealed attribute if we don't want users to subclass our scored course class.

Going beneath the class level to the property level, we can apply attributes like constant, which makes properties have the same value in all instances of that class, or access equals protected, which means properties can only be read or set from an object of that class or one of its subclasses. Just like with properties, we can apply attributes to methods to give them the same protections and restrictions. Method access can have familiar settings like public, private, or protected to adjust from where they can be executed. Plus, we can apply other attributes like static when we want to make that method callable without having to create an object of its class.

All of these attributes help make our classes more user friendly and secure, and there are even more strategies to achieve that beyond attributes. One tool to use is enumerations. Enumerations, which we can use here in our course class, are a useful approach for defining a small set of named values by defining these values in their own separate class. Instead of requiring that the inputs of the level property are type string, we can require that they are type difficulty level. Our new enumeration class, difficulty level, represents a fixed set of five named values, so the level property can only take on one of these five.

You can even have enumerations inherit from other classes, such as built-in numeric types like uint8 here, which allows us to have a convenient ranking of the difficulty levels. By adding enumerations to our class definitions, our object-oriented systems become more versatile, shareable, and secure. And there you have it.

We've taken our class definitions and enhanced their capabilities, making a more streamlined, user friendly, and robust orienteering system, showcasing how the MATLAB language grows to handle complex situations in an elegant way when you pull back the curtain on object-oriented programming. We've covered enough today to have you well equipped in the field of object-oriented programming in MATLAB, but your journey doesn't stop here. MATLAB supports a wide array of helpful capabilities and features for you to keep exploring. For more information, check out the free MATLAB Object-Oriented Programming Onramp Tutorial, which builds on the topics and the example we use today, as well as documentation on MATLAB's extensive object-oriented programming capabilities, all linked in the description. Thanks for watching, and I'll see you in another video.