473,544 Members | 1,334 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Try #2 - Inheritance work-around in VBA

Recently, I tried and did a poor job explaining an idea I've had for handling
a particular case of implementation inheritance that would be easy and obvious
in a fully OOP language, but is not at all obvious in VBA which lacks
inheritance. I'm trying the explanation again now.

I often find cases where a limited form of inheritance would eliminate
duplication my code that seems impossible to eliminate otherwise. I'm getting
very rigorous, now, about duplication because a seroius source of bugs when
code is modified later on. After you try being rigorous about it, then try to
work on code that's not written that way, you'll quickly see what I mean.

So, the specific case of inheritance I'm talking about is a base class that
contains the majority of the code and interfaces needed for an operation, but
there needs to be several minor variations on that operation, mainly
comprising attributes and functionality internal to the operation, not exposed
to external code.

Say I have an application in which the code frequently needs to retrieve the
ID of an item in a lookup table given the name, and automatically insert the
item first if it doesn't exist. Now, say I need to do this same operation for
many different tables at different times. Let's also assume that, in this
application, each table has a hard meaning known to specific parts of the
code. We are not addressing working with collections of types abstractly in
loops, etc. (that would be another layer with another solution).

If we had inheritance capability in the language, the design pattern would be
obvious. The base class (the Abstract class) contains the logic, and an
inheriting class (the Concrete class) for each lookup table provides values to
the base class for table name, name field, and ID field. The Abstract class
provides virtual (not implemented in the base class) private members for the
Concrete elements, and each Concrete class provides the implementations of
those, so the code in the Abstract class can access them.

