Classes vs. Modules

  • Thread starter Thread starter Zytan
  • Start date Start date
expensive migrations without benefit are pointless


DOTNET has no marketshare; the framework is not on any desktops

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




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
 
and it is impossible to even determine which version of the framework
is on machineX.
Click to expand...

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
Click to expand...

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

Martin
 
But, if I'm not mistaken, you can put your module into a custom namespace
(like "Main" or "appStart", etc.) and then you'd be able to use those
qualifiers (or, my preference - - import the namespace at the top of your
code and NOT qualify it.
Click to expand...

Yes, I could that. Maybe that's the best idea.

and maybe eventually I will get used to not qualifying anything.

Zytan
 
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
 
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
 
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











- Show quoted text -
Click to expand...

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.
 
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.
Click to expand...

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 "interfacing" 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.
 
Scott M. wrote:
Interfaces are just that,
interfaces. They do not imply a "type" at all, they only imply a way of
interacting or "interfacing" with a type.
Click to expand...
<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.
 
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 "interfacing" with a type.
Click to expand...

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.
Click to expand...

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.
Click to expand...

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.
 
<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.
 
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
 
<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.
Click to expand...

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.
Click to expand...

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.
Click to expand...

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.
Click to expand...

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