Not sure when to use an abstract property and when not

Question

I'm not really sure what looks better or when do I really use in abstract classes and properties, or when to use non abstract properties. I'll try to make a simple example. Let's say I have this:

abstract class Human {   public GenderType Gender { get; set; }   public string Name { get; set; }   public Date Born { get; set; }   public bool IsNerd { get; set; }    abstract public void Speak();   abstract public void Sleep();   abstract public void AnoyingPeopleOnStackOverflow();   //... so on }  class Peter : Human {   //Peter is special, he got a second name   //But thats all, everything else is the same as like on other humans   public string SecondName { get; set; }    //...override abstract stuff } 

Is this alright? As I understood, I don't have to use an abstract property if I dont want to override it. And in this situation it would be ok, just the methods like Speak, Sleep and so on should be abstract.

Now, if this is ok, when would or should I use an abstract property?

Answer 1

Use an abstract property when you have no default implementation and when derived classes must implement it.

Use a virtual property when you have an implementation in the base class but want to allow overriding.

Use the override keyword to override a member. Mark the member as sealed override if it should not be overridden again.

Don't mark the property as abstract or virtual if you don't want it to be overridden.

Use the new keyword to hide a non-abstract, non-virtual member (this is rarely a good idea).

How to: Define Abstract Properties

I find that abstract properties often occur in a design which implies that they will have type-specific logic and/or side effects. You are basically saying, "here is a data point that all subclasses must have, but I don't know how to implement it". However, properties which contain a large amount of logic and/or cause side effects may not be desirable. This is an important consideration, though there is no fixed right/wrong way to do it.

See:

• Should Properties have Side Effects
• CA1024: Use properties where appropriate

Personally, I find that I use abstract methods frequently but abstract properties rarely.

Answer 2

I know what I want them to do, I don't care how they do it: Interface.

I know what I want them to do, I don't care how they do some of it, but I've firm ideas on how they'll (or at least most of them) do other bits: Abstract class.

I know what I want them to do, and how most of them will do it: Concrete class with virtual members.

You can have other cases such as e.g. an abstract class with no abstract members (you can't have an instance of one, but what functionality it offers, it offers completely), but they're rarer and normally come about because a particular hierarchy offers itself cleanly and blatantly to a given problem.

(Incidentally, I wouldn't think of a Peter as a type of Human, but of each peter as an instance of human who happens to be called Peter. It's not really fair to pick on example code in this way, but when you're thinking about this sort of issue it's more pertinent than usual).