Nice name for `decorator' class?

Question

I would like to separate the API I'm working on into two sections: 'bare-bones' and 'cushy'. The idea is that all method calls in the 'cushy' section could be expressed in terms of the ones in the 'bare-bones' section, that is, they would only serve as convenience methods for the quick-and-dirty. The reason I would like to do this is that very often when people are beginning to use an API for the first time, they are not interested in details and performance: they just want to get it working.

Anybody tried anything similar before? I'm particularly interested in naming conventions and organizing the code.

Answer 1

Since you're asking for nice names, commonly used is simple or basic API and extended API. The simple API uses, as mentioned by Simon Nickerson, the extended API technically by providing an abstraction. See also Facade Pattern

Answer 2

One way to provide a discrete separation of 'cushy' vs 'bare-bones' would be using separate interfaces that are implemented by the same class. When writing an API I like to keep it as simple as possible. If you need lots of parameters, consider using a fluent interface.

Answer 3

Yes, I've done something like this before, and I tend to pre-pend a word that indicates what the extra functionality is doing.

For example, a basic Vector class might only perform very basic vector operations (add, dot product), and a Vectors class might have a variety of static helper methods (cross products, projections, etc). Then, a FluentVector incorporates all those helper operations, while mutating the underlying Vector.

However, this isn't the decorator pattern - decorator produces different "decorated" results with the same interface. This is the facade pattern - different interface with the same underlying function.

Also, keep in mind that your extended API may have a variety of different ways of delivering the same function. Back to my Vector example, one might not want to mutate the underlying Vector with each chained-operation and instead introduce a new Vector - this might be an ImmutableFluentVector or some such. The API would be identical, except for the specification of side-effects. Just something to keep in mind.

Answer 4

Somebody at work suggested Foo and FooHelper. I like it.

Answer 5

Assuming Barebone provides basic functionality and Cushy provides additional functionality:

 
public class Skeleton
{
  public virtual void Info()
  {
  }
}

public class Adorner:Skeleton
{
  private Skeleton _skeleton;

  public Adorner(Skeleton skeleton)
  {
     _skeleton = skeleton;
  }

  public override void Info()
  {
   //apply adorning work
  }
}

Skeleton bareBones = new Skeleton(); Adorner cushy = new Adorner(bareBones);