5

I'm working on Finite Element code in MATLAB, and the number of constants (for instance user input defining the geometry, physics, numerical solution scheme) is substantial. Currently, I've been passing variables between subroutines using global statements, but these offer no indication what the variables are or what their use is; not ideal as the code expands.

I want to encapsulate related constants in MATLAB objects (for instance GEOMETRY, for all the geometry constants, etc. In this usage case, they will essentially be structs; they will have no associated private functions.) Is this bad coding practice? It seems to run contrary to everything I know about good object-oriented programming.

Eventually (once I'm done prototyping), I want to convert everything to C++, so my main concern is doing this in a way that is acceptable in both programming paradigms.

Notes:

  • MATLAB allows definition of "objects" in a very ad hoc way:

    GEOMETRY.DX = DX;
    GEOMETRY.DY = DY;
    

whereas C++ would require definition of a class; I'd like to minimize inter-language editing required.

  • Arrays are not a suitable solution. The data is related in purpose, but is not all the same size, type, etc. Using objects ensures 1, like data is grouped together; 2, any time the data is referenced, it is referenced using its original name; 3, code clutter, contradictions, and ambiguity from global statements is removed.

Am I "breaking the rules" using objects as I've proposed? If so, is there a better way to structure my data? Thanks.

bumped to the homepage by Community 2 days ago

This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.

  • 1
    You could put your constants in namespaces. That way you won't introduce name collisions. Also C++ is a multi paradigm language and by no means encourages object-oriented programming above other techniques. Your concerns about the organization are very valid, and whether you use namespaces or structs(classes and structs or identical except for default visibility) you should group things together meaningfully as you've intuited. – Aluan Haddad Mar 28 '18 at 22:37
  • Thanks; I appreciate the clarification on structs and suggestion of namespaces, I'll definitely look into that. – Dominic Jarecki Mar 29 '18 at 15:00
0

I'm working on Finite Element code in MATLAB, and the number of constants (for instance user input defining the geometry, physics, numerical solution scheme) is substantial.

You probably just named the three objects where these constants should reside.

Currently, I've been passing variables between subroutines using global statements,

Yeah, stop doing that.

but these offer no indication what the variables are or what their use is; not ideal as the code expands.

It's not ideal with tiny bits of code.

I want to encapsulate related constants in MATLAB objects (for instance GEOMETRY, for all the geometry constants, etc. In this usage case, they will essentially be structs; they will have no associated private functions

And here's your problem. Why not? This is not object oriented. If you don't put the methods that need the constants here, you're turning the object inside out. Spreading knowledge around makes your code ridgid. Hide what your other objects don't need to know from them. Don't force me to ask Geometry for things I need from it. Let me tell Geometry what to do. See, tell, don't ask1,2.

I want to encapsulate related constants in MATLAB objects (for instance GEOMETRY, for all the geometry constants, etc. In this usage case, they will essentially be structs; they will have no associated private functions.) Is this bad coding practice? It seems to run contrary to everything I know about good object-oriented programming.

Encapsulation done right is more than clustering. I can see your constants from outside. That means I know about them. That means I'll end up depending on them. That means you can't change them, rename them, or move them without breaking me. Use data hiding and you can do as you like with them and I'll never know.

Eventually (once I'm done prototyping), I want to convert everything to C++, so my main concern is doing this in a way that is acceptable in both programming paradigms.

A language is not a paradigm. Your paradigm is, ostensibly, object oriented. You can do that in languages not even designed for it. You just have to follow it's practices.

If jumping from language to language turns converting into your main concern maybe just use one language. Your main concern should be the problem you're trying to solve. Anything that distracts you from that had better be doing something amazing for you.

whereas C++ would require definition of a class

Classes are not required to write object oriented code.

Am I "breaking the rules" using objects as I've proposed? If so, is there a better way to structure my data?

You're breaking a very important one. Spreading knowledge around hurts flexibility. I'd rather see you define pi in multiple places then do this. If the constant is something you want to adjust in one place then make that one place a full rights citizen and group methods around it.

But if you insist on providing access to things that don't need it, at least make the places you put the public constants easy to find. I find PI in Math just fine. But that's a library. People maintaining your software will have many other things to think about. Don't ask them to memorize a complicated structure to find the constants they're looking for. Avoid names like Misc. Make the structure and names meaningful.

  • I appreciate the tips and articles you linked; I'll definitely think about the structure outlined there. – Dominic Jarecki Mar 29 '18 at 14:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.