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

Implementing abstract classes

P: n/a
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
Sep 22 '08 #1
Share this Question
Share on Google+
8 Replies


P: n/a
puzzlecracker <ir*********@gmail.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 - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com
Sep 22 '08 #2

P: n/a
On Mon, 22 Sep 2008 11:52:32 -0700, puzzlecracker <ir*********@gmail.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
Sep 22 '08 #3

P: n/a
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?
Sep 22 '08 #4

P: n/a
puzzlecracker <ir*********@gmail.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 - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com
Sep 22 '08 #5

P: n/a
On Sep 22, 2:52 pm, puzzlecracker <ironsel2...@gmail.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
Sep 22 '08 #6

P: n/a
Jon Skeet [C# MVP] wrote:
puzzlecracker <ir*********@gmail.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".
Sep 22 '08 #7

P: n/a
Subject: Re: Implementing abstract classes
From: Jon Skeet [C# MVP] <sk***@pobox.com>

Mike Schilling <ms*************@amberpoint.comwrote:
Jon Skeet [C# MVP] wrote:
puzzlecracker <ir*********@gmail.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 - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com
Sep 22 '08 #8

P: n/a
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/Defa...m=juval%20lowy

Here is one of his books.
http://www.amazon.com/Programming-NE.../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.WriteLine( test.Name );
Console.WriteLine( test.GetScore( ) );

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

Console.ReadLine( );
}
}

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

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

Single GetScore( );
}


Sep 23 '08 #9

This discussion thread is closed

Replies have been disabled for this discussion.