By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,290 Members | 1,263 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,290 IT Pros & Developers. It's quick & easy.

newbe classes

P: n/a
I have a question about concrete and abstract classes. what are the
differances? can you explain them to me. I have started an advance Visual
Studio.Net class and I am having a hard time understanding him.
Thank you
Wes McCaslin
Nov 20 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a
Think of an abstract class as a "model" of a class that you never intend to
use directly. I teach VB .NET and the analogy we use in our course is that
of a vehicle "prototype". A car manufacturer may make a generic prototype
vehicle (which they never intend to put into mass-production and sell).
This prototype can then be modified and turned into specific models that
WILL be sold.

For example:

If you had a "vehicle" abstract class that was very simple it has:

A NumberOfCylinders property,
A NumberOfDoors property,
A Speed property,
An IsMoving method,
A TapTheBrakes method,
An Accelerate method,
A SpeedLimitExceeded event

These are all things that virtually ANY vehicle would/could have, but the
class doesn't have any more than this defined within it because that would
make it too specific (add a TurboCharged property and it doesn't make sense
if we're making an economy car, add a TowingCapacity and it doesn't make
sense for a sports car, etc.)

Now, the vehicle class is not intended to actually be used directly, instead
we may make a specific type of vehicle:

Public Class TowTruck()
Inherits Vehicle
Public Property TowingCapacity as Integer
...
End Property
End Class

Now we've got something we can actually use, a TowTruck.

Abstract classes are usually marked as MustInherit because they are too
generic on their own. Also, when you begin to talk about abstract classes,
you must also start talking about Interfaces because they have cross-over
appeal.

An Interface doesn't contain any actual code, only the class's member
declarations. So, if my vehicle were defined as an Interface, it would look
something like this:

Public Interface Vehicle
Public Property NumberOfCylinders() As Short
Public Property NumberOfDoors() As Short
Public Property Speed() As Short
Public Function IsMoving() As Boolean
Public Sub TapTheBrakes()
Public Sub Accelerate(ByHowMuch As Short)
Public Event SpeedLimitExceeded()
End Interface

Now, for our TowTruck class, we would say:

Public Class TowTruck()
Implements Vehicle

'You would now be forced to create all the members that a vehicle has
for the TowTruck so that
'it can "Implement" the "Interface" of a vehicle.
'The only difference here is that you have to write the logic for each
member that is required
'where as if you had Inherited from a Vehicle class, you wouldn't

Public Property TowingCapacity as Integer
...
End Property
End Class
"Wes McCaslin" <no***********@olp.net> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
I have a question about concrete and abstract classes. what are the
differances? can you explain them to me. I have started an advance Visual
Studio.Net class and I am having a hard time understanding him.
Thank you
Wes McCaslin

Nov 20 '05 #2

P: n/a
Hi Wes,

