Pass argument in class initialise

[tiredofit]

Further to this post:

Pass argument to class initialize

This code is taken from here: https://newbedev.com/pass-arguments-to-constructor-in-vba I can't get it to work. My understanding is as follows: This goes into a standard module: Sub Test Dim a As Employee Set a = Factory.CreateEmployee("Excel", 100) End Sub This goes...

www.mrexcel.com

the code is as follows:


APPROACH 1.

' STANDARD MODULE

Sub Test()

    Dim a As Employee
    Set a = CreateEmployee("Excel", 100)
  
End Sub

Public Function CreateEmployee(name As String, age As Integer) As Employee

    Set CreateEmployee = New Employee
    CreateEmployee.InitiateProperties name:=name, age:=age

End Function

and:

' CLASS MODULE EMPLOYEE

    Private m_name As String
    Private m_age As Integer
  
Public Sub InitiateProperties(name As String, age As Integer)

    m_name = name
    m_age = age

End Sub

Private Sub Class_Initialize()

End Sub

When the above code is run, the moment this line is reached:

Set CreateEmployee = New Employee

it jumps to the Class_Initialize, WITHOUT passing any arguments.


But if I wrote the code, "in the usual way", like this:

APPROACH 2.

'STANDARD MODULE

Sub Test()

    Dim a As Employee
    Set a = New Employee
   
    a.name = "Excel"
    a.age = 10
   
End Sub

and:

' CLASS MODULE EMPLOYEE

    Private m_name As String
    Private m_age As Integer

Public Property Get name() As String
   
    name = m_name
   
End Property

Public Property Let name(ByVal n As String)

    m_name = n
   
End Property

Public Property Get age() As Integer

    age = m_age
   
End Property

Public Property Let age(ByVal a As Integer)

    m_age = a
   
End Property

Private Sub Class_Initialize()

End Sub

when this line is reached:

Set a = New Employee

it also jumps to the Class_Initialize, WITHOUT passing any arguments.

So how is the first approach "passing arguments" when initialising?

Thanks

 

[StephenCrump]

This is a better link: Pass arguments to Constructor in VBA

So how is the first approach "passing arguments" when initialising?

The code isn't passing anything to Class_Initialize. I'm not sure where you got that idea.

It's passing all the arguments required to populate an instance of the Employee class in one go, rather than one by one.

'Employee Class Module
Private m_name As String
Private m_age As Long
'Compare this:
Public Sub InitiateProperties(Name As String, Age As Long)

    m_name = Name
    m_age = Age

End Sub
'... with the "usual":
Public Property Let Name(s As String)
    m_name = s
End Property
Public Property Let Age(i As Long)
    m_age = i
End Property

 

[tiredofit]

Thanks for the link but it's the same as my original post!

"It's passing all the arguments required to populate an instance of the Employee class in one go, rather than one by one."

So is the advantage that it's faster to pass all in one go, as opposed to the standard way?

My interest in this is to compensate for the lack of a constructor in VBA.

 

[StephenCrump]

Thanks for the link but it's the same as my original post!

Yes, same link ultimately. Mine is a direct link to the article where you got your code. Your link above was to a MrExcel thread that provide that link, but didn't add anything useful.

My interest in this is to compensate for the lack of a constructor in VBA.

Yes, that's the key point. VBA doesn't have a constructor, i.e. you can't pass arguments to Class_Initialize. We're all dealing with that.

I'm not clear whether you're trying to code something, or just trying to understand it conceptually. How far you take this is up to you - do you want to run some office/home working code, or build a big factory?

I'd point you to some other articles, but it looks that's been done before: Class Factory

 

[tiredofit]

I'm trying to get to grips with the various concepts surrounding object oriented programming in VBA.

I've scoured the internet for what little material there is, most VBA books just mention class modules at best.

Websites that explain OO, as well as books such as the Head First series, tend to focus on Java or C# (understandly because VBA is not totally OO).

I have yet to read anything (geared towards VBA) about how one might plan to write an application in VBA in an OO way, ie how many classes will be needed, what they'll be doing and how might they interact / refer top each other.

Perhaps you could help and give your thoughts on this other post of mine:

Object oriented reuse

I have a conundrum I hope someone can help me. One of the merits of object oriented and classes is reusability. From my understanding about OO, data and actions "gets packaged" into its own object. Let's say every object in my program contains 1 property and 1 method. Now object1 has data1...

www.mrexcel.com

Thanks

 

[StephenCrump]

Perhaps you could help and give your thoughts on this other post of mine:

I did see that thread and thought about replying, but didn't because I couldn't make head or tail of the question. If others are also struggling, that may be why you've had no answers.

I think you were talking about different objects, rather than different instances of the same object. And referring to a method, let's say .AddItem, that both objects might have in similar form.

But you totally lost me when you said: Does that mean method1 needs to be copied and relabelled as method2, then "packaged" into object2?

 

[tiredofit]

I did see that thread and thought about replying, but didn't because I couldn't make head or tail of the question. If others are also struggling, that may be why you've had no answers.

I think you were talking about different objects, rather than different instances of the same object. And referring to a method, let's say .AddItem, that both objects might have in similar form.

But you totally lost me when you talked said: Does that mean method1 needs to be copied and relabelled as method2, then "packaged" into object2?

I am talking about different objects.

From what I've read, every class should only do one thing alone and be self-contained, so It should have its own methods and properties.

Imagine I have object1 and it has method1 (say which deletes column A) and property1 (say a name, Apple).

But object2 also deletes columns but is called Orange.

As both methods are identical, in the context of self-sufficiency, it seems to me I would have to replicate method1 to put it into object2, which is efficient.

On the other hand, if object2 could somehow use method1, that breaks "the rule" of self-sufficiency.

Hope this makes sense.

 

[RoryA]

It sounds like you are confusing classes and objects.

Your example, which I suspect is oversimplified, would suggest having one class with a method and a Name property. You then create two instances of that class (objects) and assign different values to the Name of each.

 

[tiredofit]

It sounds like you are confusing classes and objects.

Your example, which I suspect is oversimplified, would suggest having one class with a method and a Name property. You then create two instances of that class (objects) and assign different values to the Name of each.

Yes, it is oversimplified.

I'll try and dig up a more concrete example.