Хорошее название для класса декоратора?

Question

Я бы хотел разделить API, над которым я работаю, на два раздела: «голые» и «удобный». Идея состоит в том, что все вызовы методов в разделе «cushy» могут быть выражены в терминах вызовов в разделе «bare-bones», то есть они будут служить лишь удобными методами для быстрого и грязного. Причина, по которой я хотел бы сделать это, состоит в том, что очень часто, когда люди начинают использовать API в первый раз, их не интересуют детали и производительность: они просто хотят, чтобы он работал.

Кто-нибудь пробовал что-нибудь подобное раньше? Меня особенно интересуют соглашения об именах и организация кода.

Answer 1

Один из способов обеспечить дискретное разделение «простых» и «пустых» - это использование отдельных интерфейсов, которые реализуются одним и тем же классом. При написании API я хотел бы сделать его максимально простым. Если вам нужно много параметров, попробуйте использовать свободный интерфейс .

Answer 2

Да, я делал что-то подобное раньше и склоняюсь к слову, которое указывает, что делает дополнительная функциональность.

Например, базовый класс Vector может выполнять только очень простые векторные операции (сложение, скалярное произведение), а класс Vectors может иметь различные статические вспомогательные методы (перекрестные произведения, проекции и т. Д.). Затем FluentVector включает в себя все эти вспомогательные операции, одновременно изменяя базовый Vector.

Однако это не шаблон декоратора - декоратор выдает разные «декорированные» результаты с одинаковым интерфейсом. Это шаблон фасада - другой интерфейс с одной и той же базовой функцией.

Кроме того, имейте в виду, что в вашем расширенном API могут быть разные способы доставки одной и той же функции. Возвращаясь к моему примеру Vector, можно не захотеть изменять базовый Vector при каждой операции цепочки и вместо этого вводить новый Vector - это может быть ImmutableFluentVector или что-то подобное. API будет идентичным, за исключением спецификации побочных эффектов. Просто что-то иметь в виду.

Answer 3

Предполагается, что Barebone предоставляет базовую функциональность, а Cushy - дополнительную.

 
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 = новый Adorner (bareBones);

Answer 4

Поскольку вы запрашиваете красивые имена, обычно используется простой или базовый API и расширенный API . Простой API использует, как уже упоминал Саймон Никерсон, расширенный API, технически предоставляя абстракцию. Смотри также Фасадный узор

Answer 5

Кто-то на работе предложил Foo и FooHelper. Мне это нравится.