Шаблон Одинак (Singleton Pattern)

Головна > Java, Програмування > Шаблон Одинак (Singleton Pattern)

Шаблон Одинак (Singleton Pattern)

Вересень 12th, 2009 admin Напиши коментар До коментарів

Вітаю всіх! Перший пост у своєму блозі я вирішив присвятити шаблону об’єктно-орієнтованого дизайну Одинак (анг.: Singleton). Перед початком потрібно вказати, що таке взагалі шаблони проектування. Шаблони проектування (Design pattern) – це загальний підхід до вирішення задач проектування програмного забезпечення, що можна повторно використовувати. Це, фактично, кращі практики в програмуванні. Інколи при створенні програмних продуктів виникає потреба у обмеженні кількості екземплярів деякого класу до одного, тобто в будь-який момент часу може існувати не більше 1-го об’єкту деякого класу. Для чого це може знадобитися? Ось перелік ситуацій, коли використання цього шаблону виправдане:

тоді, коли об’єкти являють собою загальний стан програми;
різноманітні менеджери об’єктів та фабрики класів;
створення об’єктів потребує значних затрат часу чи інших ресурсів.

Діаграма класів при цьому підході виглядає так:

Singleton UML class diagram Шаблон Одинак (Singleton Pattern)

Тепер до технічної реалізації. Одна із самих відомих імплементацій цього шаблону виглядає так:

public final class Singleton {
    private static Singleton _instance = null;
 
    private Singleton() {}
 
    public static synchronized Singleton getInstance() {
        if (_instance == null)
            _instance = new Singleton();
        return _instance;
    }
}

Конструктор даного класу оголошений приватним, тобто створення цього класу за допомогою оператора new неможливо. Через це ми вказали цей клас фінальним. Створення екзепляру відбувається за допомогою методу getInstance(). Як видно із коду, створення нового об’єкту відбувається тільки тоді, коли змінна _instance не ініціалізована. Але вже після першої ініціалізації буде повертатися вже готовий створений об’єкт. Ще одна деталь: яка бачимо, метод getInstance() оголошений за допомогою модифікатору synchronized. Це зроблено для того, щоб уникнути виникнення ситуації, коли декілька потоків входять в цей метод і можуть створити декілька екземплярів. Але захист від помилок в багатопоточних програмах може викликати проблеми зі швидкістю роботи. Щоб вберегтися від цього, використовують блокування із подвійною перевіркою, яке є більш оптимальним, але знову ж таки, в багатопоточних програмах виникають дуже “цікаві” ситуації. Які? Про це буде написано в наступному пості. До наступних зустрічей!