OOP: too many interactions between different classes

I am currently programming (OOP) a model for a separation process similar to column chromatography. As the different physical phenomenon that occur during the separation process can be described by various correlations, I want to keep the model as flexible as possible, so one can easily switch between those approaches. However, the code must not take too much time to run, of course. Hereafter, I will try to give a quick overview of how I structured the model:

Class Process: This class contains properties with information about the process like geometry, flow rates, feed composition etc. and properties that specify what approaches for the mathematical description of the physical phenomenon like fluid dynamics or adsorption kinetics are used. It is also the class where most of the calculations take place.

Superclasses and subclasses for physical phenomenon: For each phenomenon I created its own superclass. Thus, every specific approach is a subclass of the corresponding superclass (eg. Superclass: adsorption - Subclass: Langmuir). I decided to program it this way to make sure that even by using another approach the code of the class Process does not have to be changed, but only the information in its properties.

Class Component: As the components in the feed have different physical properties, I created a class that creates an object and, depending on the component name, stores the specific information as compProp as a property.

Aim of this model is showing how the concentration of the different components varies with location and time and thus requires solving a system of differential equations. The class Process includes a method which creates the system (via a nested function) and solves it afterwards.

The part of creating that system of differential equations is the part my question refers to: As the equations depend on which approach for the particular physical phenomenon is used, the class Process has to call up at least one of the subclasses for each row of the equation system to fill in the specific correlations. Sometimes it is necessary that a subclass again has to call up another subclass. Furthermore, every subclass needs the whole object of the class Process as input, as the geometrical information or component specific constants they rely on, are stored in its properties.

Apparently, the structure is quite complicated, but I did not know another way to keep model as flexible as possible. So here is my question: Is there an obvious alternative way for problems like this that I may not know (I am new to programming with matlab)? Or is there a rule of thumb how many interactions and classes are too many?

I know it is a quite rough sum up of the whole project, but nevertheless maybe someone who is more familiar with matlab has got a solution for this problem that I just missed.

Thank you in advance!

Answer 1

[Steven Lord]

It's going to be difficult to offer any concrete suggestions with this extremely high level description of your system.

Class Process: This class contains properties with information about the process like geometry, flow rates, feed composition etc. and properties that specify what approaches for the mathematical description of the physical phenomenon like fluid dynamics or adsorption kinetics are used. It is also the class where most of the calculations take place.

So this class stores data. What can you do on a Process object? What are some of its methods?

If it's just for storing data with no methods you may want to consider using a struct array instead.

Superclasses and subclasses for physical phenomenon: For each phenomenon I created its own superclass. Thus, every specific approach is a subclass of the corresponding superclass (eg. Superclass: adsorption - Subclass: Langmuir). I decided to program it this way to make sure that even by using another approach the code of the class Process does not have to be changed, but only the information in its properties.

How many methods do these classes have? If they have but one method, I'd probably consider using an approach more like the ODE solvers or the integration functions and have whatever needs to simulate / calculate the phenomena call a function handle that performs the computations required for that phenomenon. As an example the ode45 function doesn't need to be modified each time a user wants to solve a different differential equation, the user just passes a different function handle into it.

Class Component: As the components in the feed have different physical properties, I created a class that creates an object and, depending on the component name, stores the specific information as compProp as a property.

What benefit do you get from making this a class (with multiple Static methods for creating different types of components, I assume?) over a function or a series of functions?

Is there an obvious alternative way for problems like this that I may not know (I am new to programming with matlab)? Or is there a rule of thumb how many interactions and classes are too many?

That's difficult to say.

It sounds like you're designing a fairly complicated system. So I would plan out exactly what pieces I need and how they interact (don't write any code for this quite yet.) You may find drawing a UML diagram (or a similar type of flowchart of the workflow) useful in keeping track of how the pieces fit together.

Once you know what pieces in what shapes you need, assembling the overall structure will be easier.

[Katja Stingl]

Thank you very much for the quick response!

Class Process: This class stores data, but also includes the calculation for modeling the process. The process is composed of several steps, e.g., the actual separation, an elution, and a washing step. Each of these steps requires its own system of differential equations. The class includes one method for each step, that puts together these particular systems by calling up the specific subclasses for the different physical phenomon. Then, the system is solved by using the ODE45 function.

Superclasses and subclasses for physical phenomenon: The classes always have 2 – 4 methods. One is for extracting all needed constants from the properties of the Processobject or if necessary, calculating new constants, the others mathematically describe the specific physical phenomenon.

Class Component: The only reason I chose a class over a function is that I was not sure weather mixing OOP with functions that are not included in a class is “best programming practice”.

I hope I can make the structure clearer by giving an example:

The separation process is defined by the differential equation dc/dt = A + B. A describes the adsorption kinetics, but there are two approaches to do so: A1 = a * Ω^2 and A2 = a * Ω+Ψ . Both approaches are included in a method of two different subclasses (e.g. AdsorptionApproach1 and AdsorptionApproach2). B describes another phenomenon, also with two possible approaches B1 and B2.

Calling the method Separation() the equation is put together by using the approach stored in the properties of the class Process, e.g. for adsorption kinetics approach 1 and for B approach 2. First, class AdsorptionApproach1 is called to provide the first part of the equation. By calling the class BApproach2, the second part is added. Now, the differential equation is solved within the method Separation() by an ODE solver.

By splitting up the equations into the different phenomenon, an approach can be easily displaced by another, without having to create a lot of different functions that cover all possible combinations of approaches.

[Jeff Miller]

Furthermore, every subclass needs the whole object of the class Process as input, as the geometrical information or component specific constants they rely on, are stored in its properties.

The classes always have 2 – 4 methods. One is for extracting all needed constants from the properties of the Process object.

It sounds like you are passing the Process object around and the different subclass methods extract the information they need from it. Maybe you could instead pass each subclass method just the information it needs when you call it from process? To me, that would seem to separate the different classes more cleanly, if it is possible.

[Katja Stingl]

Thank you very much for your suggestion!

Maybe I could use a struct array that is created by the method that defines the needed constants and only pass this array instead of the whole Process object.