Not sure when to use an abstract property and when not

Solution 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.

Solution 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).

Solution 3:

Abstract members are simply virtual members that you have to override. You use this for something that has to be implemented, but can't be implemented in the base class.

If you want to make a virtual property, and want that it has to be overridden in the class that inherits your class, then you would make it an abstract property.

If you for example have an animal class, its ability to breathe would not be possible to detemine just from the information that it's an animal, but it's something that is pretty crucial:

public abstract class Animal {

  public abstract bool CanBreathe { get; }

}

For a fish and a dog the implementation would be different:

public class Dog : Animal {

   public override bool CanBreathe { get { return !IsUnderWater; } }

}

public class Fish : Animal {

   public override bool CanBreathe { get { return IsUnderWater; } }

}

Solution 4:

Use abstract when all sub-classes have to implement the method/property. If there's no need for each and every sub-class to implement it, then don't use it.

As for your example, if SecondName is not required for each person, then there's no need to make an abstract property in the base class. If on the other hand, every person does need a second name, then make it an abstract property.

Example of correct usage of an abstract property:

public class Car
{
    public abstract string Manufacturer { get; }
}

public class Odyssey : Car
{
    public override string Manufacturer
    {
         get 
         {
             return "Honda";
         }
    }
}

public class Camry : Car
{
    public override string Manufacturer
    {
         get 
         {
             return "Toyota";
         }
    }
}

Making Maker abstract is correct because every car has a manufacturer and needs to be able to tell the user who that maker is.