A <very> simplified way of looking at it is that an abstract class is
pseudo-code. But pseudo-code that is very strictly defined (ie. it actually
uses the language's syntax) and that <must> be implemented exactly. You can
build on it but you can not do less than it requires. Like pseudo-code, an
abstract class cannot be 'run', as it is a blueprint.

Regards,
Fergus
Nov 20 '05 #3

P: n/a
Hello,

"Wes McCaslin" <no***********@olp.net> schrieb:
I have a question about concrete and abstract classes.
what are the differances? can you explain them to me. I
have started an advance Visual Studio.Net class and I
am having a hard time understanding him.


In addition to the other replies, I recommend to read this chapter in the
documentation:

http://msdn.microsoft.com/library/en...ithobjects.asp

--
Herfried K. Wagner
MVP VB Classic, VB.NET
http://www.mvps.org/dotnet
Nov 20 '05 #4

P: n/a
Wes,
In the simplest terms:

Abstract classes are classes that have the MustInherit keyword on them.
Concrete classes do not have the MustInherit keyword on them.

As the others have stated. Abstract classes are used as starting points for
Concrete classes. You can create an instance of a Concrete class, you cannot
create an instance of an Abstract class.

For example if I were to create a type safe collection I would start with
System.Collections.CollectionBase. CollectionBase is an Abstract class
because it has the MustInherit keyword on it. I cannot create an instance of
CollectionBase .

My type safe collection extends CollectionBase adding type safe Add, Item,
and Remove methods. My type safe collection is a concrete class as it does
not have the MustInherit keyword. I can create an instance of my type safe
collection.

Some Abstract classes have MustOverride methods, these are methods that any
concrete classes have to fill in. CollectionBase does not have any these.
System.IO.Stream is an example of an Abstract class that has MustOverride
methods.

Abstract classes normally have at least Overridable methods (such as
CollectionBase), but are not required to have either MustOverride or
Overridable methods.

Abstract classes are used for 1 of 2 general reasons:
1. As a starting point for other classes as they offer common code. For
example CollectionBase. Normally I would not write functions that expect a
CollectionBase object and use it. Normally I use the type safe collection
object itself. CollectionBase gives me a head start of writing type safe
collections.

2. As a starting point for polymorphism, for example System.IO.Stream. I can
write routines that only expect System.IO.Stream, by passing a FileStream or
NetworkStream object my routine stays the same, but I just changed reading
from a disk file verses reading off a web site. I can use the same routine
with a MemoryStream and support the clipboard!

For a comparison of OOP terms across languages see:
http://msdn.microsoft.com/library/de...tsKeywords.asp

Referring to the above link, J#, C#, C++, and JScript all use the 'abstract'
keyword to "specific that a class can only be inherited. An instance of the
class cannot be created" while VB.NET uses the 'MustInherit' keyword for
this.

Hope this helps
Jay

"Wes McCaslin" <no***********@olp.net> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
I have a question about concrete and abstract classes. what are the
differances? can you explain them to me. I have started an advance Visual
Studio.Net class and I am having a hard time understanding him.
Thank you
Wes McCaslin

Nov 20 '05 #5

P: n/a
So basiclly if I create a class called Cshape which has:
Public mustinherit class Cshape

Public overrideable function area() as double
Return 0
end funcution

Publci overrideable function volume() as double
return 0
end function

Public mustoverride readonly property name() as string

end class
This is a abstract class correct? Then i could create a class called
Ctwodiminsionalshape which would calculate the area of the
twodiminsionalshape in the class that i would create called Csquare and this
would be a concrete class because it could not go any further right?
"Scott M." <s-***@badspamsnet.net> wrote in message
news:O0**************@TK2MSFTNGP10.phx.gbl...
Think of an abstract class as a "model" of a class that you never intend to use directly. I teach VB .NET and the analogy we use in our course is that of a vehicle "prototype". A car manufacturer may make a generic prototype
vehicle (which they never intend to put into mass-production and sell).
This prototype can then be modified and turned into specific models that
WILL be sold.

For example:

If you had a "vehicle" abstract class that was very simple it has:

A NumberOfCylinders property,
A NumberOfDoors property,
A Speed property,
An IsMoving method,
A TapTheBrakes method,
An Accelerate method,
A SpeedLimitExceeded event

These are all things that virtually ANY vehicle would/could have, but the
class doesn't have any more than this defined within it because that would
make it too specific (add a TurboCharged property and it doesn't make sense if we're making an economy car, add a TowingCapacity and it doesn't make
sense for a sports car, etc.)

Now, the vehicle class is not intended to actually be used directly, instead we may make a specific type of vehicle:

Public Class TowTruck()
Inherits Vehicle
Public Property TowingCapacity as Integer
...
End Property
End Class

Now we've got something we can actually use, a TowTruck.

Abstract classes are usually marked as MustInherit because they are too
generic on their own. Also, when you begin to talk about abstract classes, you must also start talking about Interfaces because they have cross-over
appeal.

An Interface doesn't contain any actual code, only the class's member
declarations. So, if my vehicle were defined as an Interface, it would look something like this:

Public Interface Vehicle
Public Property NumberOfCylinders() As Short
Public Property NumberOfDoors() As Short
Public Property Speed() As Short
Public Function IsMoving() As Boolean
Public Sub TapTheBrakes()
Public Sub Accelerate(ByHowMuch As Short)
Public Event SpeedLimitExceeded()
End Interface

Now, for our TowTruck class, we would say:

Public Class TowTruck()
Implements Vehicle

'You would now be forced to create all the members that a vehicle has
for the TowTruck so that
'it can "Implement" the "Interface" of a vehicle.
'The only difference here is that you have to write the logic for each
member that is required
'where as if you had Inherited from a Vehicle class, you wouldn't

Public Property TowingCapacity as Integer
...
End Property
End Class
"Wes McCaslin" <no***********@olp.net> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
I have a question about concrete and abstract classes. what are the
differances? can you explain them to me. I have started an advance Visual Studio.Net class and I am having a hard time understanding him.
Thank you
Wes McCaslin


Nov 20 '05 #6

P: n/a
Wes,
This is a abstract class correct? Correct if you define the Shape class with MustInherit it is an Abstract
class.
Then i could create a class called
Ctwodiminsionalshape which would calculate the area of the
twodiminsionalshape
Whether TwoDiminsionalShape is abstract or not depends on whether it has the
MustInherit keyword or not!
create called Csquare and this
would be a concrete class because it could not go any further right? Correct because you can create instances of Square it is a concrete class.

Remember that Square may inherit from Rectangle (as a square is a special
case Rectangle). Rectangle would not be abstract as you can create instances
of it.

So if you have:
Shape (MustInherit)
TwoDiminsionalShape (MustInherit, inherits Shape)
Rectangle (inherits TwoDiminsionalShape)
Square (inherits Rectangle)

Shape & TwoDiminsionalShape are Abstract, while Rectangle & Square are
concrete.

Note the naming convention for .NET does not include C on the front of the
class.

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

Hope this helps
Jay

"Wes McCaslin" <no***********@olp.net> wrote in message
news:uH**************@TK2MSFTNGP11.phx.gbl... So basiclly if I create a class called Cshape which has:
Public mustinherit class Cshape

Public overrideable function area() as double
Return 0
end funcution

Publci overrideable function volume() as double
return 0
end function

Public mustoverride readonly property name() as string

end class
This is a abstract class correct? Then i could create a class called
Ctwodiminsionalshape which would calculate the area of the
twodiminsionalshape in the class that i would create called Csquare and this would be a concrete class because it could not go any further right?
"Scott M." <s-***@badspamsnet.net> wrote in message
news:O0**************@TK2MSFTNGP10.phx.gbl...
Think of an abstract class as a "model" of a class that you never intend

to
use directly. I teach VB .NET and the analogy we use in our course is

that
of a vehicle "prototype". A car manufacturer may make a generic prototype
vehicle (which they never intend to put into mass-production and sell).
This prototype can then be modified and turned into specific models that
WILL be sold.

For example:

If you had a "vehicle" abstract class that was very simple it has:

A NumberOfCylinders property,
A NumberOfDoors property,
A Speed property,
An IsMoving method,
A TapTheBrakes method,
An Accelerate method,
A SpeedLimitExceeded event

These are all things that virtually ANY vehicle would/could have, but the class doesn't have any more than this defined within it because that would make it too specific (add a TurboCharged property and it doesn't make

sense
if we're making an economy car, add a TowingCapacity and it doesn't make
sense for a sports car, etc.)

