OOP in VBA: Immutability & The Factory Pattern

The accompanying code for this article is here on GitHub.

Factory Pattern

A factory is exactly what it sounds like: it’s an object whose role is to make things; it encapsulates the notion of creating an object.

Dim thing As Something
Set thing = New Something '<~ type is known at compile-time

Dim lateBoundThing As Object
Set lateBoundThing = CreateObject("Some.ProgID") '<~ Windows Registry lookup at run-time

Whenever we use the New keyword or the CreateObject function, we create a new instance of a class.

Why would you want to encapsulate that?

VBA classes are Private by default: they can only be used within the project they are defined in. Class modules can also be made “Public, not creatable“, and used in other VBA projects that would add this VBA project as a reference (like you would reference the Scripting library, but now you’re referencing another .xlsm or .xlam). In the referencing VBA project, you can see and use the classes in that other referenced project, but you can’t create instances of them. You need a way to expose functionality to the referencing VBA project, to return instances of a public class.

You could have a standard module that exposes a public function that creates and returns the public class instance – but standard modules don’t quite encapsulate their members, and it’s up to the client code to properly qualify function calls or not: MyFactoryModule.CreateMyClass is just as valid as CreateMyClass, because public members of standard modules pollute the global namespace. An object whose sole responsibility is to create objects of a given type, keeps the global namespace clean – and that’s the factory patern in a nutshell.

But the referencing-project scenario isn’t the only reason to want a factory: sometimes creating a new instance of a class involves some amount of tedious setup code that can easily become redundant if we often need to create instances of that class in our code.

Set thing = New Something
thing.SomeProperty = someValue
thing.AnotherProperty = anotherValue
thing.OneMoreProperty = oneMoreValue
Set thing.OtherThing = New OtherThing '<~ imagine OtherThing also needs setup code!
'...

With a factory, that code only needs to exist in one place – and then DRY (Don’t Repeat Yourself) and SRP (Single Responsibility Principle) are being adhered to, which generally means cleaner code that’s easier to maintain than if it didn’t.


Singleton

In OOP design patterns, factories are often combined with the Singleton pattern, because there only ever needs to be one single instance of a factory class. Given that the class can’t be created by the client code with the New keyword, setting the VB_PredeclaredId attribute to True essentially makes that class’ default instance an effective Singleton, at least from the perspective of the VBA project that’s referencing the project that defines the factory class.

I cannot think of a way to implement the Singleton pattern in VBA: there’s always a way something somewhere might somehow be able to create another instance of the class, or for more than one instance to exist at once. If VBA classes could have constructors (let alone static and/or private ones) it would be a different story, but it doesn’t so you’d need to implement some clunky instance-managing code involving state that’s external to the class… and I’d much rather have none of that. It’s simply not worth breaking encapsulation just to try and work around that kind of language-level limitation.

That doesn’t mean we can’t have nice things though.


Default Instances

If you’ve ever exported a VBA class module and opened it in Notepad, you’ve probably already seen this:

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

You know how every UserForm comes with a “default instance” for free? That’s because user forms have this attribute set to True, and that instructs VBA to create a global-scope object named after the type, so you can do this:

MyForm.Show

Without explicitly creating an instance of MyForm, we use one that’s already there. That’s not very OOP though – in fact it’s pretty much anti-OOP, since by doing that you’re not creating any objects, and because the automagic default instance global object is always named after the class, it makes the code look like we’re calling the Show method of the class itself, rather than the Show method of an instance of that class… So what’s the use of this attribute in an OOP discussion?

Using default instances as a prima facie singleton in VBA has shown to be the key that unlocks the true OOP capabilities of the language: by crafting an API that keeps the default instance stateless, we gain full control over exactly how our objects are shaped and can be used in other code.

With this level of control, we can now have effectively immutable, read-only objects in VBA.


Immutability

To be clear: we cannot achieve actual immutability in VBA – that would require constructors and readonly backing fields for our get-only properties. An object that is immutable is initialized with a number of values, and retains these exact same values for the entire lifetime of the object. In languages where that is enforced by the compiler, it removes implicit assumptions about objects’ state, makes objects simpler, and by extension the code easier to reason about, since there’s no mutable state to track. The Functional Programming (FP) paradigm really likes immutability, but the benefits are useful in OOP code as well.

In fact, exposing Property Let accessors for a property that has no business being written to by external code, breaks encapsulation and shouldn’t be done: the problem is that something, somewhere needs to supply the original value, and that is where factories come into play.


