Пример реального мира стратегической модели

Что относительно этого:

необходимо зашифровать файл.

Для маленьких файлов, можно использовать "в памяти" стратегию, где полный файл считан и сохранен в памяти (скажем, для файлов < 1 ГБ)

Для больших файлов, можно использовать другую стратегию, где части файла читаются в памяти, и частичные зашифрованные результаты хранятся в tmp файлах.

Они могут быть двумя различными стратегиями той же задачи.

клиентский код выглядел бы одинаково:

 File file = getFile();
 Cipher c = CipherFactory.getCipher( file.size() );
 c.performAction();



// implementations:
interface  Cipher  {
     public void performAction();
}

class InMemoryCipherStrategy implements Cipher { 
         public void performAction() {
             // load in byte[] ....
         }
}

class SwaptToDiskCipher implements Cipher { 
         public void performAction() {
             // swapt partial results to file.
         }

}

     Cipher c = CipherFactory.getCipher( file.size() );

возвратил бы корректный экземпляр стратегии для шифра.

я надеюсь, что это помогает.

(я даже не знаю, является ли Шифр правильным словом: P)

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

процесс, чтобы записать, что данные были затем довольно просты, продолжайте появляться от вершины приоритетной очереди и затем выберите стратегию на основе типа объекта, который Вы извлекаете.

Несколько недель назад я добавил общий интерфейс Java, который был реализован одним из наших объектов области. Этот объект области был загружен из базы данных, и представление базы данных было схемой "звезда" с приблизительно 10 + ответвления. Одно из последствий наличия такого тяжелого объекта области веса - то, что мы должны были сделать другие объекты области, которые представили ту же схему, хотя меньше тяжеловеса. Таким образом, я заставил другие легкие объекты реализовать тот же интерфейс. Помещенный иначе мы имели:

public interface CollectibleElephant { 
    long getId();
    String getName();
    long getTagId();
}

public class Elephant implements CollectibleElephant { ... }
public class BabyElephant implements CollectibleElephant { ... }

Первоначально, я хотел использовать CollectibleElephant для сортировки Elephant с. Довольно быстро, мои товарищи по команде glommed на CollectibleElephant для выполнения проверок безопасности отфильтруйте их, когда они отправляются на GUI, и т.д.

Я использовал подход стратегии в довольно сложном механизме в приложении, которое является хорошим примером. По существу роль механизма должна была пойти и сначала найти список людей, у которых был виджет, это - вторая роль, должен был выяснить, которые были 10 лучшими людьми с виджетом на основе неизвестного количества параметров (вещи как ценовое расстояние предыдущий бизнес вместе, сумма на запасе, варианты перевозки и т.д. и т.д. и т.д....)

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

Мы тогда также поняли, что у нас было несколько algorithims, некоторые были основаны на взвешивании параметров, другие были очень странными и propitery, и я не мог воздать им должное, не вытаскивая Visio и диаграммы, и хорошо Вы получаете изображение, у нас было много algorithims для выбора лучших людей.

Наш сервис сам был очень вещью, это по существу определило исходные данные, выводы и сделало некоторую нормализацию данных, это также привыкло шаблон поставщика для плагина специализированные поставщики данных и algorithim поставщики, которые использовали стратегию. Это было довольно эффективной системой.

у Нас были некоторые дебаты, если мы использовали стратегию или шаблонный шаблон, который мы никогда не разрешали.

Вы уверены, что состояние "порядка" не является шаблоном состояния? У меня есть догадка, что порядок не будет обработан по-другому в зависимости от его состояния.

Берут, например, метод Поставка на Порядке:

order.Ship();

• , Если способ доставки варьируется по функции своего состояния, то у Вас есть стратегическая модель.
• , Если однако Поставка () метод успешно выполняется только, когда порядок был заплачен, и заказ еще не был доставлен, у Вас есть шаблон состояния.

лучший пример шаблона состояния (и других шаблонов), который я нашел, был в книге" Главные Первые Шаблоны разработки ", который удивителен. Второй будет серия блоггинга David Cumps шаблонов .

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

я использую компонуемую стратегическую модель, чтобы сделать эту синхронизацию. Основная программа в основном выбирает основную стратегию в зависимости от дня недели (синхронизация изменяется единственный/синхронизирующий все), и время семестра относительно академического календаря. Если периодичность выставления счетов заканчивается, то она также составляет его с тарификационной стратегией. Это тогда выполняет выбранную стратегию через стандартный интерфейс.

я не знаю, насколько распространенный это, но я чувствовал, что это было идеальное пригодное для стратегической модели.

Одним из распространенных использование стратегии шаблон является определение пользовательских стратегий сортировки (на языках без функций более высокого порядка), например, Чтобы сортировать список строк по длине в Java, передавая анонимный внутренний класс (реализация интерфейса стратегии):

List<String> names = Arrays.asList("Anne", "Joe", "Harry");
Collections.sort(names, new Comparator<String>() {
  public int compare(String o1, String o2) {
    return o1.length() - o2.length();
  }
});
Assert.assertEquals(Arrays.asList("Joe", "Anne", "Harry"), names);

Аналогичным образом, стратегии могут быть использованы для нативных запросов с объектами баз данных, например, В DB4O:

List<Document> set = db.query(new Predicate<Document>() {
  public boolean match(Document candidate) {
    return candidate.getSource().contains(source);
  }
});

Могу привести несколько довольно простых примеров:

• Сортировка списка. Стратегией является сравнение, которое используется для того, чтобы решить, какой из двух пунктов списка является "Первым"
• У вас может быть приложение, в котором сам алгоритм сортировки (QuickSort, HeapSort и т.д.) может быть выбран во время выполнения
• Appenders, Layouts, and Filters в Log4Net и Log4j
• Layout Managers в наборах инструментов пользовательского интерфейса

• Data compressit. У вас может быть интерфейс ICompressor, единственный метод которого выглядит следующим образом:

  byte[] compress(byte[] input);

  Вашими конкретными классами компрессии могут быть такие вещи, как RunLengthCompression, DeflateCompression и т.д.