Using class A object in properties of class B in matlab?

From a MATLAB OOP perspective, the choice struct

or custom class is highly dependent on the specific application and considerations of maintainability, extensibility, performance, etc.

I like structs

it as I find them extremely lightweight compared to custom classes and very flexible as fields can be added on the fly. Some disadvantages structs

that come to mind when it comes to complex applications:

• The fields are added dynamically: I know what I listed as a plus, but it is a plus that needs to be used with care. Matlab will happily add the "geuss" error field to the struct
  
  containing guess
  
  on assignment and it will be fine until it does. This does not happen with custom objects, as properties can be dynamically added by inheriting from dynamicprops
  
  and explicitly calling addprop
  
  (I think).

• All fields are visible and assigned to one and all. If the application is intended for less skilled users, hiding certain information or restricting / compressing variables or assignment values ​​may be useful or perhaps necessary.

• Fields within struct
  
  cannot work with data struct
  
  after the field is created; in my opinion, this is one of the main reasons why OOP has become one of the dominant programming paradigms: it is very useful to have something (object) that can store data, and return the result without caring about how it was calculated (as if it is right).

However, there is also an overhead when using all the additional custom classes added. Matlab's OOP model improves performance, but I think it struct

still takes a toll on raw performance as a simple data container. And if you don't need power, you can avoid it without issue.

Another important thing you can get with custom classes are links that can automatically update information across all instances. To illustrate this point and hopefully address your second question indirectly, consider the following MedicalChart

class

classdef MedicalChart < handle

    properties
        doctor_info  = [];
        patient_info = [];
    end 

    methods
        function MC = MedicalChart(doc,pat)
            if (nargin ~= 0)
                MC.doctor_info = doc;
                MC.patient_info = pat;
            end
        end
    end

end

      

        
        
        
      

    

I can define properties using two structures and instantiate this class:

>> doctor.name  = 'Joe'     ;
>> doctor.phone = '555-0100';
>> patient.name = 'Bob'     ;
>> mc = MedicalChart(doctor,patient);
>> mc.doctor_info.phone
ans =
555-0100

      

        
        
        
      

    

But now I may have a problem. Suppose I have a large application and Dr. Joe has many patients, each with their own instance MedicalChart

. struct

doctor

can be reused seamlessly to create all these medical records by duplicating all of the doctor's information in each case. It's pretty redundant in terms of memory, but not a huge deal.

But what if Dr. Joe changes his number? We would need to recreate everything MedicalCharts

with an updated one struct

.

We can avoid the need to recreate all instances as well as duplicate data by instantiating Dr. Joe class doctor

that inherits from : handle

classdef Doctor < handle

    properties
        name
        phone
    end

    methods
        function doc = Doctor(name,phone)
            if (nargin ~= 0)
                doc.name  = name;
                doc.phone = phone;
            end
        end
    end

end

      

        
        
        
      

    

And now we create MedicalChart

like this:

>> DrJoe = Doctor('Joe','555-0100');
>> patient.name = 'Bob';
>> mc = MedicalChart(DrJoe,patient);
>> mc.doctor_info.phone
ans =
555-0100

      

        
        
        
      

    

Very similar. But since I inherited from handle

, there is only one instance in memory DrJoe

. Thus, any changes made to this object are automatically available in mc

:

>> DrJoe.phone = '555-0111';
>> mc.doctor_info.phone
ans =
555-0111

      

        
        
        
      

    

This is a really good function for doing a lot of things like a database and structs

can't do things at all.

The only complication that comes to mind is when you delete instances and what happens to their references when you delete. On my R2014b installation, the uninstall DrJoe

works fine as it mc

creates a local copy DrJoe

. The patient doesn't really have to have a doctor, but accounting for that would complicate this example.

(I think it would have to be doctor

tracked MedicalCharts

and removed from them as part of my destructor for everything to work correctly . I don't think there is a need here, but I thought I mentioned it.)