Example: Cross-Project Scenario

Say you have a Car class, with Make, Model and Manufacturer properties. It wouldn’t make sense for any of these properties to be changed after they’re assigned, right?

'@Folder("Examples.ReadOnlyInReferencingProject")
'@Exposed
Option Explicit

Private Type TCar
    Make As Long
    Model As String
    Manufacturer As String
End Type
Private this As TCar

Public Property Get Make() As Long
    Make = this.Make
End Property

Friend Property Let Make(ByVal value As Long)
    this.Make = value
End Property

Public Property Get Model() As String
    Model = this.Model
End Property

Friend Property Let Model(ByVal value As String)
    this.Model = value
End Property

Public Property Get Manufacturer() As String
    Manufacturer = this.Manufacturer
End Property

Friend Property Let Manufacturer(ByVal value As String)
    this.Manufacturer = value
End Property

The seldom-used Friend access modifier makes the Model property read-only, at least for code located outside the VBA project this Car class is defined in: the Property Let member is only accessible from within the same project. However, a CarFactory class defined in the same VBA project can access the Friend members:

'@Folder("Examples.ReadOnlyInReferencingProject")
'@PredeclaredId
'@Exposed
Option Explicit

Public Function Create(ByVal carMake As Long, ByVal carModel As String, ByVal carManufacturer As String) As Car
    Dim result As Car
    Set result = New Car
    result.Make = carMake
    result.Model = carModel
    result.Manufacturer = carManufacturer
    Set Create = result
 End Function

Because this CarFactory class has a PredeclaredId attribute set to True, the referencing VBA code can do this:

'@Folder("VBAProject")
Option Explicit

Public Sub DoSomething()
    Dim myCar As Car
    Set myCar = CarFactory.Create(2016, "Civic", "Honda")
    
    MsgBox "We have a " & myCar.Make & " " & myCar.Manufacturer & " " & myCar.Model & " here."
    'these assignments are illegal here, code won't compile if they're uncommented:
    'myCar.Make = 2014
    'myCar.Model = "Fit"
    
End Sub

And then the myCar object can’t be turned into a 2014 Honda Fit – not even by accident. Now that’s great, but more often than not, it’s within the project that we’d like to enjoy compiler-validated immutability – the problem is that within the project that defines the Car class, the Friend access modifier might as well be Public, for within that project, anything anywhere is able to access the Property Let members and turn our 2016 Honda into a 2017 Nissan.

If classes and public properties were all we had in our toolbox, that’s as far as we could get. Fortunately, VBA has more tricks up its sleeves.


Interface

In VBA a class module’s Public members define the default interface of an instance of that class, and while any other class can theoretically implement any other class’ default interface, in practice we actually use dedicated class modules to define formal abstract interfaces (just method stubs, no implementations) – to make sure things are confusing for everyone, we also call these special class modules… interfaces. In .NET we would use the interface keyword instead of class; in VBA we just use class modules for both.

For example we could add another class module, call it ICar (or whatever – but it’s typical if not expected to have abstract interface class names prefixed with an I), and then let it define the Get accessors we want the world to see:

'@Folder("Examples.ReadOnlyEverywhere")
'@Interface
Option Explicit

Public Property Get Make() As Long
End Property

Public Property Get Model() As String
End Property

Public Property Get Manufacturer() As String
End Property

One Interface, One Implementation: Caution!

It’s very much frowned upon in object-oriented code, to define an explicit abstract interface only to have one single class implement it: it’s a design smell because it makes things more complicated than they need to be… provided that the language has constructors and the ability to encapsulate readonly fields… which VBA does not.

So we’re going to bend the rules a bit here, tweak the accepted wisdom a bit: what we’re about to do is indeed going to enable polymorphism, but we’re not going to cover that here. For now we’re going to leverage interfaces for their ability to shape an object the way we need it to be, but it needs to be mentioned that in well-written OOP code, sticking an I in front of a class’ name and calling it an abstract interface is… not it – but that would be the subject of a discussion about abstraction levels, and abstraction in general: we’re just focusing on the mechanics here.


Implementation

In VBA we use the Implements keyword in a class module’s declarations section to tell the compiler that the class can be used with a particular interface. When we do that, we must implement every member of the interface we specified: not implementing them all would be a compile-time error.

Document Modules: Don’t.

