ExcelBanter - Avoiding duplication in objects with large commonality

ExcelBanter (https://www.excelbanter.com/)

- Excel Programming (https://www.excelbanter.com/excel-programming/)

- - Avoiding duplication in objects with large commonality (https://www.excelbanter.com/excel-programming/317334-avoiding-duplication-objects-large-commonality.html)

Andrew[_16_]

Avoiding duplication in objects with large commonality

I am implementing an object structure which consists of a number of
objects and each of those objects should be accessed via a collection
class. For example:

Joints.Item("JointName").JointProperties
Pipes.Item("PipeName").PipeProperties
etc.

The properties in each of the collection classes are always very
similar - consisting of .Count and .Item (which returns a pointer to
the child object).
At the moment I have created a new class for each of the collections
and duplicated the collection code in each. This seems quite
inefficient and prone to mistakes if I ever decide to make a change to
the way I deal with collection objects.

Is there any neater way of doing this? I'm not sure whether I can do
anything with the "Implements" keyword but it looks like this is more
for creating a common interface rather than common base code.

Thanks a lot for your time,
Andrew

Jamie Collins

Avoiding duplication in objects with large commonality

(Andrew) wrote ...

I am implementing an object structure which consists of a number of
objects and each of those objects should be accessed via a collection
class.

I'm not sure whether I can do
anything with the "Implements" keyword but it looks like this is more
for creating a common interface rather than common base code.

VBA supports polymorphism via Implements whereas you are looking for
more traditional inheritance which VBA does not support. I have a
standard collection class 'template' from which I change the class
name each time. And, because I have the usual default member and
NewEnum frigs, I have to do this in a text editor else risk losing
them.

In case that last comment made no sense you can 'neaten' your syntax
to

Joints("JointName").JointProperties
Pipes("PipeName").PipeProperties
etc

by making Item the default member of the class. Because this Attribute
property is invisible in VBA, you have to export the class module to a
file, open it in a text editor (e.g. Notepad) and add the magic line:

Public Property Get Item(ByVal Index As Variant) As CColumn
Attribute Item.VB_UserMemId = 0 ' <<<<< magic line
Set Item = m_colColumns.Item(Index)
End Property

(note must be Public - not Friend - and the keyword 'Item' in the
magic line must match the procedure name). While in the text editor,
you may as well add the following, which contains *two* magic lines:

Public Property Get NewEnum() As IUnknown
Attribute NewEnum.VB_UserMemId = -4
Attribute NewEnum.VB_MemberFlags = "40"
Set NewEnum = m_colColumns.[_NewEnum]
End Property

The above allows a For Each loop to be performed on the collection
class. Save in the text editor and re-import the class to the VBA
project.

Jamie.

--

Jamie Collins

Avoiding duplication in objects with large commonality

(Andrew) wrote ...

Re the tweaks that you mention - I had read that these lines can
sometimes get overwritten when making changes to your code so I have
tended to steer away from them. Have you had any problems with this?
Maybe it is only an issue if you change the actual collection class
object?

Yes but only occasionally and it's not too much of a pain to put them
back in. I think you have to change the procedures themselves (e.g.
add white space then delete could do it) to erase the hidden lines.

I changed my template so that the two sub procedures with the hidden
lines are together and are straddled by the _initialize and _terminate
events (no white space) which I amend rarely and with care. the
procedures themselves never need to change.

Definitely worth the extra time and trouble.

Jamie.

--

All times are GMT +1. The time now is 05:23 PM.