16

I want to have a catalog of constant materials so I can use code that looks like the following:

Dim MyDensity, MySymbol
MyDensity = ALUMINUM.Density
MySymbol = ALUMINUM.Symbol

Obviously the density and symbol for aluminum are not expected to change so I want these to be constants but I like the dot notation for simplicity.

I see a few options but I don't like them.

  1. Make constants for every property of every material. That seems like too many constants since I might have 20 materials each with 5 properties.

    Const ALUMINUM_DENSITY As Float = 169.34
    Const ALUMINUM_SYMBOL As String = "AL"
    
  2. Define an enum with all the materials and make functions that return the properties. It's not as obvious that density is constant since its value is returned by a function.

    Public Enum Material
         MAT_ALUMINUM
         MAT_COPPER
    End Enum
    
    Public Function GetDensity(Mat As Material)
        Select Case Mat
            Case MAT_ALUMINUM
                GetDensity = 164.34
        End Select
    End Function
    

It doesn't seem like Const Structs or Const Objects going to solve this but maybe I'm wrong (they may not even be allowed). Is there a better way?

Mathieu Guindon
  • 69,817
  • 8
  • 107
  • 235
R. Binter
  • 221
  • 1
  • 8
  • 2
    This is attracting enough interest that it would be nice to see the final product posted as a question on [Code Review](https://codereview.stackexchange.com/) if you're up for it. – Comintern Nov 16 '18 at 18:31

5 Answers5

13

Make VBA's equivalent to a "static class". Regular modules can have properties, and nothing says that they can't be read-only. I'd also wrap the density and symbol up in a type:

'Materials.bas

Public Type Material
    Density As Double
    Symbol As String
End Type

Public Property Get Aluminum() As Material
    Dim output As Material
    output.Density = 169.34
    output.Symbol = "AL"
    Aluminum = output
End Property

Public Property Get Iron() As Material
    '... etc
End Property

This gets pretty close to your desired usage semantics:

Private Sub Example()
    Debug.Print Materials.Aluminum.Density
    Debug.Print Materials.Aluminum.Symbol
End Sub

If you're in the same project, you can even drop the explicit Materials qualifier (although I'd recommend making it explicit):

Private Sub Example()
    Debug.Print Aluminum.Density
    Debug.Print Aluminum.Symbol