While VBA will compile an Implements statement in any class module and that ThisWorkbook and worksheet modules are such modules, these document modules are also a special kind of class that’s best left handled by the host application that owns them: they will not be happy with implementing user classes. Corrupted project and sudden crash unhappy, I mean: whatever you do, do not use Implements in a document module’s code-behind. There are ways to work around this, using wrapper classes for example, where another class (the wrapper) implements the interface and talks to the worksheet.


So we have an ICar abstract interface that says any object implementing that interface has read-only properties Make, Model, and Manufacturer. The implementation might look like this – note this is the ReadOnlyCar class in the example code, but it could very well be the Car class above; I’ve kept them distinct to make the example code easier to follow along this article.

'@Folder("Examples.ReadOnlyEverywhere")
'@PredeclaredId
'@Exposed
Option Explicit
Implements ICar

Private Type TCar
    Make As Long
    Model As String
    Manufacturer As String
End Type
Private this As TCar

Public Property Get Make() As Long
    Make = this.Make
End Property

Friend Property Let Make(ByVal value As Long)
    this.Make = value
End Property

Public Property Get Model() As String
    Model = this.Model
End Property

Friend Property Let Model(ByVal value As String)
    this.Model = value
End Property

Public Property Get Manufacturer() As String
    Manufacturer = this.Manufacturer
End Property

Friend Property Let Manufacturer(ByVal value As String)
    this.Manufacturer = value
End Property

Private Property Get ICar_Make() As Long
    ICar_Make = this.Make
End Property

Private Property Get ICar_Manufacturer() As String
    ICar_Manufacturer = this.Manufacturer
End Property

Private Property Get ICar_Model() As String
    ICar_Model = this.Model
End Property

If we changed the return type of CarFactory.Create to the abstract ICar instead of the concrete Car, and made it return a New ReadOnlyCar reference, any existing calling code wouldn’t flinch, because the interface serves as a separation between the concrete class and the code that’s using it: it reduces the coupling and that makes the code more flexible – that factory could setup and return any implementation of the ICar interface, and as long as we adhere to the Liskov Substitution Principle (LSP), we are guaranteed to find a manufacturer in the Manufacturer property, a year in the Make property, and a model name in the Model property, because that’s what the “contract” of the ICar interface entails.

Notice the implementation is always Private? You will never ever want to change that: these methods are not meant to be exposed on the class’ default interface. That’s what the Implements keyword accomplishes: it tells VBA to expect (require, actually) certain specific members in that class. When an instance of the class is accessed through its ICar interface, what the code is seeing is the public ICar.Model, not the private ReadOnlyCar.ICar_Model.

Underscores: Don’t.

Notice the members implementing the interface always have that Interface_Member naming scheme? That underscore matters, possibly due to a bug in the VBA compiler, but if you try to make an interface with some Public Sub Do_Something() method, …VBA will refuse to recognize Private Sub IThing_Do_Something() as an implementation of that method. You should be avoiding underscores in VBA identifier names in general, anyway.


Factory Method

Depending on where we are in an OOP project, coupling with a concrete type can be perfectly fine. For example in the composition root at the entry point of a program, where objects and their dependencies are being created, we have no choice but to know about the concrete types – that doesn’t mean the rest of the code needs to know about them too though.

What we’re going to do here, is put everything we’ve seen above into practice, by simply moving the Create method from the factory class into the ReadOnlyCar class itself, and make the function return the ICar interface:

Public Function Create(ByVal carMake As Long, ByVal carModel As String, ByVal carManufacturer As String) As ICar
    Dim result As ReadOnlyCar
    Set result = New ReadOnlyCar
    result.Make = carMake
    result.Model = carModel
    result.Manufacturer = carManufacturer
    Set Create = result
End Function

Because the class has a VB_PredeclaredId attribute set to True, we get a free, global-scope default instance… that we’re going to keep stateless: it’s meaningless to assign that particular instance any values for its Make, Model, or Manufacturer properties. But that stateless default instance can be used as a factory by a referencing project if we make the class public, or by any other code that needs to create an instance of a ReadOnlyCar:

Dim myCar As ICar
Set myCar = ReadOnlyCar.Create(2014, "Honda", "Fit")
'myCar can only access the ICar members here.

Nothing can prevent us from creating a New ReadOnlyCar, but the Create factory method is more compelling to use, and now code that needs to initialize a series of ICar objects looks much cleaner than without.


What to use When

