[Английска версия на статията може да намерите тук].
Този пост отворя поредица от статии за моделите на дизайна. Всичко, което съм написал се основава единствено на личен опит.
Дизайн модели - описание на някои от проблемите, възникнали по време на обектно-ориентиран дизайн, както и начините за отстраняването им (както теоретически и практически). С други думи - това са примери за правилния подход за решаване на общи проектни задачи.
А просто прилагане на Singleton
Един от най-лесните начини за прилагане на модела Сингълтън в Java изглежда така:
Сега аз дам някои обяснения за прилагането на шаблона.
getInstance () метод ще създаде точно един екземпляр на Сингълтън. Този метод е обявен синхронизирани. Това беше направено, за добра причина. В многонишкова програма, докато getInstance на метод повикване () от множество потоци, може да създаде няколко екземпляра Singleton клас. И не може да има само един!
От синхронизирано модификатор може да се елиминира. За да направите това, трябва да се инициализира _instance:
и метод getInstance () премахване конструкт "ако". След това, по време на инициализация случва клас натоварване.
Но използването на късна инициализация (късна инициализация) е за предпочитане при създаването на инстанция на класа отнема много време. И в случай на късна инициализация, че е възможно да се справи с положението, произтичащо isklyuchitalnye чрез конструктора.
Singleton с двойна проверка заключване
Проблемът с късна инициализация е само в тази синхронизация е необходимо по принцип само веднъж, на няколко реки не са включени в критичния участък едновременно. Но след създаването на клас от синхронизация например бих искал да се отърве от.
Най-разпространеният начин да се отървем от ненужните синхронизация - е двойно проверени заключване, който изглежда така:
Сингълтън с Титуляр съд
И тук е друг забележително изпълнение на единния шаблона с късна инициализация:
Обектът ще се инициализира по време на първата покана за getInstance на метод (). Тоест, ние сме прехвърля проблема за синхронизация на нивото на зареждане на класа (клас товарач).
Но какво, ако заявлението няколко Class Loader'ov или имаме разпределена система с множество Java virtualnmi машини? След това е сложно. Ще говорим за това друг път.
Като цяло, това е сега модерно да се казва, наистина страхотно версия на модела Сингълтън изглежда така:
Това е всичко. А, да! Защо имаме нужда от него.
Практически пример за Сингълтън
Често съм се използва този модел, когато се занимават с конфигурацията. Понякога програмата за конфигурация е удобно да се съхранява във файл. Да кажем, че това е обикновен текстов файл "props.txt" с ред като "ключ = стойност". Трябва да се гарантира, че конфигурацията на програмата е уникална. На второ място, ние не бихме създали така, но вие трябва да направите е да се забрани на класа потребител. По този начин,
Сега за конфигурация можете да използвате този вид структура:
Ако имената на имотите в "props.txt" няма да се промени, че е възможно да ги опише в един клас, като това:
и стойностите, получени, както следва:
Сингълтън модел е полезен не само при работа с конфигурации. Тя може да се използва при писане на ConnectionPool, Фабрика и други неща.
Сега точно всичко.
Свързани статии