Now, the vehicle class is not intended to actually be used directly,

instead
we may make a specific type of vehicle:

Public Class TowTruck()
Inherits Vehicle
Public Property TowingCapacity as Integer
...
End Property
End Class

Now we've got something we can actually use, a TowTruck.

Abstract classes are usually marked as MustInherit because they are too
generic on their own. Also, when you begin to talk about abstract

classes,
you must also start talking about Interfaces because they have cross-over appeal.

An Interface doesn't contain any actual code, only the class's member
declarations. So, if my vehicle were defined as an Interface, it would

look
something like this:

Public Interface Vehicle
Public Property NumberOfCylinders() As Short
Public Property NumberOfDoors() As Short
Public Property Speed() As Short
Public Function IsMoving() As Boolean
Public Sub TapTheBrakes()
Public Sub Accelerate(ByHowMuch As Short)
Public Event SpeedLimitExceeded()
End Interface

Now, for our TowTruck class, we would say:

Public Class TowTruck()
Implements Vehicle

'You would now be forced to create all the members that a vehicle has for the TowTruck so that
'it can "Implement" the "Interface" of a vehicle.
'The only difference here is that you have to write the logic for each member that is required
'where as if you had Inherited from a Vehicle class, you wouldn't

Public Property TowingCapacity as Integer
...
End Property
End Class
"Wes McCaslin" <no***********@olp.net> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
I have a question about concrete and abstract classes. what are the
differances? can you explain them to me. I have started an advance

