Decorator example from Design Pattern Framework

 
280   99.7
Feb 27, 2012
 
I hope that I don't get moved to the 'hair-splitters' section for that question, but as we're talking here about very basic principles, I just wanted to get everything right :)

In the Design Pattern Framework, there's an example in the solution DoFactory.HeadFirst.Decorator.Starrbuzz. That example contains a base-class, which is called Beverage.

My question is now, why don't we declare this base-class as abstract, as we're never going to have instance of a sole Beverage, but only drinks like e.g. Espresso, DarkRoast, ...?
public class Beverage
{
   public virtual string Description { get; protected set; }
   public virtual double Cost { get; protected set; }
}

public class DarkRoast : Beverage
{
   public DarkRoast()
   {
      Description = "Dark Roast Coffee";
      Cost = 0.99;
   }
}

 



380   99.9
Mar 01, 2012
I have not seen the full source of the Beverage class, but an abstract class provides a base framework (optionally with partial implementation) that other classes can share via inheritance. In the above case, Beverage case can be abstract too since it is not instantiated and provides base properties for beverages.

Hope this helps?

 1 comment
 
When writing source code, we try to make our source code as restricted as possible, right? That is done in order to give another programmer an accurate impression of the intented functionality of our source code. That's why we decide to sometimes work with a Collection and in other cases with a IEnumerable. From that point of view, a class like Beverage, which never gets instantiated should be declared abstract. With that in mind, in that case it actually would be wrong to not declare the base-class Beverage as abstract. That was my actual question. Why don't we declare that certain base-class as abstract. --- Florian Schaeffler  Mar 05, 2012