Classes vs. Modules

[aaron.kempf@gmail.com]

Re: Classes vs. Modules

google is not a search engine

they are a platform, a services company.. they provide freeware
Spreadsheet and Documents SOLUTIONS and they innovate more in a week
than MS does in a year.

MS has not innovated ONE IOTA since 1998, the release of VB6.

everything since then has been a step BACKWARDS.

whereas google is continously giving us MORE functionality--- VB has
_LESS_ functionality than it did a decade ago.

VBS FILES - USED TO WORK, NOW IT DOESNT.
SQL JOBS - CANNOT RUN DOTNET CRAP
VBA - DOTNET CANNOT WORK WITH OFFICE, GOOGLE CAN!

this so-called DOTNET is a 1/4 solution AT BEST

and I will NOT STAND FOR ANOTHER VISUAL FRED
and I will NOT STAND FOR ANOTHER VISUAL FRED
and I will NOT STAND FOR ANOTHER VISUAL FRED
and I will NOT STAND FOR ANOTHER VISUAL FRED


On Feb 15, 12:27 am, "Martin H." <h...@gmx.netwr ote:

and it is impossible to even determine which version of the framework
is on machineX.

>
I told you how to find it out. It's so easy that even a 3-year-old can
do it.
>

a bunch of blind and drunk teenagers could have come up with better
execution and a better strategy... oh wait; they already DID it is
called GOOGLE

>
What do a search engine and framework such as the .NET framework in
common? NOTHING!
>
Martin

[Scott M.]

Re: Classes vs. Modules

Public Interface IDoor
Property LockType As Integer
Property Material As String
ReadOnly Property IsLocked As Boolean
Sub Lock
Sub UnLock
End Interface

Public Class Car
Implements IDoor
'This class must now implement all of the members of the IDoor
interface.
'The actual functionality of the interface members is left up to this
class creator
'but any Car instance will be guaranteed to have a Door interface with
the
'appropriate methods and properties


End Class

Public Class House
Implements IDoor
'This class must now implement all of the members of the IDoor
interface.
'The actual functionality of the interface members is left up to this
class creator
'but any House instance will be guaranteed to have a Door interface with
the
'appropriate methods and properties

End Class

'************** *************** *************** ***

Public Class DoorUser

Public Sub UserDoor(x As IDoor)
'Since this method must be provided a type (any type) that implements
'the IDoor interface, we know for sure that it will be able to use
'any of that interface's properties & methods. This is Polymorphism
x.Lock
Dim y As Boolean = x.IsLocked
End Sub

End Class




"Martin H." <hkshk@gmx.netw rote in message
news:45d419c8$0 $23370$9b622d9e @news.freenet.d e...

Hello Scott,
>
Scott M. wrote:

>Sounds like a job for Interfaces or Polymorphism to me.

>
How would that work?
>
Thanks in advance.
>
Best regards,
>
Martin

[Tom Shelton]

Re: Classes vs. Modules

On Feb 15, 3:08 pm, "Scott M." <s...@nospam.no spamwrote:

Public Interface IDoor
Property LockType As Integer
Property Material As String
ReadOnly Property IsLocked As Boolean
Sub Lock
Sub UnLock
End Interface
>
Public Class Car
Implements IDoor
'This class must now implement all of the members of the IDoor
interface.
'The actual functionality of the interface members is left up to this
class creator
'but any Car instance will be guaranteed to have a Door interface with
the
'appropriate methods and properties
>
End Class
>
Public Class House
Implements IDoor
'This class must now implement all of the members of the IDoor
interface.
'The actual functionality of the interface members is left up to this
class creator
'but any House instance will be guaranteed to have a Door interface with
the
'appropriate methods and properties
>
End Class
>
'************** *************** *************** ***
>
Public Class DoorUser
>
Public Sub UserDoor(x As IDoor)
'Since this method must be provided a type (any type) that implements
'the IDoor interface, we know for sure that it will be able to use
'any of that interface's properties & methods. This is Polymorphism
x.Lock
Dim y As Boolean = x.IsLocked
End Sub
>
End Class
>
"Martin H." <h...@gmx.netwr ote in message
>
news:45d419c8$0 $23370$9b622d9e @news.freenet.d e...
>
>
>