Visual Studio.Net class and I am having a hard time understanding him.
Thank you
Wes McCaslin



Nov 20 '05 #7

P: n/a
Hi Jay,

|| Note the naming convention for .NET does not
|| include C on the front of the class.

The guidelines say "Do not use 'C', etc" but not why not. Any ideas about
their justification?

Regards,
Fergus
Nov 20 '05 #8

P: n/a
Hello,

"Fergus Cooney" <fi******@tesco.net> schrieb:
|| Note the naming convention for .NET does not
|| include C on the front of the class.

The guidelines say "Do not use 'C', etc" but not why not.
Any ideas about their justification?


"C" was used as a prefix for classes, for example in the MFC libraries.

Remember that it's only a guideline. Nobody can prevent you from using "C"
as prefix.

--
Herfried K. Wagner
MVP VB Classic, VB.NET
http://www.mvps.org/dotnet
Nov 20 '05 #9

P: n/a

"Wes McCaslin" <no***********@olp.net> wrote in message
news:uH**************@TK2MSFTNGP11.phx.gbl...
So basiclly if I create a class called Cshape which has:
Public mustinherit class Cshape

Public overrideable function area() as double
Return 0
end funcution

Publci overrideable function volume() as double
return 0
end function

Public mustoverride readonly property name() as string

end class
This is a abstract class correct?
Correct!

Then i could create a class called Ctwodiminsionalshape which would calculate the area of the
twodiminsionalshape in the class that i would create called Csquare and this would be a concrete class because it could not go any further right?
Well, to make a concrete class only means that you can make instances of it
(Dim X as New CShape).
"Scott M." <s-***@badspamsnet.net> wrote in message
news:O0**************@TK2MSFTNGP10.phx.gbl...
Think of an abstract class as a "model" of a class that you never intend

to
use directly. I teach VB .NET and the analogy we use in our course is

that
of a vehicle "prototype". A car manufacturer may make a generic prototype
vehicle (which they never intend to put into mass-production and sell).
This prototype can then be modified and turned into specific models that
WILL be sold.

For example:

If you had a "vehicle" abstract class that was very simple it has:

A NumberOfCylinders property,
A NumberOfDoors property,
A Speed property,
An IsMoving method,
A TapTheBrakes method,
An Accelerate method,
A SpeedLimitExceeded event

These are all things that virtually ANY vehicle would/could have, but the class doesn't have any more than this defined within it because that would make it too specific (add a TurboCharged property and it doesn't make

sense
if we're making an economy car, add a TowingCapacity and it doesn't make
sense for a sports car, etc.)

