Class folders and passing variables to objects

Hi all,

i am a beginner with classes and want to create a complex class structure.

My target is to generate a library for testing (TLib) with classes. Every Test needs a unique TestSet with Library Items (e.g. Criterion, Disturbance etc.) . A test specification defines a Unique TestSet. The TLib Object shall hold the TestSet and the collected initialization Parameter.

classdef TLib 
    properties (GetAccess = public , SetAccess = protected)
        TestSet
        InitParams
    end
    function obj = TLib(obj, TestSpecification)
         obj.TestSet = FillTestSetProperty(TestSpecification);
    end
end

When calling "TLib" the test specification shall be passed as an argument to fill the TestSet. My first Problem is, that the test specification is not passed as an argument.

TLib(TestSpecification)

What am i doing wrong? I also would like to treat TestSet and InitParams as inherited classes of TLib. InitParams shall hold all default initialization parameter as properties. These properties shall only be changed inside the TLib classes and subclasses. I would like to pass all initialization parameter from library items to the InitParams subclass.

My folder structure looks like this:

./+TLib/+criterion/default_criterion.m % <-Superclass with properties
./+TLib/+criterion/criterion1.m % <-subclass with a method to load properties of default Criterion
./+TLib/+criterion/criterion2.m %
./@TLib/TLib
% Path for InitParamsClass missing
% Path for TestSetClass missing

This works for me. The advantage is that I can see all variables by using namespace like this:

TLib.Criterion.criterion1

My main issue is, that I don't know how to pass arguments to the objects of TLib subclass InitParams and TestSet. So i need a folder structure and a minimal code example for implementing. I also did not menage to pass TestSpecifcation as an argument to TLib. Any links or hints are helpful.

Thank you!

Answer 1

[Steven Lord]

My first Problem is, that the test specification is not passed as an argument.

You've defined your constructor to accept two inputs but you only call it with one. Remove the obj input from the constructor definition. [All other non-Static methods must accept an instance of the class as at least one of their inputs, but the constructor and Static methods do not.]

I also would like to treat TestSet and InitParams as inherited classes of TLib. InitParams shall hold all default initialization parameter as properties.

This has gotten a bit long and a bit not MATLAB specific, but in my (very biased) opinion I have some general advice that I think you'll find useful.

As written TestSet and InitParams are properties of TLib objects, they are not subclasses of the TLib class. While I can't be certain from the names it doesn't seem to me that TestSet and InitParams are suitable to inherit from TLib.

One general object oriented programming principle, the Liskov substitution principle, basically roughly says that you should be able to substitute a subclass object for a superclass object and still have what you're doing "make sense". As an example, a Dog class could inherit from an Animal class because anything an Animal can do a Dog can do as well. But a Car class shouldn't inherit from Animal since an Animal can breathe() and a Car cannot. [Nor should Animal inherit from Car since a Car can drive() but a general Animal cannot.]

Perhaps you want to use composition instead of inheritance. A Car object should not inherit from an Engine class or vice versa, but a Car object should contain an Engine object. Similarly perhaps a TLib should contain a TestSet and a ParameterSet.

Before you go further in your implementation, I advise you to plan out the design of your software system. You don't have to draw a UML diagram but it might help. Plan out what each entity in your system is, what its purpose is, what it contains, what it can do (what methods it should have), and how it relates to the rest of the entities in your system.

• What stuff does the entity contain (composition), what does the entity know (data): properties
• What can the entity do, what can I do to the entity: methods
• Can I substitute this entity for another entity: inheritance
• What do I need to know to make this entity: constructor arguments

Once you have a "recipe" or plan for your multi-class system it should be much easier to determine how to implement it. Whenever I've had to implement a class hierarchy I've had a lot less pain and backtracking (to add in pieces I forgot in a base class) when I took the time to plan it out first.