Hello Scott,

>

Scott M. wrote:

Sounds like a job for Interfaces or Polymorphism to me.

>

How would that work?

>

Thanks in advance.

>

Best regards,

>

Martin- Hide quoted text -

>
- Show quoted text -

Sorry Scott, I don't particularly agree with this implementation. For
one thing, Interfaces imply a "type of" relationship - and a car and a
house are not types of doors. They have doors - so this is better
expressed intermes of a "has-a" relationship - and that means
aggregation... Most likely, I would create an abstract door class and
then inherit various door types from it.

--
Tom Shelton

[Scott M.]

Re: Classes vs. Modules

Sorry Scott, I don't particularly agree with this implementation. For

one thing, Interfaces imply a "type of" relationship - and a car and a
house are not types of doors. They have doors - so this is better
expressed intermes of a "has-a" relationship - and that means
aggregation... Most likely, I would create an abstract door class and
then inherit various door types from it.

Actually Tom, I think you've got that backwards. Interfaces are just that,
interfaces. They do not imply a "type" at all, they only imply a way of
interacting or "interfacin g" with a type. An abstract class is, in fact, a
type and so it would indicate a "type" when inheriting from it. Also, since
we can't inherit from more than one type at a time, Interfaces become an
important way of getting where we need to go. Also, through the use of
interfaces, we can get the polymorphic behavior that is essential when
talking about a property or method that 2 unrelated types have, but use in
different ways.

[Branco Medeiros]

Re: Classes vs. Modules

Scott M. wrote:
<snip>

Interfaces are just that,
interfaces. They do not imply a "type" at all, they only imply a way of
interacting or "interfacin g" with a type.

<snip>

Most interfaces I know of are used as types, or, at least, as quality
of a type:

IList
ICollection
IClonable
IEnumerable
IEtc...

i.e. if a class implements a given interface, you can use an instance
of the class wherever the implemented type is expected. I don't see
how a car or a house can be used where a door is expected...

At least that's how I've been seeing interfaces being used since the
first time I stumbled on them (circa 19VB5).

IMXHO, your example would be more "correct" (not that it's really
incorrect) if you aggregated a Door class to the Car and House
classes, as suggested by Tom, and/or changed the IDoor interface to
IEnterable (ouch!).

As Cor uses to say, "just my thought". ;-)

Regards,

Branco.

[Tom Shelton]

Re: Classes vs. Modules

On Feb 16, 5:30 am, "Scott M." <s...@nospam.no spamwrote:

Sorry Scott, I don't particularly agree with this implementation. For
one thing, Interfaces imply a "type of" relationship - and a car and a
house are not types of doors. They have doors - so this is better
expressed intermes of a "has-a" relationship - and that means
aggregation... Most likely, I would create an abstract door class and
then inherit various door types from it.

>
Actually Tom, I think you've got that backwards. Interfaces are just that,
interfaces. They do not imply a "type" at all, they only imply a way of
interacting or "interfacin g" with a type.

That is true to some extent. An interface can be used in a number of
ways. An interface, can be used to define a contract, and is often
used to ensure functionality across multiple different, and unrelated
types. I used "type-of" to differentiate between what you metion
below - inheritance - which is an "is-a" relation ship. If you think
about some of the common interfaces it makes sense, for example,
IList, anything that implements is a type of list (or at least can be
treated as a type of list).

An abstract class is, in fact, a
type and so it would indicate a "type" when inheriting from it.

Yep.

Also, since
we can't inherit from more than one type at a time, Interfaces become an
important way of getting where we need to go.

Again, definately.

Also, through the use of
interfaces, we can get the polymorphic behavior that is essential when
talking about a property or method that 2 unrelated types have, but use in
different ways.

And that's what I said above. Because, with the interface we can
treat them as a "type of" something. I had a very specific reason for
saying "type of". To me it implies a general grouping of objects,
that aren't necessarily the same type "is-a".