The way inheritance is normally simulated in languages like VBA is that the
Concrete class encapsulates (contains a reference to) the Abstract class, and
provides external access to the Abstract class' members via a wrapper method
for each. For the situation I've described, that's a total mess, which is why
this case is such a prolem and in need of this solution; it adds as much
duplication as it removes. Every Concrete class has to implement and expose
all of its concrete members (that external code doesn't need) plus a wrapper
for every single public member of the Abstract class (that the Concrete class
doesn't implement).

My solution is to invert the encapsulation, so that the "Abstract" class
encapsulates the "Concrete" class. The external code interacts with the
"Abstract" class directly, and that class invokes the "Concrete" class to
obtain the specifics for the case at hand.

Working code example follows. Note that the concrete class could provide
processes (such as special initialization) as well as static properties.
-- basTests

Option Compare Database
Option Explicit

Public Function GetNewLookupVal ueList( _
objValueListCon crete As IValueListConcr ete _
) As clsLookupValueL ist
Dim objLookupValueL ist As New clsLookupValueL ist
objLookupValueL ist.Setup objValueListCon crete
Set GetNewLookupVal ueList = objLookupValueL ist
End Function

Sub RunTests()
With GetNewLookupVal ueList(New clsLookupValLis tColor)
Debug.Print .IdFromName("Bl ue")
End With

With GetNewLookupVal ueList(New clsLookupValLis tStyle)
Debug.Print .IdFromName("Ga udy")
End With
End Sub
-- clsLookupValueL ist --

Option Compare Database
Option Explicit
Private mobjConcrete As IValueListConcr ete
Private mdbs As DAO.Database
Private mrst As DAO.Recordset

Public Sub Setup( _
objValueListCon crete As IValueListConcr ete _
)
Set mobjConcrete = objValueListCon crete
End Sub

Private Property Get SelectSql() As String
With mobjConcrete
SelectSql = _
"SELECT " & _
.FieldNameId & ", " & _
.FieldNameItem & " " & _
"FROM " & _
.TableName
End With
End Property

Private Function GetRecordset() As DAO.Recordset
If mrst Is Nothing Then
Set mdbs = CurrentDb()
Set mrst = mdbs.OpenRecord set(SelectSql)
End If
Set GetRecordset = mrst
End Function

Private Property Get IdField() As DAO.Field
' Could be made public, but not needed now, so not exposed.
Set IdField = GetRecordset.Fi elds(mobjConcre te.FieldNameId)
End Property

Private Property Get ItemField() As DAO.Field
' Could be made public, but not needed now, so not exposed.
Set ItemField = GetRecordset.Fi elds(mobjConcre te.FieldNameIte m)
End Property

Public Function IdFromName(strN ame As String) As Long
Dim varResult As Variant
varResult = Null
With GetRecordset()
If .RecordCount > 0 Then
.FindFirst _
mobjConcrete.Fi eldNameItem & "=" & _
StringToSqlStri ngExpr(strName)
If Not .NoMatch Then
varResult = IdField.Value
End If
End If
If IsNull(varResul t) Then
.AddNew
ItemField.Value = strName
.Update
.Bookmark = .LastModified
varResult = IdField.Value
End If
End With
IdFromName = varResult
End Function

Private Function StringToSqlStri ngExpr(strStrin g As String) As String
StringToSqlStri ngExpr = "'" & Replace(strStri ng, "'", "''") & "'"
End Function

Public Function NameFromID(lngI D As Long) As Variant
Dim varResult As Variant
varResult = Null
With GetRecordset()
If .RecordCount > 0 Then
.FindFirst mobjConcrete.Fi eldNameId & "=" & lngID
If Not .NoMatch Then
varResult = IdField.Value
End If
End If
End With
NameFromID = varResult
End Function

Private Sub Class_Terminate ()
If Not (mrst Is Nothing) Then
mrst.Close
Set mrst = Nothing
End If
Set mdbs = Nothing
End Sub
-- IValueListConcr ete --

Option Compare Database
Option Explicit

Public Property Get TableName() As String
End Property

Public Property Get FieldNameId() As String
End Property

Public Property Get FieldNameItem() As String
End Property
-- clsLookupValLis tColor --

Option Compare Database
Option Explicit

Implements IValueListConcr ete

Private Property Get IValueListConcr ete_TableName() _
As String
IValueListConcr ete_TableName = "tblColor"
End Property

Private Property Get IValueListConcr ete_FieldNameId () _
As String
IValueListConcr ete_FieldNameId = "ColorID"
End Property

Private Property Get IValueListConcr ete_FieldNameIt em() _
As String
IValueListConcr ete_FieldNameIt em = "Color"
End Property
-- clsLookupValLis tStyle --

Option Compare Database
Option Explicit

Implements IValueListConcr ete

Private Property Get IValueListConcr ete_TableName() _
As String
IValueListConcr ete_TableName = "tblStyle"
End Property

Private Property Get IValueListConcr ete_FieldNameId () _
As String
IValueListConcr ete_FieldNameId = "StyleID"
End Property

Private Property Get IValueListConcr ete_FieldNameIt em() _
As String
IValueListConcr ete_FieldNameIt em = "Style"
End Property

Nov 12 '05 #1
14 12883
On Tue, 13 Apr 2004 07:20:06 GMT, Steve Jorgensen <no****@nospam. nospam>
wrote:

....
Correction
The way inheritance is normally simulated in languages like VBA is that the
Concrete class encapsulates (contains a reference to) the Abstract class, and
provides external access to the Abstract class' members via a wrapper method
for each. For the situation I've described, that's a total mess, which is why
this case is such a prolem and in need of this solution; it adds as much
duplication as it removes. Every Concrete class has to implement and expose
all of its concrete members (that external code doesn't need) plus a wrapper
for every single public member of the Abstract class (that the Concrete class
doesn't implement).


My intention was to say it is the standard solution that adds as much
duplication as it removes, not that my proposed solution adds as much
duplication as it removes <g>.
Nov 12 '05 #2
Steve Jorgensen <no****@nospam. nospam> wrote in
news:54******** *************** *********@4ax.c om:
On Tue, 13 Apr 2004 07:20:06 GMT, Steve Jorgensen
<no****@nospam. nospam> wrote:

...
Correction
The way inheritance is normally simulated in languages like VBA is
that the Concrete class encapsulates (contains a reference to) the
Abstract class, and provides external access to the Abstract
class' members via a wrapper method for each. For the situation
I've described, that's a total mess, which is why this case is
such a prolem and in need of this solution; it adds as much
duplication as it removes. Every Concrete class has to implement
and expose all of its concrete members (that external code doesn't
need) plus a wrapper for every single public member of the
Abstract class (that the Concrete class doesn't implement).


My intention was to say it is the standard solution that adds as
much duplication as it removes, not that my proposed solution adds
as much duplication as it removes <g>.


I'm beginning to get it, but I'm still bogged down in your example
implementation. The task you've set for yourself seems really simple
to me -- it's the kind of thing I do all the time by various
methods, but it's really a very elaborate DLookup(), but with the
added feature that it adds the value if it's not there already?

I'm not sure what value you've gotten from this complexity. How many
times do you really have to do this kind of thing? Assuming a
structure for all your tables that you're working with of ID field
and value field (variant?), then I just don't see where the code
duplication would come in. Working up from the simplest case, I end
up with the code after my signature.

Now, that could easily be generalized to returning any field based
on any criteria (via a parameter array), assuming you are returning
one field. It wouldn't produce horrid code, in my opinion, but you
would end up with a function overloaded with arguments that would
have to be passed in a very special format. That always leads me in
the direction of a class module, since that can document much more
easily what the requirements are for getting accurate data out of
it.

But I still don't see where there needs to be a base class and then
specific classes.

I very, very often write simply one-line wrapper functions around
complex class modules (most often when I need to use the output in a
query, which can't refer directly to class modules), and your
example concrete classes have only a very small number of
properties/methods/members.

So, I'm just not seeing where the benefit is here:

1. your example seems more easily implemented in a much more
straightforward manner

2. I'm not able to think of an example that isn't likewise going to
be simple like that.

Each time you choose an example, you pick table interaction as your
subject. Table interactions are, I think, pretty easy to deal with.
Indeed, I kept thinking while reading your code that I sometimes use
tables to map relationships between tables and data within those
tables (tables as storage structures that themselves drive the
behavior of code; that is, tables that don't store data about the
app's end-user viewed data, but that store information that is used
entirely to drive code operation). The most common example of this
that I'm sure many people have used is when importing/exporting data
you often use a table to map fields on one side to fields on the
other.

Now, where I get a glimmer of potential for this kind of thing is
with objects that are not generic (like tables), but that are
specific to a particular application, but that are used in multiple
ways. We have a certain amount of "pass-through" encapsulation
available to us if we, say, wrap a class module around a generic
form. We can expose the properties, methods and members of the
encapsulated form directly through a form-type property of the
encapsulating class (including custom properties/methods/members of
the encapsulated form), while also enhancing the encapasulated form
with additional propertis/methods/members.

It's not real inheritance, but it's exactly what you've described,
in that it's upside-down, placing the "abstract" class as a wrapper
around the "concrete" class (in this case, a form).

Now, you can do the same kind of thing with a class module, as
you've shown, in that one of the properties of the "abstract" class
returns a reference to the "concrete" class.

So, it sort of makes sense to me from a structural level, but your
specific examples are sort of sabotaging my ability to understand it
clearly.

And when described the way I've done above, it doesn't sound so
earth-shattering. But when you talk about using it with pure class
modules (not forms), it does seem to me to have value.

The key breakthrough for me here was thinking about the idea of
wanting to add a bunch of behaviors and properties to a lot of
objects of exactly the same type. When I looked at the concept of a
wrapper around a bunch of forms that added new capabilities to all
the forms thus encapsulated, it began to make sense.

But I think it's a mistake to talk about it as though it's
inheritance. It really isn't at all -- it's just a form of
encapsulation that gives you the same benefits in regard to
eliminating code duplication as pure inheritance does.

(Of course, I'm also assuming that I've finally understood!)

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Public Function idLookup(strLoo kupValue As String, _
strLookupField As String, strLookupTable As String, _
Optional ysnAdd As Boolean = True, _
Optional db As DAO.Database) As Long
Dim ysnReleaseDB As Boolean
Dim strSQL As String
Dim rs As DAO.Recordset
Dim strIDField As String

If db Is Nothing Then
Set db = CurrentDb()
ysnReleaseDB = True
End If
strIDField = Mid(strLookupTa ble, 4) & "ID"
strSQL = "SELECT " & strLookupTable & "." & strIDField
strSQL = strSQL & ", " & strLookupTable & "." & strLookupField
strSQL = strSQL & " FROM " & strLookupTable
strSQL = strSQL & " WHERE " & strLookupTable & "."
strSQL = strSQL & strLookupField & "='"
strSQL = strSQL & strLookupValue & "';"
Set rs = db.OpenRecordse t(strSQL)
If rs.RecordCount = 0 Then
If ysnAdd Then
rs.AddNew
rs(strLookupFie ld) = strLookupValue
rs.Update
End If
End If
If rs.RecordCount <> 0 Then
rs.MoveFirst
idLookup = rs(strIDField)
End If

rs.Close
Set rs = Nothing
If ysnReleaseDB Then Set db = Nothing
End Function
Nov 12 '05 #3
rkc

"David W. Fenton" <dX********@bwa y.net.invalid> wrote in message
news:Xn******** *************** ***********@24. 168.128.78...
Steve Jorgensen <no****@nospam. nospam> wrote in
news:54******** *************** *********@4ax.c om: But I think it's a mistake to talk about it as though it's
inheritance. It really isn't at all -- it's just a form of
encapsulation that gives you the same benefits in regard to
eliminating code duplication as pure inheritance does.

(Of course, I'm also assuming that I've finally understood!)


It's containment. Nothing more. Nothing less.
One object instantiates another object as a member variable and
uses that objects properties and methods internally. It's containment.
If the member object's properties and methods were exposed to
outside code it would be delegation. Delegation is what containment
avoids. Exposing the member objects properties and methods to
outside code usually involves adding properties and methods to the
containing class. That is what Steve sees as code duplication. It's
not. It's just the way it's done.

This msdn article shows a way to sort of/kind of extend interface
classes to do much the same thing. Once again it's a long way
around the barn for people who don't live and breath oop.

http://msdn.microsoft.com/library/de...lymorphism.asp





Nov 12 '05 #4
On Tue, 13 Apr 2004 15:21:28 GMT, "David W. Fenton"
<dX********@bwa y.net.invalid> wrote:
Steve Jorgensen <no****@nospam. nospam> wrote in
news:54******* *************** **********@4ax. com:
On Tue, 13 Apr 2004 07:20:06 GMT, Steve Jorgensen
<no****@nospam. nospam> wrote:

...
Correction
The way inheritance is normally simulated in languages like VBA is
that the Concrete class encapsulates (contains a reference to) the
Abstract class, and provides external access to the Abstract
class' members via a wrapper method for each. For the situation
I've described, that's a total mess, which is why this case is
such a prolem and in need of this solution; it adds as much
duplicatio n as it removes. Every Concrete class has to implement
and expose all of its concrete members (that external code doesn't
need) plus a wrapper for every single public member of the
Abstract class (that the Concrete class doesn't implement).
My intention was to say it is the standard solution that adds as
much duplication as it removes, not that my proposed solution adds
as much duplication as it removes <g>.


I'm beginning to get it, but I'm still bogged down in your example
implementation . The task you've set for yourself seems really simple
to me -- it's the kind of thing I do all the time by various
methods, but it's really a very elaborate DLookup(), but with the
added feature that it adds the value if it's not there already?


Again, this is a pattern to be used for removing duplication within a
sepecific application. This is not intended to be general-purpose, it's an
example of how the pattern might be used in a single app.

I chose a simple example on purpose, though not as simple as my first case.
Although what the class does is really just a DLookup, the code that uses the
class should be not have to know or care that that's what the implementation
is doing. That code should not need to know field names or table names, or
how to build criteria strings. In fact, if external code is aware of these
things and does them more than once, it is duplicating code, and what's being
duplicated is not something the compiler can check for you, so there is the
possibility of typos, cut/paste errors, and Search/Replace errors.
I'm not sure what value you've gotten from this complexity. How many
times do you really have to do this kind of thing? Assuming a
structure for all your tables that you're working with of ID field
and value field (variant?), then I just don't see where the code
duplication would come in. Working up from the simplest case, I end
up with the code after my signature.
The duplication is not in the lookup code, the duplication is in the
application code that uses it. That's why what I'm talking about is a design
pattern to be applied in a given application, not a library routine to be
reused across applications. Using your code in an application, then using
that code multiple times for tables with the same nature (lookup table), and
use it multiple times for the same table as well, the calling code has
duplication. Of course, calling your code from my example would very likely
be desirable to remove duplication in another direction presuming one did not
also want to cache the recordset which may or may not make sense in a given
app, but it's better that this also be something the calling code does not
need to know. If I want to cache or not cache my lookup table recordsets,
there should only be one place to make the change.

Let's say I end up making this a client/server app on a busy network, and I
want to use disconnected recordsets for lookup tables. With the code
following the pattern I've outlined, only the code in the "Abstract" class has
to change. Neither the calling code nor the Concrete classes has to change.
Now, that could easily be generalized to returning any field based
on any criteria (via a parameter array), assuming you are returning
one field. It wouldn't produce horrid code, in my opinion, but you
would end up with a function overloaded with arguments that would
have to be passed in a very special format. That always leads me in
the direction of a class module, since that can document much more
easily what the requirements are for getting accurate data out of
it.

But I still don't see where there needs to be a base class and then
specific classes.
The specific classes encapsulate combinations of attributes (and custom
behaviors if/when they are added later) and keep each combination in one and
only one place in the code. That's the sole reason for their existence
I very, very often write simply one-line wrapper functions around
complex class modules (most often when I need to use the output in a
query, which can't refer directly to class modules), and your
example concrete classes have only a very small number of
properties/methods/members.

So, I'm just not seeing where the benefit is here:

1. your example seems more easily implemented in a much more
straightforwar d manner

2. I'm not able to think of an example that isn't likewise going to
be simple like that.

Each time you choose an example, you pick table interaction as your
subject. Table interactions are, I think, pretty easy to deal with.
Indeed, I kept thinking while reading your code that I sometimes use
tables to map relationships between tables and data within those
tables (tables as storage structures that themselves drive the
behavior of code; that is, tables that don't store data about the
app's end-user viewed data, but that store information that is used
entirely to drive code operation). The most common example of this
that I'm sure many people have used is when importing/exporting data
you often use a table to map fields on one side to fields on the
other.
A table makes sense when each case doesn't need to have a concrete identity
within the app, but needs to be flexible and data driven. In my case,
compile-time checking is a value. Also, in my real-world case, I have
encapsulated some behavior as well as data, and you can't do that with a
table. My code uses Concrete implementations of data sources, and the test
source gets automatically re-copied before it is opened. The example I have
shown here could and likely would evolve to have some encapsulated behavior
such as a table data integrity checker or some such (probably not that in
particular, but it's one real possibility).
Now, where I get a glimmer of potential for this kind of thing is
with objects that are not generic (like tables), but that are
specific to a particular application, but that are used in multiple
ways. We have a certain amount of "pass-through" encapsulation
available to us if we, say, wrap a class module around a generic
form. We can expose the properties, methods and members of the
encapsulated form directly through a form-type property of the
encapsulatin g class (including custom properties/methods/members of
the encapsulated form), while also enhancing the encapasulated form
with additional propertis/methods/members.
Well, my examples deal with tables primarily because I'm a database programmer
and this is an Access group. Yes, this design pattern would apply equally
well to many other kinds of things. It applies well to database interactions
because it keeps everything that needs to know it even -is- a database
interaction in one place and it keeps all the details about each specific use
case in a single place in the code.
It's not real inheritance, but it's exactly what you've described,
in that it's upside-down, placing the "abstract" class as a wrapper
around the "concrete" class (in this case, a form).
Your application has a much different feel because each "Concrete" class is
much heavier, but I agree that what you are talking about is probably the
exact same design pattern I'm talking about.
Now, you can do the same kind of thing with a class module, as
you've shown, in that one of the properties of the "abstract" class
returns a reference to the "concrete" class.

So, it sort of makes sense to me from a structural level, but your
specific examples are sort of sabotaging my ability to understand it
clearly.
Perhaps, what I've said above will change your mind. It's good to tuck the
code that knows how a lookup is implemented (including the fact that it's a
database table at all) away from the code that wants to look up a value.
And when described the way I've done above, it doesn't sound so
earth-shattering. But when you talk about using it with pure class
modules (not forms), it does seem to me to have value.

The key breakthrough for me here was thinking about the idea of
wanting to add a bunch of behaviors and properties to a lot of
objects of exactly the same type. When I looked at the concept of a
wrapper around a bunch of forms that added new capabilities to all
the forms thus encapsulated, it began to make sense.
Neat. I came up with the same pattern from a totally different direction. I
wanted to factor out just what was different from a group of table interaction
classes that had only a few differences without having a bunch of classes
wrapping a bunch of members of a single root class.
But I think it's a mistake to talk about it as though it's
inheritance. It really isn't at all -- it's just a form of
encapsulatio n that gives you the same benefits in regard to
eliminating code duplication as pure inheritance does.

(Of course, I'm also assuming that I've finally understood!)


I think you get it. If there's a better terminology for what I've come up
with, I'm interested in hearing it. Where I'm coming from is that I started
from a problem I knew very well how to handle if I did have inheritance as a
tool, and found an OK way to approximate it without using inheritance. So, to
me, the code class correlates with the Abstract class, and the detail classes
correlate with Concrete classes because that's how they actually would be
implemented if we were doing true OOP.
Nov 12 '05 #5
rkc

"Steve Jorgensen" <no****@nospam. nospam> wrote in message
news:ug******** *************** *********@4ax.c om...
The duplication is not in the lookup code, the duplication is in the
application code that uses it. That's why what I'm talking about is a design pattern to be applied in a given application, not a library routine to be
reused across applications.


So the calling code is where the less duplication part comes in. Was that
function in your first example? It's gone from my news server. It wasn't
in your second example.

Your latest example does make more clear to me what you are calling
a design pattern. I think though that the pattern is just the way you have
to do oop stuff using VB.


Nov 12 '05 #6
Steve Jorgensen <no****@nospam. nospam> wrote in
news:ug******** *************** *********@4ax.c om:
On Tue, 13 Apr 2004 15:21:28 GMT, "David W. Fenton"
<dX********@bw ay.net.invalid> wrote:
Steve Jorgensen <no****@nospam. nospam> wrote in
news:54****** *************** ***********@4ax .com:
On Tue, 13 Apr 2004 07:20:06 GMT, Steve Jorgensen
<no****@nospam. nospam> wrote:

...
Correction
The way inheritance is normally simulated in languages like VBA
is that the Concrete class encapsulates (contains a reference
to) the Abstract class, and provides external access to the
Abstract class' members via a wrapper method for each. For the
situation I've described, that's a total mess, which is why this
case is such a prolem and in need of this solution; it adds as
much duplication as it removes. Every Concrete class has to
implement and expose all of its concrete members (that external
code doesn't need) plus a wrapper for every single public member
of the Abstract class (that the Concrete class doesn't
implement ).

My intention was to say it is the standard solution that adds as
much duplication as it removes, not that my proposed solution
adds as much duplication as it removes <g>.
I'm beginning to get it, but I'm still bogged down in your example
implementatio n. The task you've set for yourself seems really
simple to me -- it's the kind of thing I do all the time by
various methods, but it's really a very elaborate DLookup(), but
with the added feature that it adds the value if it's not there
already?


Again, this is a pattern to be used for removing duplication
within a sepecific application. This is not intended to be
general-purpose, it's an example of how the pattern might be used
in a single app.

I chose a simple example on purpose, though not as simple as my
first case. Although what the class does is really just a DLookup,
the code that uses the class should be not have to know or care
that that's what the implementation is doing. That code should
not need to know field names or table names, or how to build
criteria strings. In fact, if external code is aware of these
things and does them more than once, it is duplicating code, and
what's being duplicated is not something the compiler can check
for you, so there is the possibility of typos, cut/paste errors,
and Search/Replace errors.


I don't see how my example would lead to duplication of any kind in
this regard.
I'm not sure what value you've gotten from this complexity. How
many times do you really have to do this kind of thing? Assuming a
structure for all your tables that you're working with of ID field
and value field (variant?), then I just don't see where the code
duplication would come in. Working up from the simplest case, I
end up with the code after my signature.


The duplication is not in the lookup code, the duplication is in
the application code that uses it. That's why what I'm talking
about is a design pattern to be applied in a given application,
not a library routine to be reused across applications. Using
your code in an application, then using that code multiple times
for tables with the same nature (lookup table), and use it
multiple times for the same table as well, the calling code has
duplication. . . .


What?

You're saying that:

Dim lngID as Long

lngID = idLookup("Benze ne", "Gas", "tblGas", True)

is *code duplication*?

My code can be used on any table of any kind that has these
characteristics :

1. has a unique ID PK

2. that ID field has a name derivable from the table name
("tblYourTab le" -> "YourTableI D")

3. has a second field with a non-duplicated text value.

Every table that has this characteristic could use this code.

If I wanted to extend it to multiple field lookup, I could have a
parameter array called in pairs of VALUE/FIELD.

I don't see that there's any code duplication caused by my proposal
of a short function to do this.

The most trivial problem with it is that your tables may have
differnt naming conventions for the ID field, so you'd work around
that some way.

But I don't see how my proposed solution increases code duplication
at all.

But it isn't infinitely extensible, no, nor does it validate too
many things.

I'm just not getting it, Steve.
. . . Of course, calling your code from my example would
very likely be desirable to remove duplication in another
direction presuming one did not also want to cache the recordset
which may or may not make sense in a given app, but it's better
that this also be something the calling code does not need to
know. If I want to cache or not cache my lookup table recordsets,
there should only be one place to make the change.
I'd think that lookup tables would be small enough that (and
probably stored locally) so that there's little reason to cache
them.
Let's say I end up making this a client/server app on a busy
network, and I want to use disconnected recordsets for lookup
tables. With the code following the pattern I've outlined, only
the code in the "Abstract" class has to change. Neither the
calling code nor the Concrete classes has to change.
I only have to change my code in one place, to, within the function,
idLookup().

I just don't get it, Steve.
Now, that could easily be generalized to returning any field based
on any criteria (via a parameter array), assuming you are
returning one field. It wouldn't produce horrid code, in my
opinion, but you would end up with a function overloaded with
arguments that would have to be passed in a very special format.
That always leads me in the direction of a class module, since
that can document much more easily what the requirements are for
getting accurate data out of it.

But I still don't see where there needs to be a base class and
then specific classes.


The specific classes encapsulate combinations of attributes (and
custom behaviors if/when they are added later) and keep each
combination in one and only one place in the code. That's the
sole reason for their existence


And how is it different than converting my simple function to a
single class?

I don't see why you need either encapsulation or inheritance.

I see only one level here.
I very, very often write simply one-line wrapper functions around
complex class modules (most often when I need to use the output in
a query, which can't refer directly to class modules), and your
example concrete classes have only a very small number of
properties/methods/members.

So, I'm just not seeing where the benefit is here:

1. your example seems more easily implemented in a much more
straightforwa rd manner

2. I'm not able to think of an example that isn't likewise going
to be simple like that.

Each time you choose an example, you pick table interaction as
your subject. Table interactions are, I think, pretty easy to deal
with. Indeed, I kept thinking while reading your code that I
sometimes use tables to map relationships between tables and data
within those tables (tables as storage structures that themselves
drive the behavior of code; that is, tables that don't store data
about the app's end-user viewed data, but that store information
that is used entirely to drive code operation). The most common
example of this that I'm sure many people have used is when
importing/exporting data you often use a table to map fields on
one side to fields on the other.


A table makes sense when each case doesn't need to have a concrete
identity within the app, but needs to be flexible and data driven.


Yes, certainly. But I think you're depending on code for constructin
code structures that don't really *need* to be code structures. I
know your goal is having them be enforced by the compiler, but I'm
not sure that the value of that is so great as to justify the
enormous amount of extra code.
In my case, compile-time checking is a value. Also, in my
real-world case, I have encapsulated some behavior as well as
data, and you can't do that with a table. . . .
I understand that. All I'm saying is that tables can model
hierarchical relationships that aren't possible with the code
structures you have.
. . . My code uses Concrete
implementations of data sources, and the test source gets
automatically re-copied before it is opened. The example I have
shown here could and likely would evolve to have some encapsulated
behavior such as a table data integrity checker or some such
(probably not that in particular, but it's one real possibility).
I'm still foggy on why you need to do this the way you're doing it,
mostly because you've outlined the problem and not gone into detail.
I'm not sure the details would be any more enlightening, actually.
Now, where I get a glimmer of potential for this kind of thing is
with objects that are not generic (like tables), but that are
specific to a particular application, but that are used in
multiple ways. We have a certain amount of "pass-through"
encapsulati on available to us if we, say, wrap a class module
around a generic form. We can expose the properties, methods and
members of the encapsulated form directly through a form-type
property of the encapsulating class (including custom
properties/methods/members of the encapsulated form), while also
enhancing the encapasulated form with additional
propertis/methods/members.


Well, my examples deal with tables primarily because I'm a
database programmer and this is an Access group. . . .


Er, I spend most of *my* time not with tables, but with user
interface objects. And that's where I need lots of flexibility, and
presentations that may change within different runtime contexts.
Indeed, it's certainly where code duplication is the most problem.
My earlier example of dialog forms that collect filtering criteria
for reports is a good example of exactly how the traditional
approach causes the proliferation of duplicate objects and duplicate
code. Generic class wrappers around dialog forms could give you an
object that you open and that returns a WHERE clause (assuming your
report recordsource is simple enough that it can be filtered by a
mere WHERE clause -- certain kinds can't).
. . . Yes, this design
pattern would apply equally well to many other kinds of things.
It applies well to database interactions because it keeps
everything that needs to know it even -is- a database interaction
in one place and it keeps all the details about each specific use
case in a single place in the code.


I don't see how my idLookup() function violates that same principle.
It's not real inheritance, but it's exactly what you've described,
in that it's upside-down, placing the "abstract" class as a
wrapper around the "concrete" class (in this case, a form).


Your application has a much different feel because each "Concrete"
class is much heavier, but I agree that what you are talking about
is probably the exact same design pattern I'm talking about.


Well, I've concluded that you're onto something, but that you're
stumbling over trying to apply pure OO terminology.

There is no inheritance.

Get used to it.

There *is* encapsulation, and that's how you get the benefits you
need.
Now, you can do the same kind of thing with a class module, as
you've shown, in that one of the properties of the "abstract"
class returns a reference to the "concrete" class.

So, it sort of makes sense to me from a structural level, but your
specific examples are sort of sabotaging my ability to understand
it clearly.


Perhaps, what I've said above will change your mind. It's good to
tuck the code that knows how a lookup is implemented (including
the fact that it's a database table at all) away from the code
that wants to look up a value.


Well, that's the basic principle of encapsulation, and, I'd think,
is self-evident.
And when described the way I've done above, it doesn't sound so
earth-shattering. But when you talk about using it with pure class
modules (not forms), it does seem to me to have value.

The key breakthrough for me here was thinking about the idea of
wanting to add a bunch of behaviors and properties to a lot of
objects of exactly the same type. When I looked at the concept of
a wrapper around a bunch of forms that added new capabilities to
all the forms thus encapsulated, it began to make sense.


Neat. I came up with the same pattern from a totally different
direction. I wanted to factor out just what was different from a
group of table interaction classes that had only a few differences
without having a bunch of classes wrapping a bunch of members of a
single root class.


As I said above, I think your insistence on the idea that you're
faking "inheritanc e" was the real problem for me. You're getting one
of the benefits that inheritance provides, but you're getting it by
an approach that turns the concept on its head.

And that's why I was so completely confused.
But I think it's a mistake to talk about it as though it's
inheritance . It really isn't at all -- it's just a form of
encapsulati on that gives you the same benefits in regard to
eliminating code duplication as pure inheritance does.

(Of course, I'm also assuming that I've finally understood!)


I think you get it. If there's a better terminology for what I've
come up with, I'm interested in hearing it. Where I'm coming from
is that I started from a problem I knew very well how to handle if
I did have inheritance as a tool, and found an OK way to
approximate it without using inheritance. So, to me, the code
class correlates with the Abstract class, and the detail classes
correlate with Concrete classes because that's how they actually
would be implemented if we were doing true OOP.


To me the crucial concept is that you have a group of objects that
are the same at some level and you want to enhance all of them in
the same fashion. "Concrete" and "Abstract" just get in the way for
me there.

But I still think for the specific example you've given, you are
engaging in massive overkill. A simple function does *not* propagate
duplicate code.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #7
On Wed, 14 Apr 2004 00:05:39 GMT, "David W. Fenton"
<dX********@bwa y.net.invalid> wrote:
Steve Jorgensen <no****@nospam. nospam> wrote in
news:ug******* *************** **********@4ax. com: ....
I chose a simple example on purpose, though not as simple as my
first case. Although what the class does is really just a DLookup,
the code that uses the class should be not have to know or care
that that's what the implementation is doing. That code should
not need to know field names or table names, or how to build
criteria strings. In fact, if external code is aware of these
things and does them more than once, it is duplicating code, and
what's being duplicated is not something the compiler can check
for you, so there is the possibility of typos, cut/paste errors,
and Search/Replace errors.


I don't see how my example would lead to duplication of any kind in
this regard.
I'm not sure what value you've gotten from this complexity. How
many times do you really have to do this kind of thing? Assuming a
structure for all your tables that you're working with of ID field
and value field (variant?), then I just don't see where the code
duplicatio n would come in. Working up from the simplest case, I
end up with the code after my signature.


The duplication is not in the lookup code, the duplication is in
the application code that uses it. That's why what I'm talking
about is a design pattern to be applied in a given application,
not a library routine to be reused across applications. Using
your code in an application, then using that code multiple times
for tables with the same nature (lookup table), and use it
multiple times for the same table as well, the calling code has
duplication. . . .


What?

You're saying that:

Dim lngID as Long

lngID = idLookup("Benze ne", "Gas", "tblGas", True)

is *code duplication*?


Now, I'm seeing what you're saying. In your case, the design pattern includes
the layout of the tables themselves, and that results in a simpler pattern
than mine so long as no behabiors have to be encapsulated. Actually, the
table name would be duplicated there, but that could be fixed by making it a
declared constant, so yes, that's less complex than my example and meets the
requirements demonstrated in my example.
My code can be used on any table of any kind that has these
characteristic s:

1. has a unique ID PK

2. that ID field has a name derivable from the table name
("tblYourTable " -> "YourTableI D")

3. has a second field with a non-duplicated text value.

Every table that has this characteristic could use this code.
OK, but what's to keep you, or more importantly the person who ends up having
to maintain your code later from changing the order of the fields. The
compiler can't tell you about such problems. Of course, I see that even that
could be worked around by placing a SELECT statement in a constant, and
passing that. Of course, the SELECT statement structure is still technically
duplicated, but if the constants are all together in one module, I guess any
deviation would be blatantly obvious, so the eye-ball code checker should be
sufficient.

Now, the only issue is adding code behavior. Since my code didn't add any
behavior, I will agree that your code would be better with the requirements as
shown, but if behavior were required, then I think mine would be the better
pattern.
The most trivial problem with it is that your tables may have
differnt naming conventions for the ID field, so you'd work around
that some way.
Actually, you could check the primary key property of the tabledef :).
But I don't see how my proposed solution increases code duplication
at all.
Now that I understand how you are using your code, I agree it doesn't given
that the table names are stored in constants.
But it isn't infinitely extensible, no, nor does it validate too
many things.

I'm just not getting it, Steve.
It sounds like you understand what my code does, so, given my acknowledgments
above, what's not to get. If you need overridable behaviors as well as static
value properties, I think the value of my approach becomes clear, and I do see
that my example fails to fully make the point since no behaviors are required.
Do you see, though, how it doesn sense in situations where behaviors are
required?

The case in which I employed this pattern, I was actually abstracting 2
complete separate database back-ends, one JET (for testing), and the other
PostgreSQL (Production). First of all, then, the connection string was not a
constant for the JET back-end, because it was determining the path of the
front-end (in this case, and Excel front-end), and using that path to find the
template database back-end contained in the same directory. Next, besides
values, there was a behavior. For the testing back-end, a new copy of the
back-end was made from the template on start-up using the PreInitialize member
of the Concrete class. For the production back-end, PreInitialize was left
empty.
. . . Of course, calling your code from my example would
very likely be desirable to remove duplication in another
direction presuming one did not also want to cache the recordset
which may or may not make sense in a given app, but it's better
that this also be something the calling code does not need to
know. If I want to cache or not cache my lookup table recordsets,
there should only be one place to make the change.


I'd think that lookup tables would be small enough that (and
probably stored locally) so that there's little reason to cache
them.


Actually, I sometimes like to cache them, so I always know I have the latest
copy as of some recent point in time. I tend to cache them only for the
lifespan of a single process.
Let's say I end up making this a client/server app on a busy
network, and I want to use disconnected recordsets for lookup
tables. With the code following the pattern I've outlined, only
the code in the "Abstract" class has to change. Neither the
calling code nor the Concrete classes has to change.


I only have to change my code in one place, to, within the function,
idLookup().

I just don't get it, Steve.


Right - it was I who didn't get your code. I get it now that you do have the
code in one place, and my objection does not apply.
Now, that could easily be generalized to returning any field based
on any criteria (via a parameter array), assuming you are
returning one field. It wouldn't produce horrid code, in my
opinion, but you would end up with a function overloaded with
arguments that would have to be passed in a very special format.
That always leads me in the direction of a class module, since
that can document much more easily what the requirements are for
getting accurate data out of it.

But I still don't see where there needs to be a base class and
then specific classes.


The specific classes encapsulate combinations of attributes (and
custom behaviors if/when they are added later) and keep each
combination in one and only one place in the code. That's the
sole reason for their existence


And how is it different than converting my simple function to a
single class?


That doesn't deal with adding behaviors and computed properties specific to
individual cases. I am agreeing that my example still failed to make the
case, but hopefully my explanation here has made explained its value in other
cases.
I don't see why you need either encapsulation or inheritance.
It only came up for me because I needed unique behaviors and computed
attributes for concrete cases.
I see only one level here.
I very, very often write simply one-line wrapper functions around
complex class modules (most often when I need to use the output in
a query, which can't refer directly to class modules), and your
example concrete classes have only a very small number of
properties/methods/members.

So, I'm just not seeing where the benefit is here:

1. your example seems more easily implemented in a much more
straightforw ard manner

2. I'm not able to think of an example that isn't likewise going
to be simple like that.

Each time you choose an example, you pick table interaction as
your subject. Table interactions are, I think, pretty easy to deal
with. Indeed, I kept thinking while reading your code that I
sometimes use tables to map relationships between tables and data
within those tables (tables as storage structures that themselves
drive the behavior of code; that is, tables that don't store data
about the app's end-user viewed data, but that store information
that is used entirely to drive code operation). The most common
example of this that I'm sure many people have used is when
importing/exporting data you often use a table to map fields on
one side to fields on the other.


A table makes sense when each case doesn't need to have a concrete
identity within the app, but needs to be flexible and data driven.


Yes, certainly. But I think you're depending on code for constructin
code structures that don't really *need* to be code structures. I
know your goal is having them be enforced by the compiler, but I'm
not sure that the value of that is so great as to justify the
enormous amount of extra code.


Well, it could even be done more simply with code structures as I acknowledged
above up until behaviors are involved. I get that a lookup system might never
need that, and if it did that would probably be because it evolved into
something more complex than what you would call a lookup system.
In my case, compile-time checking is a value. Also, in my
real-world case, I have encapsulated some behavior as well as
data, and you can't do that with a table. . . .


I understand that. All I'm saying is that tables can model
hierarchical relationships that aren't possible with the code
structures you have.


But the pattern I'm describing can be used to abstract away the interfaces to
2 similar heirarchies provided the abstract class does know the structure of
the heirarchy.
. . . My code uses Concrete
implementations of data sources, and the test source gets
automatically re-copied before it is opened. The example I have
shown here could and likely would evolve to have some encapsulated
behavior such as a table data integrity checker or some such
(probably not that in particular, but it's one real possibility).


I'm still foggy on why you need to do this the way you're doing it,
mostly because you've outlined the problem and not gone into detail.
I'm not sure the details would be any more enlightening, actually.


Alright then, I blew it again on providing a decent example. I'll try to post
a simple example of actually abstracting the entire database with a test
back-end just like my real-world case has to do.
Now, where I get a glimmer of potential for this kind of thing is
with objects that are not generic (like tables), but that are
specific to a particular application, but that are used in
multiple ways. We have a certain amount of "pass-through"
encapsulatio n available to us if we, say, wrap a class module
around a generic form. We can expose the properties, methods and
members of the encapsulated form directly through a form-type
property of the encapsulating class (including custom
properties/methods/members of the encapsulated form), while also
enhancing the encapasulated form with additional
propertis/methods/members.


Well, my examples deal with tables primarily because I'm a
database programmer and this is an Access group. . . .


Er, I spend most of *my* time not with tables, but with user
interface objects. And that's where I need lots of flexibility, and
presentation s that may change within different runtime contexts.
Indeed, it's certainly where code duplication is the most problem.
My earlier example of dialog forms that collect filtering criteria
for reports is a good example of exactly how the traditional
approach causes the proliferation of duplicate objects and duplicate
code. Generic class wrappers around dialog forms could give you an
object that you open and that returns a WHERE clause (assuming your
report recordsource is simple enough that it can be filtered by a
mere WHERE clause -- certain kinds can't).


Agreed. User interfaces are where the bigger problems with duplication lie,
especially when trying to use Access bound forms for the interface.
. . . Yes, this design
pattern would apply equally well to many other kinds of things.
It applies well to database interactions because it keeps
everything that needs to know it even -is- a database interaction
in one place and it keeps all the details about each specific use
case in a single place in the code.


I don't see how my idLookup() function violates that same principle.


It doesn't - I just wasn't seeing it.
It's not real inheritance, but it's exactly what you've described,
in that it's upside-down, placing the "abstract" class as a
wrapper around the "concrete" class (in this case, a form).


Your application has a much different feel because each "Concrete"
class is much heavier, but I agree that what you are talking about
is probably the exact same design pattern I'm talking about.


Well, I've concluded that you're onto something, but that you're
stumbling over trying to apply pure OO terminology.

There is no inheritance.

Get used to it.

There *is* encapsulation, and that's how you get the benefits you
need.


Right. This was basically just all about how I finally figured out how to use
Enhapsulation and Polymorhpism to solve a problem I never previously saw a way
to solve without the benefit of inheritance.
Now, you can do the same kind of thing with a class module, as
you've shown, in that one of the properties of the "abstract"
class returns a reference to the "concrete" class.

So, it sort of makes sense to me from a structural level, but your
specific examples are sort of sabotaging my ability to understand
it clearly.


Perhaps, what I've said above will change your mind. It's good to
tuck the code that knows how a lookup is implemented (including
the fact that it's a database table at all) away from the code
that wants to look up a value.


Well, that's the basic principle of encapsulation, and, I'd think,
is self-evident.


The fact of wanting to do it is self-evident, the -how- was not at
self-evident to me in the case of trying to make a pluggable datbase back-end
for a data download process.
And when described the way I've done above, it doesn't sound so
earth-shattering. But when you talk about using it with pure class
modules (not forms), it does seem to me to have value.

The key breakthrough for me here was thinking about the idea of
wanting to add a bunch of behaviors and properties to a lot of
objects of exactly the same type. When I looked at the concept of
a wrapper around a bunch of forms that added new capabilities to
all the forms thus encapsulated, it began to make sense.


Neat. I came up with the same pattern from a totally different
direction. I wanted to factor out just what was different from a
group of table interaction classes that had only a few differences
without having a bunch of classes wrapping a bunch of members of a
single root class.


As I said above, I think your insistence on the idea that you're
faking "inheritanc e" was the real problem for me. You're getting one
of the benefits that inheritance provides, but you're getting it by
an approach that turns the concept on its head.

And that's why I was so completely confused.


I'm not sure I see it as turning the concept on its head. I still have a
class that contains the majority of the code structure, but is incomplete by
itself, and I have another class that provides the missing pieces to make the
first class able to function and handle a specific case. Is it so far off to
think of the first class as Abstract? I agree that to call the second class
Concrete is a bit rough when it in no way pretends to be exposed, but I can't
find a good term.
But I think it's a mistake to talk about it as though it's
inheritanc e. It really isn't at all -- it's just a form of
encapsulatio n that gives you the same benefits in regard to
eliminatin g code duplication as pure inheritance does.

(Of course, I'm also assuming that I've finally understood!)


I think you get it. If there's a better terminology for what I've
come up with, I'm interested in hearing it. Where I'm coming from
is that I started from a problem I knew very well how to handle if
I did have inheritance as a tool, and found an OK way to
approximate it without using inheritance. So, to me, the code
class correlates with the Abstract class, and the detail classes
correlate with Concrete classes because that's how they actually
would be implemented if we were doing true OOP.


To me the crucial concept is that you have a group of objects that
are the same at some level and you want to enhance all of them in
the same fashion. "Concrete" and "Abstract" just get in the way for
me there.

But I still think for the specific example you've given, you are
engaging in massive overkill. A simple function does *not* propagate
duplicate code.


I had misapprehended what your code actually did. I agree that functions
often provide complete abstractions and don't require duplicating code, though
there are several cases where they cannot, and patterns like the one I'm
trying to propose here must be employed.
Nov 12 '05 #8
rkc

"Steve Jorgensen" <no****@nospam. nospam> wrote in message
news:ml******** *************** *********@4ax.c om...
On Wed, 14 Apr 2004 00:05:39 GMT, "David W. Fenton"
<dX********@bwa y.net.invalid> wrote: I'm not sure I see it as turning the concept on its head. I still have a
class that contains the majority of the code structure, but is incomplete by itself, and I have another class that provides the missing pieces to make the first class able to function and handle a specific case. Is it so far off to think of the first class as Abstract? I agree that to call the second class Concrete is a bit rough when it in no way pretends to be exposed, but I can't find a good term.


Your first class is not abstract. It can't even be confused with being
abstract.

In VB an interface is abstract. It's abstract because it only has signatures
of
properties and methods. They have no functionality. The functionality is
left to
a concrete class (any class that can be instantiated) that implements the
interface
class. What you are doing is clear to me. The value of what you are doing is
clear to me. Unfortunately it is not because of what you have presented
so far. Raise a glass to the fourth try being a winner.
Nov 12 '05 #9
On Wed, 14 Apr 2004 02:53:54 GMT, "rkc" <rk*@yabba.dabb a.do.rochester. rr.bomb>
wrote:

"Steve Jorgensen" <no****@nospam. nospam> wrote in message
news:ml******* *************** **********@4ax. com...
On Wed, 14 Apr 2004 00:05:39 GMT, "David W. Fenton"
<dX********@bwa y.net.invalid> wrote:

I'm not sure I see it as turning the concept on its head. I still have a
class that contains the majority of the code structure, but is incomplete

by
itself, and I have another class that provides the missing pieces to make

the
first class able to function and handle a specific case. Is it so far off

to
think of the first class as Abstract? I agree that to call the second

class
Concrete is a bit rough when it in no way pretends to be exposed, but I

can't
find a good term.


Your first class is not abstract. It can't even be confused with being
abstract.

In VB an interface is abstract. It's abstract because it only has signatures of
properties and methods. They have no functionality. The functionality is left to
a concrete class (any class that can be instantiated) that implements the
interface class. What you are doing is clear to me. The value of what you are doing is
clear to me. Unfortunately it is not because of what you have presented
so far. Raise a glass to the fourth try being a winner.


An abstract class is not one that contains only interfaces, it is one that is
incomplete without a supporting class. If it's that unclear to everyone but
me, though, then it is inherently unclear, and my terminology needs work. All
suggestions welcome.

As for my next try, I'll just strip down the real, production code. It may be
a few days because the code is in flux, so I'll have to get it to the next
stable point, then rip out enough to protect my client.
Nov 12 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
3181
by: Brian Jones | last post by:
I'm sure the solution may be obvious, but this problem is driving me mad. The following is my code: class a(object): mastervar = def __init__(self): print 'called a'
12
7018
by: Steve Jorgensen | last post by:
The classing Visual Basic and VBA support for polymorphism, let's face it, is a bit on the weak side, and built-in support for inheritance is non-existent. This little essay is about some patterns I've ended up using successfully for certain kinds of inheritance and polymorphism, and some that have not worked out so well. Let's start with...
22
23323
by: Matthew Louden | last post by:
I want to know why C# doesnt support multiple inheritance? But why we can inherit multiple interfaces instead? I know this is the rule, but I dont understand why. Can anyone give me some concrete examples?
45
6313
by: Ben Blank | last post by:
I'm writing a family of classes which all inherit most of their methods and code (including constructors) from a single base class. When attempting to instance one of the derived classes using parameters, I get CS1501 (no method with X arguments). Here's a simplified example which mimics the circumstances: namespace InheritError { //...
7
12862
by: Hazz | last post by:
Are there any good references/articles/books which provide clarity toward my insecurity still on deciding how to model a complex system? I still feel uncomfortable with my understanding, even though I have worked with these systems on when to decide to use interfaces (and how they should be developed) as opposed to or complemented by the use...
5
2858
by: jao | last post by:
My company's product uses Postgres 7.4.3. Postgres is working well for us, and we've worked through many performance issues by tweaking the schema, indexes, and posgresql.conf settings. Inheritance would be useful for our application, but we did not use this feature initially. We're about to revise part of our application, and this would be...
6
1657
by: tshad | last post by:
I am playing with Inheritance and want to make sure I understand it. I have the following Classes: ******************************************* Public Class AuthHeader:Inherits SoapHeader Public AuthHeaderName As String Public SessionKey As String = "Default" End Class Public Class ServiceTicket:Inherits AuthHeader
60
4869
by: Shawnk | last post by:
Some Sr. colleges and I have had an on going discussion relative to when and if C# will ever support 'true' multiple inheritance. Relevant to this, I wanted to query the C# community (the 'target' programming community herein) to get some community input and verify (or not) the following two statements. Few programmers (3 to7%)...
16
2925
by: devicerandom | last post by:
Hi, I am currently using the Cmd module for a mixed cli+gui application. I am starting to refactor my code and it would be highly desirable if many commands could be built as simple plugins. My idea was: - Load a list of plugin names (i.e. from the config file, or from the plugins directory) - Import all plugins found dynamically:
3
2540
by: Jess | last post by:
Hello, I've been reading Effective C++ about multiple inheritance, but I still have a few questions. Can someone give me some help please? First, it is said that if virtual inheritance is used, then "the responsibility for initializing a virtual base is borne by the most derived class in the hierarchy". What does it mean? Initializing...
0
7429
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
0
7614
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. ...
0
7777
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that...
1
7384
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
0
7713
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
0
4922
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert...
0
3420
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in...
1
1844
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
0
671
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.