Implementing abstract classes

[puzzlecracker]

0) What is the convention name for derived classes?
1) If we implement methods in abstract class, do we still need to
declare them as abstract?
2) Are we allowed to override methods in derived classes that are
already implemented in abstract?
3) Are there a different accessibility levels when I inherit class,
like (public, protected, private), like class A:public B?


Thanks

[Jon Skeet [C# MVP]]

Re: Implementing abstract classes

puzzlecracker <ironsel2000@gm ail.comwrote:

0) What is the convention name for derived classes?

There isn't one really. Abstract base classes sometimes have a "Base"
suffix.

1) If we implement methods in abstract class, do we still need to
declare them as abstract?

No.

2) Are we allowed to override methods in derived classes that are
already implemented in abstract?

Yes, so long as they're still virtual (i.e. not marked with "virtual").

3) Are there a different accessibility levels when I inherit class,
like (public, protected, private), like class A:public B?

You can't specify an access modifier there.

--
Jon Skeet - <skeet@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[Peter Duniho]

Re: Implementing abstract classes

On Mon, 22 Sep 2008 11:52:32 -0700, puzzlecracker <ironsel2000@gm ail.com>
wrote:

0) What is the convention name for derived classes?

Nothing different from classes derived from non-abstract classes.

1) If we implement methods in abstract class, do we still need to
declare them as abstract?

Not only do you not need to, you cannot.

2) Are we allowed to override methods in derived classes that are
already implemented in abstract?

There's nothing unusual about abstract classes in this respect. As long
as the methods are virtual, you may override the methods.

3) Are there a different accessibility levels when I inherit class,
like (public, protected, private), like class A:public B?

No. In C#, you simply inherit the class; accessibility of members in the
inherited class remain the same as they are originally declared.

Pete

[puzzlecracker]

Re: Implementing abstract classes

2) Are we allowed to override methods in derived classes that are
already implemented in abstract?

>
Yes, so long as they're still virtual (i.e. not marked with "virtual").

I don't understand this one? should virtual be specified next to the
abstract method in base class?

[Jon Skeet [C# MVP]]

Re: Implementing abstract classes

puzzlecracker <ironsel2000@gm ail.comwrote:

2) Are we allowed to override methods in derived classes that are
already implemented in abstract?

Yes, so long as they're still virtual (i.e. not marked with "virtual").

>
I don't understand this one? should virtual be specified next to the
abstract method in base class?

No, if it's an abstract method it's necessarily virtual - but if you've
implemented the method in the abstract class, that method isn't virtual
by default.

--
Jon Skeet - <skeet@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[Ignacio Machin ( .NET/ C# MVP )]

Re: Implementing abstract classes

On Sep 22, 2:52 pm, puzzlecracker <ironsel2...@gm ail.comwrote:

0) What is the convention name for derived classes?

As you need.

1) If we implement methods in abstract class, do we still need to
declare them as abstract?

nop, you will get a compiler error

2) Are we allowed to override methods in derived classes that are
already implemented in abstract?

as long as they are virtual, of course

3) Are there a different accessibility levels when I inherit class,
like (public, protected, private), like class A:public B?

no

[Mike Schilling]

Re: Implementing abstract classes

Jon Skeet [C# MVP] wrote:

puzzlecracker <ironsel2000@gm ail.comwrote:

>>>2) Are we allowed to override methods in derived classes that are
>>>already implemented in abstract?
>>>
>>Yes, so long as they're still virtual (i.e. not marked with
>>"virtual").

>>
>I don't understand this one? should virtual be specified next to the
>abstract method in base class?

>
No, if it's an abstract method it's necessarily virtual - but if
you've implemented the method in the abstract class, that method
isn't virtual by default.

Agreed, but I still don't understand the "not".

[Jon Skeet [C# MVP]]

Re: Implementing abstract classes

Subject: Re: Implementing abstract classes
From: Jon Skeet [C# MVP] <skeet@pobox.co m>

Mike Schilling <mscottschillin g@amberpoint.co mwrote:

Jon Skeet [C# MVP] wrote:

puzzlecracker <ironsel2000@gm ail.comwrote:

>>2) Are we allowed to override methods in derived classes that are
>>already implemented in abstract?
>>
>Yes, so long as they're still virtual (i.e. not marked with
>"virtual").
>
I don't understand this one? should virtual be specified next to the
abstract method in base class?

No, if it's an abstract method it's necessarily virtual - but if
you've implemented the method in the abstract class, that method
isn't virtual by default.

>
Agreed, but I still don't understand the "not".

Oh, sorry, I see what you mean. My fault entirely. I meant "not marked
with sealed" for methods which are already overriding a previous
implementation, and "marked with virtual" for other methods.

Apologies - I've got about 20 different things going on here and a
useless internet connection :(

--
Jon Skeet - <skeet@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[Russell Mangel]

Re: Implementing abstract classes

Hi,

It looks like you received some help on your questions.
So I won't offer any abstract class advice.

I would like to point out to you that depending on your design
you should also consider Interface Based Programming.

Personally, I like to program against Interfaces only, never
against the objects (Class implementaion), in fact I always
try to Implement the Interface Explicitly. Of course this can't
be done in every case, but learning how and what interfaces
are good for will become very valuable to you once you get
past the learning curve. It can take years to really *get* Interface
based programming.

If you are interested in learning about Interface Based Programming
I highly suggest anything written by Juval Lowy.

Here Juval's take on "Object Oriented Programming."
He claims it does not work well for larger projects.

ARCast.TV - Juval Lowy on Interface Based Design

http://channel9.msdn.com/Search/Default.aspx?Term=juval%20lowy

Here is one of his books.

http://www.amazon.com/Programming-NET-Components-Juval-Lowy/dp/0596102070

And lastly his consultant web page:

http://www.idesign.net

Juval Lowy is a very talented guy. He is Microsoft Regional Director for
Silicon Valley CA. He was involved with internal design of C#.

Russell Mangel
Las Vegas, NV



// Here is a simple example of what I mean by "Declaring Methods
Explicitly":

using System;

class Program
{
static void Main( string[] args )
{
// Here we are programming against the interface.
ITest test = new Test( );
Console.WriteLi ne( test.Name );
Console.WriteLi ne( test.GetScore( ) );

// Here we can not code against the class object:
Test test2 = new Test( );
//Console.WriteLi ne( test2.Name ); // Error
//Console.WriteLi ne( test2.GetScore( ) ); // Error

Console.ReadLin e( );
}
}

public class Test : ITest
{
string ITest.Name
{
get
{
return "Danielle";
}
}

Single ITest.GetScore( )
{
return 98.7f;
}
}
public interface ITest
{
String Name
{
get;
}

Single GetScore( );
}