All that said - your implementation was an inappropriate use of
interfaces. A door is an object in it's own right. A house is not a
door, nor does it behave as a door. A house has a door and uses a
door. Same with a vehicle. The relationship is better expressed in a
"has-a" relationship.

--
Tom Shelton

[=?Utf-8?B?U2NvdHQgTS4=?=]

Re: Classes vs. Modules

<snip>
All that said - your implementation was an inappropriate use of
interfaces. A door is an object in it's own right. A house is not a
door, nor does it behave as a door. A house has a door and uses a
door. Same with a vehicle. The relationship is better expressed in a
"has-a" relationship.
</snip>

I don't belive you can acurrately say that my use of interfaces is
"inappropriate" , you can only say that you would choose to "implement" a door
in a differet way that I chose to.

There is absolutely nothing wrong (or inapproprate) about the code that I've
shown. Quite literally, a door is an interface to ahouse or car and my code
allows either a house or a car to expose that interface, but in ways that are
specific to the individual types.

I agree that interfaces *can* be used as abstract types (such as IDisposable
or ISerializable), but that doesn't mean that they *must* be or, for that
matter *can't* be used, in just as valid of a way as I've shown. No, a house
is not a door, nor is a car a door, but you, by your own admission, are using
your own "has a", "type of" and "is a" rules here when, I belive they are not
applicable.

Historically, the "is a" test has been used to see if inheritance applies.
If you must brand your own terminology to this, stick with the "has a" test.
A house "has a" door and so does a car.

"Tom Shelton" wrote:

On Feb 16, 5:30 am, "Scott M." <s...@nospam.no spamwrote:

Sorry Scott, I don't particularly agree with this implementation. For
one thing, Interfaces imply a "type of" relationship - and a car and a
house are not types of doors. They have doors - so this is better
expressed intermes of a "has-a" relationship - and that means
aggregation... Most likely, I would create an abstract door class and
then inherit various door types from it.

Actually Tom, I think you've got that backwards. Interfaces are just that,
interfaces. They do not imply a "type" at all, they only imply a way of
interacting or "interfacin g" with a type.

>
That is true to some extent. An interface can be used in a number of
ways. An interface, can be used to define a contract, and is often
used to ensure functionality across multiple different, and unrelated
types. I used "type-of" to differentiate between what you metion
below - inheritance - which is an "is-a" relation ship. If you think
about some of the common interfaces it makes sense, for example,
IList, anything that implements is a type of list (or at least can be
treated as a type of list).
>

An abstract class is, in fact, a
type and so it would indicate a "type" when inheriting from it.

>
Yep.
>

Also, since
we can't inherit from more than one type at a time, Interfaces become an
important way of getting where we need to go.

>
Again, definately.
>

Also, through the use of
interfaces, we can get the polymorphic behavior that is essential when
talking about a property or method that 2 unrelated types have, but use in
different ways.

>
And that's what I said above. Because, with the interface we can
treat them as a "type of" something. I had a very specific reason for
saying "type of". To me it implies a general grouping of objects,
that aren't necessarily the same type "is-a".
>
All that said - your implementation was an inappropriate use of
interfaces. A door is an object in it's own right. A house is not a
door, nor does it behave as a door. A house has a door and uses a
door. Same with a vehicle. The relationship is better expressed in a
"has-a" relationship.
>
--
Tom Shelton
>
>

[Cor Ligthert [MVP]]

Re: Classes vs. Modules

Hi Americans,

And than we see nowhere on movies so much mobile homes as in the USA.

Just my thought, Branco.

:-)

I agree the most with Tom this time in the discussion and have not something
really to add..

Cor


"Tom Shelton" <tom_shelton@co mcast.netschree f in bericht
news:1171643503 .474245.126370@ j27g2000cwj.goo glegroups.com.. .

On Feb 16, 5:30 am, "Scott M." <s...@nospam.no spamwrote:

Sorry Scott, I don't particularly agree with this implementation. For
one thing, Interfaces imply a "type of" relationship - and a car and a
house are not types of doors. They have doors - so this is better
expressed intermes of a "has-a" relationship - and that means
aggregation... Most likely, I would create an abstract door class and
then inherit various door types from it.

>>
>Actually Tom, I think you've got that backwards. Interfaces are just
>that,
>interfaces. They do not imply a "type" at all, they only imply a way of
>interacting or "interfacin g" with a type.

>
That is true to some extent. An interface can be used in a number of
ways. An interface, can be used to define a contract, and is often
used to ensure functionality across multiple different, and unrelated
types. I used "type-of" to differentiate between what you metion
below - inheritance - which is an "is-a" relation ship. If you think
about some of the common interfaces it makes sense, for example,
IList, anything that implements is a type of list (or at least can be
treated as a type of list).
>

> An abstract class is, in fact, a
>type and so it would indicate a "type" when inheriting from it.

>
Yep.
>

> Also, since
>we can't inherit from more than one type at a time, Interfaces become an
>important way of getting where we need to go.

>
Again, definately.
>

>Also, through the use of
>interfaces, we can get the polymorphic behavior that is essential when
>talking about a property or method that 2 unrelated types have, but use
>in
>different ways.

>
And that's what I said above. Because, with the interface we can
treat them as a "type of" something. I had a very specific reason for
saying "type of". To me it implies a general grouping of objects,
that aren't necessarily the same type "is-a".
>
All that said - your implementation was an inappropriate use of
interfaces. A door is an object in it's own right. A house is not a
door, nor does it behave as a door. A house has a door and uses a
door. Same with a vehicle. The relationship is better expressed in a
"has-a" relationship.
>
--
Tom Shelton
>

[Tom Shelton]

Re: Classes vs. Modules

On Feb 16, 10:34 am, Scott M. <s...@nospam.no spamwrote:

<snip>
All that said - your implementation was an inappropriate use of
interfaces. A door is an object in it's own right. A house is not a
door, nor does it behave as a door. A house has a door and uses a
door. Same with a vehicle. The relationship is better expressed in a
"has-a" relationship.
</snip>
>
I don't belive you can acurrately say that my use of interfaces is
"inappropriate" , you can only say that you would choose to "implement" a door
in a differet way that I chose to.
>

You are right - that was an unfortunate word choice. I was not trying
to offend you or show any disrespect. I just feel that using an
interface in this manner is not a good choice of implementation.
While it works, it seems to me that it unecessarily restricts
flexability.

In the real world, which we are generally attempting to model, there
are many kinds of doors. An while they all have the same basic
attributes and behaviors, they often times do it differently. By
implementing house as a door, you must change your house class if
suddenly you decide to change the direction the door opens? Or, you
decide that I want a door with a peep-hole? Or a sliding glass door?
By implementing Door as a separate (and most likely abstract class)
class and then using delegation to expose a door on the house, you can
easily switch your door implementation on the house - even at runtime.

There is absolutely nothing wrong (or inapproprate) about the code that I've
shown. Quite literally, a door is an interface to ahouse or car and my code
allows either a house or a car to expose that interface, but in ways that are
specific to the individual types.
>

Using an abstract door class and aggregation does the same thing in a
much more maintainable and flexible manner.

I agree that interfaces *can* be used as abstract types (such as IDisposable
or ISerializable), but that doesn't mean that they *must* be or, for that
matter *can't* be used, in just as valid of a way as I've shown. No, a house
is not a door, nor is a car a door, but you, by your own admission, are using
your own "has a", "type of" and "is a" rules here when, I belive they are not
applicable.
>

I'm not using my own "has a", "is a" rules. An interface implies a
couple of things.... That you are implementing in terms of the
interface (a contract) or as a type of something. A house is not
built in terms of a door, nor as a type of door. A house has a door.

Historically, the "is a" test has been used to see if inheritance applies.
If you must brand your own terminology to this, stick with the "has a" test.
A house "has a" door and so does a car.

Yep. A house has a door - which is exactly what I said. Implying
composition, not inheritance.

--
Tom Shelton