As we’ve seen, a factory method is useful when coupling isn’t a concern, and for all intents & purposes can be considered VBA’s take on parameterized object construction. A factory class is useful when the setup of an object is complex enough to warrant being pulled out of the class as its own responsibility, for it also shouldn’t be used when coupling matters. An abstract factory however, should be used when decoupling is needed (that would be when the class using the factory needs to be unit-tested but the factory then needs to supply an alternative implementation for testing purposes), and is a powerful tool in the injection of dependencies that cannot be initialized at the composition root. Big scary words? Read up on Dependency Injection in VBA!

Your project may not (probably doesn’t) need such complete decoupling, and that’s perfectly fine: OOP with tightly-coupled dependencies is still OOP – yes, even without any unit tests, and adhering to all SOLID principles is an art more than a science – but merely knowing that these techniques exist and what they are used for, will change how you reason about code: it’s no longer all about what the code does, it’s now also about how the components interact with each other, what responsibilities each object has; as the abstraction level increases, when to split things up becomes more and more obvious, and it all begins with interfaces and a better understanding of the nature of classes – once encapsulation is mastered, we can move on to explore abstraction; once abstraction is mastered, polymorphism will come much more easily. Factories being creational patterns (there are others), they make a perfect introduction to every single one of these concepts.


ThingFactoryFactory

Sometimes creating an object involves several components – in this simplified example we are creating cars with a few values, but what if creating an ICar object required us to provide some Engine object, which itself had its own dependencies? This is a contrived (and possibly bad) example, so bear with me, but let’s say every new ICar object needed to be injected with the same Engine instance… okay, definitely a bad example – the idea is that if every object ever created by a factory class needs a reference to some other object or value, then it becomes redundant to supply that reference or value through the factory’s ICar_Create method parameters.

Let’s say a car factory can only ever create new cars (hmm, what a crazy idea!) – taking in a carMake parameter for the year of manufacturing makes no sense then. And if a factory is making Nissan cars, they’re probably not making Ford or Toyota cars, so the carManufacturer parameter is really a property of the factory. Let’s make a simpler ISimplerCarFactory abstract factory interface that only takes the parameter we actually need: the carModel.

'@Folder("Examples.ReadOnlyEverywhere.AbstractFactory")
'@Interface
Option Explicit

Public Function Create(ByVal carModel As String) As ICar
End Function

Now we can see the actual benefits start to emerge – code using such a factory will be able to create an ICar without needing to specify a carManufacturer or a carMake; the factory implementation is now responsible for providing them:

'@Folder("Examples.ReadOnlyEverywhere.AbstractFactory")
'@PredeclaredId
Option Explicit
Implements ISimplerCarFactory

Private Type TFactory
    Manufacturer As String
End Type

Private this As TFactory

Public Function Create(ByVal carManufacturer As String) As ICarFactory
    Dim result As ManufacturerCarFactory
    Set result = New ManufacturerCarFactory
    result.Manufacturer = carManufacturer
    Set Create = result
End Function

Public Property Get Manufacturer() As String
    Manufacturer = this.Manufacturer
End Property

Public Property Let Manufacturer(ByVal value As String)
    this.Manufacturer = value
End Property

Private Function ISimplerCarFactory_Create(ByVal carModel As String) As ICar
    Dim result As ReadOnlyCar
    result.Manufacturer = this.Manufacturer
    result.Make = DateTime.Year
    result.Model = carModel
    Set ISimplerCarFactory_Create = result
End Function

As you can see, we’re now looking at a ManufacturerCarFactory class that can take its own dependencies, and thus has its own Create factory method that encapsulates them in private instance state. The advantages of such abstraction should become apparent now:

'@Folder("Examples")
Option Explicit

Public Sub DoSomething()
    
    ' let's make a factory that creates brand new cars whose Manufacturer is "Honda"
    Dim factory As ISimplerCarFactory
    Set factory = ManufacturerCarFactory.Create("Honda")
    
    ' let's make a bunch of cars
    Dim cars As Collection
    Set cars = CreateSomeHondaCars(factory)
    
    ' ...and now consume them
    ListAllCars cars
    
End Sub

Private Function CreateSomeHondaCars(ByVal factory As ISimplerCarFactory) As Collection
'NOTE: this function doesn't know or care what specific ISimplerCarFactory it's working with.
    Dim cars As Collection
    Set cars = New Collection
    cars.Add factory.Create("Civic")
    cars.Add factory.Create("Accord")
    cars.Add factory.Create("CRV")
    Set CreateSomeCars = cars
End Function

Private Sub ListAllCars(ByVal cars As Collection)
'NOTE: this procedure doesn't know or care whas specific ICar implementation it's working with.
    Dim c As ICar
    For Each c In cars
        Debug.Print c.Make, c.Manufacturer, c.Model
    Next