End Sub
Comintern
  • 21,855
  • 5
  • 33
  • 80
  • 1
    I like that, although then code that does `Materials.Aluminum.Density = 42` from outside will compile, even though will do nothing. – GSerg Nov 16 '18 at 17:38
  • @GSerg - Yeah, that's one issue - the returned `Material` really isn't a constant - there's nothing to prevent the caller from grabbing a reference to it. Ideally I'd combine this with one of the solutions from [this QA](https://codereview.stackexchange.com/q/157425/36565) to make the return value immutable, but that's a bit above and beyond. – Comintern Nov 16 '18 at 17:47
  • No, it's safe in the sense that the caller cannot mess it up, because `Material` is a value type. It's just that it allows non-sensible code to compile instead of giving an error of some sort. – GSerg Nov 16 '18 at 17:49
  • I like that! it gives easy to read notation, its value can't be modified, it lets me even pass the result like a variable with an enforced type. Example: Function CalculateWeight(Mat As Material, Volume as float) End Function Weight = CalculateWeight(Materials.Aluminum, 50.6) – R. Binter Nov 16 '18 at 17:49
  • 1
    @GSerg - Right, but you do need to be aware that you shouldn't `Dim x As Material: x = Materials.Aluminum` and then start messing around with it locally. – Comintern Nov 16 '18 at 17:51
6

IMO @Comintern hit the nail on the head; this answer is just another possible alternative.


Make an interface for it. Add a class module, call it IMaterial; that interface will formalize the get-only properties a Material needs:

Option Explicit
Public Property Get Symbol() As String
End Property

Public Property Get Density() As Single
End Property

Now bring up Notepad and paste this class header:

VERSION 1.0 CLASS
BEGIN
  MultiUse = -1  'True
END
Attribute VB_Name = "StaticClass1"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = False
Option Explicit

Save it as StaticClass1.cls and keep it in your "frequently needed VBA code files" folder (make one if you don't have one!).

Now add a prototype implementation to the text file:

VERSION 1.0 CLASS
BEGIN
  MultiUse = -1  'True
END
Attribute VB_Name = "Material"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = False
Option Explicit    
Implements IMaterial

Private Const mSymbol As String = ""
Private Const mDensity As Single = 0

Private Property Get IMaterial_Symbol() As String
    IMaterial_Symbol = Symbol
End Property

Private Property Get IMaterial_Density() As Single
    IMaterial_Density = Density
End Property

Public Property Get Symbol() As String
    Symbol = mSymbol
End Property

Public Property Get Density() As Single
    Density = mDensity
End Property

Save that text file as Material.cls.

Now import this Material class into your project; rename it to AluminiumMaterial, and fill in the blanks:

Private Const mSymbol As String = "AL"
Private Const mDensity As Single = 169.34

Import the Material class again, rename it to AnotherMaterial, fill in the blanks:

Private Const mSymbol As String = "XYZ"
Private Const mDensity As Single = 123.45

Rinse & repeat for every material: you only need to supply each value once per material.

If you're using Rubberduck, add a folder annotation to the template file:

'@Folder("Materials")

And then the Code Explorer will cleanly regroup all the IMaterial classes under a Materials folder.

Having "many modules" is only a problem in VBA because the VBE's Project Explorer makes it rather inconvenient (by stuffing every single class under a single "classes" folder). Rubberduck's Code Explorer won't make VBA have namespaces, but lets you organize your VBA project in a structured way regardless.

Usage-wise, you can now have polymorphic code written against the IMaterial interface:

Public Sub DoSomething(ByVal material As IMaterial)
    Debug.Print material.Symbol, material.Density
End Sub

Or you can access the get-only properties from the exposed default instance (that you get from the modules' VB_PredeclaredId = True attribute):

Public Sub DoSomething()
    Debug.Print AluminumMaterial.Symbol, AluminumMaterial.Density
End Sub

And you can pass the default instances around into any method that needs to work with an IMaterial:

Public Sub DoSomething()
    PrintToDebugPane AluminumMaterial
End Sub

Private Sub PrintToDebugPane(ByVal material As IMaterial)
    Debug.Print material.Symbol, material.Density
End Sub

Upsides, you get compile-time validation for everything; the types are impossible to misuse.

Downsides, you need many modules (classes), and if the interface needs to change that makes a lot of classes to update to keep the code compilable.

Mathieu Guindon
  • 69,817
  • 8
  • 107
  • 235
  • That way we end up with a bunch of classes, and the OP has [already disliked](https://stackoverflow.com/questions/53342482/constant-with-dot-operator-vba#comment93564213_53342609) a bunch of modules. – GSerg Nov 16 '18 at 17:52
  • 2
    @GSerg I know, and I believe this answer already states this clearly. Yet it's how you get 100% type safety and compiler-assisted consistency, without exposing a mutable UDT (which have frustrating limitations in VBA). It's a solution worth considering *regardless* of what the OP thinks of having many modules. Having many classes isn't a problem in any OOP language; my take is that it's only a problem in VBA because the IDE *makes* it inconvenient. And there's tooling to work around that. – Mathieu Guindon Nov 16 '18 at 17:57
  • some parts of this goes a bit over my head but my understanding is that you are suggesting making each material its own data type which inherits the interface from an abstract material class. Is that correct? And this would help with expanding my code in the future because it would let me make my code go even deeper such as making multiple types of aluminum etc. which could inherit from the aluminum type? – R. Binter Nov 16 '18 at 18:18
  • 2
    @R.Binter VBA doesn't do class ineritance, so you couldn't have an aluminum sub-type, but you can indeed have as many classes implementing `IMaterial` as you need. IMO we all missed a fundamental point though: this is *data*, not *code*. If the code is hosted in Excel, have the data live on a (hidden?) worksheet table (or a db table in Access) - then you only need one implementation of the interface, say, a `Material` class, and the rest of the code can be written against `IMaterial`, and all instances can be stored in a `Dictionary` with the `Symbol` as a key, making it trivial to retrieve. – Mathieu Guindon Nov 16 '18 at 18:22
  • 2
    ...basically I'd challenge the premise that `Aluminum.Density` even needs to exist; the code should only need to know about `IMaterial`, and not need to care whether it's working with `Aluminum` or `Titanium` or `Gold`. Much code gets slashed away if the code is the same regardless of what material you're working with! – Mathieu Guindon Nov 16 '18 at 18:27
  • 3
    @MathieuGuindon I love seeing your posts. Makes vba not seem like a child's tool <3 – Doug Coats Nov 16 '18 at 18:30
  • I agree - the underlying question here is how to expose constant data in an efficient way. While I like @MathieuGuindon's answer, I still think that addressing this as a data problem (and probably using a look-up table) is a better approach. – AJD Nov 16 '18 at 21:03
2

You can create a Module called "ALUMINUM" and put the following inside it:

Public Const Density As Double = 169.34
Public Const Symbol As String = "AL"

Now in another module you can call into these like this:

Sub test()
    Debug.Print ALUMINUM.Density
    Debug.Print ALUMINUM.Symbol
End Sub
ArcherBird
  • 2,019
  • 10
  • 35
  • So, option 1 then – Mathieu Guindon Nov 16 '18 at 17:22
  • 1
    @MathieuGuindon No, the module name is important because it allows the dot the OP wants. – GSerg Nov 16 '18 at 17:23
  • @MathieuGuindon true... I guess I don't see how to have a ton of constants without having a ton of constants... This at least gets to the "." behavior that the OP described – ArcherBird Nov 16 '18 at 17:23
  • That is a neat idea that I didn't think of but I think I would prefer having a lot of constants to having a lot of modules. I might have 20+ materials so that's a lot of modules also – R. Binter Nov 16 '18 at 17:26
  • @R.Binter - I get what you mean, but I think no matter what approach you take either constants or properties, there is going to be some sort of Data-Entry-Like work to get your constants set up in a structured way. – ArcherBird Nov 16 '18 at 17:29
2

You could create a Class module -- let's call it Material, and define the properties a material has as public members (variables), like Density, Symbol:

Public Density As Float
Public Symbol As String

Then in a standard module create the materials:

Public Aluminium As New Material
Aluminium.Density = 169.34
Aluminium.Symbol = "AL"

Public Copper As New Material
' ... etc

Adding behaviour

The nice thing about classes is that you can define functions in it (methods) which you can also call with the dot notation on any instance. For example, if could define in the class:

Public Function AsString() 
    AsString = Symbol & "(" & Density & ")"
End Function

...then with your instance Aluminium (see earlier) you can do:

MsgBox Aluminium.AsString() ' =>   "AL(169.34)"

And whenever you have a new feature/behaviour to implement that must be available for all materials, you only have to implement it in the class.

Another example. Define in the class:

Public Function CalculateWeight(Volume As Float) As Float
    CalculateWeight = Volume * Density
End Function 

...and you can now do:

Weight = Aluminium.CalculateWeight(50.6)

Making the properties read-only

If you want to be sure that your code does not assign a new value to the Density and Symbol properties, then you need a bit more code. In the class you would define those properties with getters and setters (using Get and Set syntax). For example, Symbol would be defined as follows:

Private privSymbol as String

Property Get Symbol() As String
    Symbol = privSymbol
End Property

Property Set Symbol(value As String)
    If privSymbol = "" Then privSymbol = value
End Property

The above code will only allow to set the Symbol property if it is different from the empty string. Once set to "AL" it cannot be changed any more. You might even want to raise an error if such an attempt is made.

trincot
  • 317,000
  • 35
  • 244
  • 286
  • 1
    this is a good suggestion but I think code could potentially set Aluminum.Density = 2 since I don't think it's really a constant – R. Binter Nov 16 '18 at 17:46
  • Indeed, @R.Binter, when one doesn't trust their own code to not change it, then you can make it a getter/setter property that only allows one change to the property (for initialisation) and no more. I added the suggest code for that to my answer. – trincot Nov 16 '18 at 18:06
  • 2
    *when one doesn't trust their own code* - say, why do we make anything `private` in C#? Or `final` in Java? It annoys me to no end that the attitude is "bah, doesn't really matter" only when the language is VBA. – Mathieu Guindon Nov 16 '18 at 18:34
  • Well, VBA is a long way from truly object oriented languages. For one it lacks a constructor accepting arguments. That would really be the way to go to initialise an instance, but it's not possible in VBA (unless I'm missing something), so we get into a kind of hacky way to almost get there. I'm not completely convinced that such workarounds are better than just living with the fact that VBA is not all that fantastic. – trincot Nov 16 '18 at 21:12
  • Such factories need to call setters, and then I would not know how to make those setters inaccessible from any other code but from within the factory methods. Do you know? I can't see yet how this fills the gap of not having constructors. – trincot Nov 16 '18 at 21:49
  • Code against the interface (as is best-practice in OOP), the setters only need to be on the concrete type. – Mathieu Guindon Nov 16 '18 at 21:55
  • Can you point me to an example where the factory can set a property, but other code in the same project cannot? – trincot Nov 16 '18 at 22:08
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/183802/discussion-between-mathieu-guindon-and-trincot). – Mathieu Guindon Nov 16 '18 at 22:09
0

I like a hybrid approach. This is pseudo code because I don't quite have the time to fully work the example.

Create a MaterialsDataClass - see Mathieu Guindon's knowledge about setting this up as a static class

Private ArrayOfSymbols() as String
Private ArrayOfDensity() as Double
Private ArrayOfName() as String
' ....

    ArrayOfSymbols = Split("H|He|AL|O|...","|")
    ArrayOfDensity = '....
    ArrayOfName = '....

    Property Get GetMaterialBySymbol(value as Variant) as Material
    Dim Index as Long
    Dim NewMaterial as Material
        'Find value in the Symbol array, get the Index
        New Material = SetNewMaterial(ArrayOfSymbols(Index), ArrayofName(Index), ArrayofDensity(Index))
        GetMaterialBySymbol = NewMaterial
    End Property

Property Get GetMaterialByName(value as string) ' etc.

Material itself is similar to other answers. I have used a Type below, but I prefer Classes over Types because they allow more functionality, and they also can be used in 'For Each' loops.

Public Type Material
    Density As Double
    Symbol As String
    Name as String
End Type

In your usage:

Public MaterialsData as New MaterialsDataClass
Dim MyMaterial as Material
    Set MyMaterial = MaterialsDataClass.GetMaterialByName("Aluminium")
    Debug.print MyMaterial.Density
AJD
  • 2,400
  • 2
  • 12
  • 22