RoGKôT
RoGKôT

Reputation: 29

VBA OOP Class conception... distinct Factory with redundant code or a factory who decide which to build?

I "play" with classes, Factory, Immutable object and so on! I take my references from VBA RubberDuck blog. But seems complicated to ask questions there... So I came to my favorite code issue solver's salvier... Stack Overflow

Let's say I have a variable... I will call it member as distinct for variant I use in the project so less confusing, I hope.

So a member have a {Variant|Object|String} pointer who point's to an address in memory from which we can deduce type and name of.

cPointer and iPointer classic classes

tPointer

Factory.Create(Value) with select case VarType(Value)

OR

Factory.Create(Address, Value) [Address] = `{Var|Obj|Str}Ptr`([Value]) and [Value] *only to set Type and Name of [Value]*

OR

Factory.Create_VariantPointer(Value)

BUT... also have

cPointers and iPointers

tPointers

  1. Which factory example should I use?

  2. 1 Factory with 3 Create or 3 factories

I think to be OOP like, it should be Pointer.Variant.Create(Value)

  1. Same questions for the Build procedure of the cPointer

Once this part is resolved, I have another issue.

I try implementing a debug member :The type member [tPointer|tPointers] used in the class

Pointer's Create function looks like:

Public Function Create(Value) As Pointer.iPointer
 Dim new_pointer as Pointer.cPointer

 Set new_pointer = new cPointer
 new_pointer.Build Value
 a11Dbug = new_pointer.DbugiT 'Both are [tPointer]
 Set Create = new_pointer
End Function

This is how I use it now so the Build procedure do the selection of which address to return. And in the Pointers class I use it like:

Set this.VariantPointer = Pointer.Factory.Create(Value)
  1. Seems correct for me but I want to knows other vision.

The other big issue is that the Pointers members Type are [iPointer]... what makes me loose Dbug information usually store in a plain type easily displayed in the locals windows when debugging BECAUSE the iPointer interface blocks me from DbugiT Friend Property of Pointer class

  1. I think that the Dbug information will be accessible only in single object and the "collection" classes not... without breaking the immutable state.

  2. I also think of a property in the iDbug interface... but it opens a breach in Dbug mode... does this is considerable in terms of hacking... I think not as compiled without the "breach" code.

  3. Final question... Does empty procedure slow down program?

    Public Sub AssertionIsEqual(this, that) #if Dbug then Debug.Assert (this = that) #endif end sub

When compiled, the calls to the assert procedure will find an empty procedure.

That's all for now folks! Thanks in advance for the time taken to answer me!

Edit:

Not possible to add a property in iDbug as Type cannot be the same for all and coercion to Variant blocks me... any workaround possible?

Upvotes: -1

Views: 38

Answers (0)

Related Questions