End Sub

Running this code produces this output:

 2020         Honda         Civic
 2020         Honda         Accord
 2020         Honda         CRV

The Make and Manufacturer properties of every ICar issued by this abstract factory, are provided by the factory, such that none of this code needs to worry about these values. If we wanted CreateSomeCars to make Ford models instead, we would be giving it an ISimplerCarFactory implementation that would have been created with ManufacturerCarFactory.Create("Ford").


Back on Earth

Discussions around OOP design patterns often turn to highly-abstracted components described in vague terms (“model-view-controller”, “repository”, “unit-of-work”, “command”, etc.) that, coming from procedural programming, feel convoluted and perhaps hard to follow. The sheer amount of class modules involved feels like nonsense, how does anyone even work with that many modules in a VBA project!

While Rubberduck’s Code Explorer and many other navigational enhancements completely address the code organization concerns, the fact remains that not all VBA code needs that much abstraction. The goal isn’t to learn how to write a macro here – the goal is to learn how VBA (and yes, VB6) code can scale to software-level projects. Small, perfectly-working and decently maintainable applications might have been written with a procedural paradigm, but OOP wouldn’t have been invented if scaling that up didn’t come with a number of design problems that demanded solutions – OOP design patterns propose upping the abstraction level and generalizing various common programming problems: that’s why they feel so far removed from cold-headed immediate applicability if you’re coming from small procedural projects and are just curious about classes and object-oriented code… it all feels overwhelmingly complicated stuff, with vague theoretical advantages that some praise and some others dispute, and sometimes rather energetically so.

Truth is, you don’t learn OOP by writing an ERP System, not anymore than you learn to swim by crossing the Atlantic. No project is too small to put these principles into application – sure the smaller the project the more silly & overkill having that much abstraction looks, but if you never cut your teeth on something small and keep OOP principles for the day you would actually need them, you may not have all the tools in your toolbox when you need them. Plus, it’s much easier to organically grow a code base that’s designed to scale in the first place, and then OOP principles being language-agnostic, what you’re learning here isn’t VBA, it’s Object-Oriented Programming, and that will stay with you well after you’ve moved on to, say, TypeScript.

