How to communicate among objects from different classes in a solid way?

Hi all,

This is a really long question, thanks for your patience!

Imagine I have two classes like this:

classdef beam < handle
  properties
      stiff_mtx1
      stiff_mtx2
      stiff_mtx
  end
  methods
      function obj = beam(stiff_mtx1, stiff_mtx2)
          obj.stiff_mtx1 = stiff_mtx1;
          obj.stiff_mtx2 = stiff_mtx2;
      end
  end
end

and

classdef parameter < handle
    properties
        pm1
        pm2
    end
    methods
        function obj = parameter(pm1, pm2)
            obj.pm1 = pm1;
            obj.pm2 = pm2;
        end
    end
end

and a main script to start objects:

clear; clc; 
stiff_mtx1 = % a stiffness matrix.
stiff_mtx2 = % another stiffness matrix with same size.
myBeam = beam(stiff_mtx1, stiff_mtx2);
pm1 = 5;
pm2 = 10;
myPm = parameter(pm1, pm2);

So far so good, but then I want 'stiff_mtx' in beam class to be obtained like this:

myBeam.stiff_mtx = myBeam.stiff_mtx1 * myPm.pm1 + myBeam.stiff_mtx2 * myPm.pm2;

Which I tested, it works. obviously this is a communication between beam class and parameter class, and property 'stiff_mtx' is assigned after this line of command. My question is: is this the SOLID way to allow objects communicate with each other? I read in book saying in OOP, inheritance should be avoided while composition is recommended, which I agree. In the above example I could define pm1 and pm2 as properties of beam, which results in one beam class only, but I believe this is not SOLID because: 1. beam is obviously different from parameter; 2. simply adding properties in one class makes a class unnecessarily complex, which violates the SOLID principle.

I'm not sure how to allow communication among different objects, and is it SOLID to define different classes and related objects, make them communicate, or just define one big class and create one object?

Also the above line

myBeam.stiff_mtx = myBeam.stiff_mtx1 * myPm.pm1 + myBeam.stiff_mtx2 * myPm.pm2;

can it be defined as a method and put in a class? My thought is this line can be defined as a function and can be called when needed, and my program becomes a combination of OO classes and traditional functions, is this SOLID?

Answer 1

[Adam]

I'm rusty on my SOLID principles and don't tend to have time to get back up to date so I tend to just go with intuition instead. One simple rule of thumb though for working out where something should go is to look at what objects are being used in the expression. If one object is having its properties referred to often (more often than others) then it immediately jumps to the front of the queue as a candidate to have that function as a member of its class.

So in your case, if you have decided that beam and parameter are two distinct objects then I would add that function to the beam class and pass it the parameter object since it sets a property of beam based on two other properties of beam. Then, if those other two properties of beam are not used externally they can be made private for better encapsulation e.g.

function calculateStiff_mtx( obj, myParam )
   validateattributes( myParam, { 'parameter' }, { 'scalar' } ) % Optional fussiness - if performance is crucial and this is called very frequently don't include this

   obj.stiff_mtx = obj.stiff_mtx1 * myParam.pm1 + obj.stiff_mtx2 * myParam.pm2;
end

I would strongly advise you to come up with more meaningful names though unless 'parameter' is contained within a package which gives it context.

[Xh Du]

Hi Adam,

Thanks and you are really helpful!

I don't quite understand the last sentence 'unless 'parameter' is contained within a package which gives it context.' Do you mean parameter is a build-in variable name in a package so that I should avoid using it?

[Adam]

It isn't a builtin name (you can always check this by typing 'which parameter' on command line), but unless you are going to write so little Matlab code that 'parameter' is completely unambiguous (which seems hard to imagine) then it needs a clearer name to say exactly what it is - e.g. BeamDefinitionParamater (just an example, I don't know exactly what it is a parameter of).

If it where in a package then a simple name is ok, e.g. sticking with the same example, if you had a package called 'BeamDefinition', then having a class just called 'parameter' within this package is fine because it will be referred to as

BeamDefinition.parameter

which gives it context.

[Xh Du]

And regarding your saying ' if you have decided that beam and parameter are two distinct objects', I believe beam and parameter should be two classes also for the reason of future upgrade of the program (this is probably a question of how to design my OO program). Parameter of course is a property of beam, but in the future if there is another class 'plate', or 'column', parameter is also a property of these new classes. I do not want to add parameter property to the new class I define every time, therefore I'd like to extract 'parameter' as an independent class and make another object, add parameter to any structure by composition of different objects.

[Adam]

That sounds fine. Then just inject it into whichever classes require it when they do so.

[Xh Du]

Thanks!