Multiton

Хотел написать о БД, но перед обсуждением некоторых решений полезно знать что-такое мультитон. Это не столь распространенный шаблон, но я его буду использовать - поэтому, коротко о нем.

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

class A {
    A()
}
class MyMultitone {
//probably, it's can be singletone
    //...
    A a;
    static A getA(){
        if(a == null){
            a = new A();
        }
        return a;
    }
    static B getB(){...}
}

где такое может понадобится? - уже скоро, будьте с нами, не переключайтесь!

Справедливости ради стоит заметить, что так-как мультитон не устоявшийся шаблон взгляды на него несколько разнятся: (еще одна статья о нем)

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

Абстрактная фабрика

Если я подойду к стойке бара и попрошу мне налить, то, в зависимости от заведения, мне могут налить совсем разные вещи хотя запрос был-то одинаков и я был тот-же.
К чему это я? Продолжаем нашу сагу о том, как не изобретать велосипед.
Бары это все хорошо, но далеко. Пусть есть классы кнопочек для графического интерфейса. Для каждой ОС они свои но я хочу получать кнопочку под текущую ОС и не напрягать себя лишними проверками. Что я делаю - создаю отдельный класс, который будет мне выдавать нужную мне кнопочку. Так.. пожалуй достаточно, надо ближе к коду.

Абстрактная кухня

public interface AbstractCook {
 Dish getDish();
 Drink getDrink();
}

Мексиканская кухня

public class MexicoCook imlements AbstractCook {
 @Override
 public Dish getDish(){
  return new Burrito();
 }
 @Override
 public Drink getDrink(){{
  return new Tequila();
 }
}

А вот немецкая

public class GermanCook imlements AbstractCook {
 @Override
 public Dish getDish(){
  return new Meat();
 }
 @Override
 public Drink getDrink(){{
  return new Bear();
 }
}

разница, думаю, заметна)

а теперь об использовании счастья

class User {
 eatSomething(AbstractCook cook){
  cook.getDish();
 }
}

В этом участке кода пользователь не знает что он съел, а значит можно писать программу для всех возможных вариантов пищеупотребления.

Переходим на новый уровень абстракции вместе!

Одиночка или синглетон

Как я и обещал, мы будем публиковать повести о разных шаблонных решениях.
Во многих языках программирования существует механизм глобальных переменных, помимо области размещения в памяти, они обладают свойством всеобщей доступности – в Java таких переменных нет. Зачем это может понадобиться нам, крутым проектировщикам, ведь глобальные переменные – зло? – А я хочу параметры настройки один раз читать из файла и потом их отовсюду использовать.

Следующая ситуация – иногда хочется иметь гарантию того, что будет создан только один экземпляр класса. Например, я кеширую данные или управляю соединением с БД.
Как решить эти проблемы – на помощь приходит шаблонное решение, который мы и обсудим.

Singleton – класс не имеющий доступного конструктора и создающийся путем вызова статического метода.
Реализация приписываемая Майерсу:

class God {
 private static God ourInstance;
 private God(){}
 public static God getInstance(){
  if(ourInstance == null){
   ourInstance = new God();
  }
  return ourInstance;
 }
}

Для сокращения количества строк (на 3 штуки – 30%!) и просветления можно использовать строку

return ourInstance == null ? ourInstance = new God() : ourInstance;

"Создавать" объект теперь надо так:
God foo = God.getInstance();

Стоит отметить что злоупотреблять таким решением не стоит, но учить надо.

Совсем забыл - существует альтернативное, простое, но менее гибкое решение. Жду предложения)

Design patterns

При создании ПО часто возникают аналогичные задачи. Это происходит на всех уровнях - от организации сортировки, работе с БД и т.д. . Для упрощения жизни создаются библиотеки утилиты и другие вкусности. На уровне проектирования для этого существуют - шаблонные решения (design patterns). Их довольно много и структурируются они относительно решаемых задач (создание объектов, поведение, работа с потоками и другие). Для того, что бы не изобретать постоянно велосипед, мы будем рассматривать основные из них - те, без знания которых страшно ложится спать.

Первые на очереди синглетон и фабрика.

Поехали.