23 thoughts on “OOP in VBA: Immutability & The Factory Pattern”

  1. Not to muddy the waters too much, but that’s not really a singleton. There can only ever be one instance of a singleton. PredeclaredId and GlobalNamespace just provide a default instance. You can create other named instances of you wish. Great write up. I’ve been meaning to write something like this for a while, you beat me to it.

    Liked by 1 person

    1. Not exactly a Singleton indeed, but as far as client/referencing code goes (assuming it’s a separate VBA project), it can’t be new’d up, so the default instance is the only instance that will ever be created – I’d call it VBA’s Singleton 😉

      Liked by 2 people

  2. It was not real clear to me what had been achieved until I read the code about 10 times. This is what I understand. A class factory creates objects with some properties that were set at the time of creation and can’t be changed later on by the code that uses the objects.

    I once failed a job interview on the what is a class factory question so I have been looking for a clear answer for a while.

    Liked by 1 person

  3. Sorry to come to this quite late but as a newbie to VBA I’ve been scratching my head over this for some time. I think the statement
    ‘And then the myCar object can’t be turned into a 2014 Honda Fit – not even by accident.’
    is incorrect.
    My reasoning for this is that the properties used in the create function require public setters which in my uinderstanding remain valid once the object has been returned, which means that without additional code it is all too easy to change the Make, Model and manufacturer.
    It is simple to add code to make the properties immutable after the first assignment (we can include code to thes the internal property for its null value (the default value at creation) and to not do the assigment if it isn’t)
    The downside of this is that intellisense will still show the existence of a setter when in fact what we really want is the absence of a setter.
    Is my understanding correct or should I just stand in the corner wearing a pointy hat?

    Liked by 1 person

    1. The point is that the code that consumes a Car instance needs to work off the ICar interface, which doesn’t expose the setters. You code against the interface, not the concrete type: only the factory needs to know about the concrete type.

      Liked by 1 person

  4. OK I get it now. Its because the creator of the car object is in a different project to the consumer of the car object and the Friend qualifier on the setter restricts the visibility of the setter to the project in which it is located.

    I missed this because as I mainly VBA within Word I’m only really ever working within one project.

    Given the advantages you’ve demonstrated with the Friend qualifier it looks like I’m going to have to divide (code in multiple dot files) if I am to conquer!!!

    Liked by 1 person

    1. Yes… but no. If the consumer only ever cares about ICar, then it never gets to see the setters. The Friend modifier does enforce the get-only accessibility across projects though, but the main point is that the client code does not work with the Car class: it only cares about ICar.

      Liked by 1 person

  5. I’m curious. Why not just using conditional logic in the setters to get immutable types? For example, I wrote code like this in a class module:

    Public Property Let name(value As String)
    If pName = Empty Then
    pName = value
    Else
    Err.Raise Number:=nameErr, Description:=”Name is set and cannot be reset”
    End If
    End Property

    If I create an instance of this class from a factory method and set the property, it’s essentially immutable isn’t it?

    Like

    1. Sort of. It’s moving the problem from compile-time to run-time though. With a get-only interface the compiler will refuse to do foo.name = “bar”, because name simply has no Property Let mutator that can do this. With conditionals like this, the compiler will be happy to let you do it, and only at run-time will you go “oh, snap”. At the moment I can’t think of a single instance of something I’d prefer to blow up at run-time for, vs compile-time, given the choice. It’s all about leveraging the compiler mechanics.

      Liked by 1 person

  6. Hi Mathieu,
    Is it possible for you to demonstrate a working example of this post (especially about Factory class) as an Excel file, to make my understanding clear about Friend access modifiers, accessing the class from another VBProject, creating a Factory class?

    This knowledge will be really helpful for my project.
    Thanks.

    Like

    1. Hi there, thanks for the feedback! Have you seen the Battleship post series? It demonstrates a number of patterns, including Factory Method – and the full source is on GitHub: https://github.com/rubberduck-vba/Battleship

      Note, I’ve yet to update that code to catch up with Rubberduck’s annotations, and if you download the .xlsm you’ll want to remove the “freeze panes” on the title and game sheets (it’s causing Excel to spike CPU usage for some reason).

      Like

  7. I’m glad you pointed me back to this article on FB — reading the section Document Modules: Don’t, saved me from making a grave mistake – reading through this I was just thinking about using the Implements on a worksheet! {whew}! You mentioned that it could be accomplished with a wrapper class, do you have a post covering that topic?

    Like

    1. “There is no worksheet” (https://rubberduckvba.wordpress.com/2017/12/08/there-is-no-worksheet/) is along these lines, but I need to update that article as well… the general idea is sound, but I’m not satisfied with the result.. feels more complex than it really is – the read is still worth it, but I wouldn’t do it like this if I had to wrap worksheet modules today.
      Also worth noting, if the purpose of wrapping is to enable testability without needing to actually hit a real worksheet, Rubberduck will eventually have a mocking framework that will make it unnecessary, since worksheets can be mocked directly. Of course wrapper classes are a useful technique regardless, e.g. to preserve early binding when using a late-bound API that you can’t reference directly for whatever reason.

      Like

  8. Mathieu, great content like always! This was my 5th time reading it, this time around it made way more sense!

    For my own sanity, in ThingFactoryFactory shouldn’t this code:

    Dim result As ManufacturerCarFactory

    Really read:

    Dim result As New ManufacturerCarFactory

    And:

    Dim result As ReadOnlyCar

    Should really read:

    Dim result As ReadOnlyCar

    Otherwise you get runtime errors, or am I missing something??

    Like

    1. Did you miss the part about the VB_PredeclaredId attribute? With Rubberduck you can do that by specifying a @PredeclaredId annotation comment at module level, and then using code inspections to automatically synchronize the value of the hidden attribute.

      Classes with a VB_PredeclaredId attribute set to True have a default/predeclared compile-time instance that’s named after the class itself. That’s how UserForm1.Show works btw.

      I don’t recommend declaring anything “As New” 😉

      EDIT: hmm, re-reading, that part looks like it’s untested air-code – you’re right `result` should be initialized proper.

      Like

  9. Just a small fix required in module:AbstractFactoryExample
    Private Function CreateSomeHondaCars(ByVal factory As ISimplerCarFactory) As Collection
    ‘NOTE: this function doesn’t know or care what specific ISimplerCarFactory it’s working with.
    Dim cars As Collection
    Set cars = New Collection
    cars.Add factory.Create(“Civic”)
    cars.Add factory.Create(“Accord”)
    cars.Add factory.Create(“CRV”)
    ‘ Set CreateSomeCars = Collection
    Set CreateSomeHondaCars = cars
    End Function

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s