Now, the vehicle class is not intended to actually be used directly,

instead
we may make a specific type of vehicle:

Public Class TowTruck()
Inherits Vehicle
Public Property TowingCapacity as Integer
...
End Property
End Class

Now we've got something we can actually use, a TowTruck.

Abstract classes are usually marked as MustInherit because they are too
generic on their own. Also, when you begin to talk about abstract

classes,
you must also start talking about Interfaces because they have cross-over appeal.

An Interface doesn't contain any actual code, only the class's member
declarations. So, if my vehicle were defined as an Interface, it would

look
something like this:

Public Interface Vehicle
Public Property NumberOfCylinders() As Short
Public Property NumberOfDoors() As Short
Public Property Speed() As Short
Public Function IsMoving() As Boolean
Public Sub TapTheBrakes()
Public Sub Accelerate(ByHowMuch As Short)
Public Event SpeedLimitExceeded()
End Interface

Now, for our TowTruck class, we would say:

Public Class TowTruck()
Implements Vehicle

'You would now be forced to create all the members that a vehicle has for the TowTruck so that
'it can "Implement" the "Interface" of a vehicle.
'The only difference here is that you have to write the logic for each member that is required
'where as if you had Inherited from a Vehicle class, you wouldn't

Public Property TowingCapacity as Integer
...
End Property
End Class
"Wes McCaslin" <no***********@olp.net> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
I have a question about concrete and abstract classes. what are the
differances? can you explain them to me. I have started an advance

Visual Studio.Net class and I am having a hard time understanding him.
Thank you
Wes McCaslin



Nov 20 '05 #10

P: n/a
Hi Herfried,

|| "C" was used as a prefix for classes

Yep, it was and still is.

|| Remember that it's only a guideline.

Even if it were a rule, I'd still do it my way without a good reason.
If it were <Law>, I'd still want a good reason. ;-)

|| Nobody can prevent you from using "C" as prefix.

Lol. <I> can - I hate 'C' as a prefix!!
Fergus said:
|| The guidelines say "Do not use 'C', etc" but not why not.
|| Any ideas about their justification?

??

Regards,
Fergus
Nov 20 '05 #11

P: n/a
Fergus,
The why has been discussed in different newsgroups.

The way I see it, is that C as a prefix is redundant, I'm doing object
oriented programming, naturally the bulk of my types are going to be
classes, what benefit is there to labeling them as such. With intellisense
have a prefix, just means more typing. I would have to type C before any
class then the character it starts with, as opposed to simply typing the
character it starts with.

For other types (Structures, Delegates) does it really make sense to prefix
them with S or D? As an S or a D IMHO does not really add any value.

For Interfaces the Microsoft world seems hung up with the I prefix. Its in
the guidelines so I tend to follow it. In the Java world interfaces are not
prefixed with an I. In Java & VB.NET there is a specific keyword to signify
that a type implements an interface, so the I is redundant. However there is
no keyword in C# to signify that a type implements an interface as opposed
to inheriting from a class (both are signified by the a colon ':' & commas
',' in the class definition, so the I makes sense...

Hope this helps
Jay
"Fergus Cooney" <fi******@tesco.net> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...
Hi Jay,

|| Note the naming convention for .NET does not
|| include C on the front of the class.

The guidelines say "Do not use 'C', etc" but not why not. Any ideas about their justification?

Regards,
Fergus

Nov 20 '05 #12

P: n/a
Hi Jay,

|| The why has been discussed in different newsgroups.

I'm too new to newsgroups and I've been too busy answering others to stray
very far afield. :-)

I haven't finalised my position on this issue yet, though I never liked
'C' as it gives two capitals together. I prefer the lowercase 'cls' and
'frm' - three! characters to type ;-)

I not going to start a debate, though, I detect that you've been through
it all quite enough.

|| Hope this helps

Yes, it does, thanks. :-)

Regards,
Fergus
Nov 20 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.