CodeGym /Java блог /Случаен /Модели и Singleton в Java
John Squirrels
Ниво
San Francisco

Модели и Singleton в Java

Публикувано в групата
Тази статия е насочена към всеки, който за първи път се сблъсква с концепцията за шаблони на проектиране, чувал е термина singleton or по няHowъв начин е приложил модела singleton, но не е разбрал Howво се случва. Добре дошли! Студентите от CodeGym се сблъскват с шаблони за проектиране за първи път на ниво 15, когато капитанът неочаквано ги моли да „подсилят“ разбирането си чрез прилагане на шаблона Java Singleton с мързелива реализация. Учениците, които чуват за единичния модел за първи път, незабавно имат много въпроси: Howво, по дяволите, е дизайнерски модел? Защо ни трябва? Какво е сингълтон ? И накрая, Howво е мързелива реализация? Нека отговорим на тези въпроси по ред.

Какво, по дяволите, е дизайнерски модел?

Вярвам, че малко история е за да се отговори най-добре на този въпрос. Има четирима известни автори на програмиране (Erich Gamma, John Vlissides, Ralph Johnson и Richard Helm), които излязоха с интересна идея. Те забелязаха, че разработването на софтуер често изисква от тях да решават приблизително едни и същи проблеми и да пишат code, структуриран по същия начин. Затова те решиха да опишат типични модели, които често трябва да се използват в обектно-ориентираното програмиране. Тяхната книга е публикувана през 1994 г. под заглавието Design Patterns: Elements of Reusable Object-Oriented Software. Името на книгата се оказа твърде дълго и хората започнаха да я наричат ​​просто книгата на Бандата на четиримата. Първото издание включваше 23 модела. След това бяха открити десетки други модели.
Шаблонът за проектиране е стандартизирано решение на общ проблем.
И единичният модел е само един от тях.

Защо се нуждаем от шаблони за проектиране?

Можете да програмирате, без да знаете шаблони: в крайна сметка до ниво 15 вече сте написали стотици мини-програми на CodeGym, без дори да знаете, че съществуват. Това предполага, че шаблоните за проектиране са вид инструмент, чиято употреба отличава майстора от аматьора: Шаблоните за проектиране описват How правилно да се реши типичен проблем. Това означава, че познаването на модели ви спестява време. По този начин те са подобни на алгоритмите. Например, можете да създадете свой собствен алгоритъм за сортиране с блекджек и числаи прекарайте много време в това, or бихте могли да приложите такъв, който е разбран и описан от дълго време. Същото важи и за моделите на дизайна. Освен това, с шаблоните за проектиране, codeът става по-standardн и когато използвате подходящия шаблон, е по-малко вероятно да направите грешки, тъй като често срещаните клопки на шаблона бяха идентифицирани и елиминирани отдавна. Освен всичко останало, познаването на моделите помага на програмистите да се разбират по-добре. Можете просто да кажете името на шаблон, instead of да се опитвате да предоставите дълго обяснение на вашите колеги програмисти. Обобщавайки, шаблоните за проектиране ви помагат:
  • не преоткривайте колелото, а instead of това използвайте стандартни решения;
  • стандартизира code;
  • стандартизират терминологията;
За да завършим този раздел, отбелязваме, че цялото тяло от дизайнерски модели може да бъде разделено на три големи групи: Patterns и singleton - за всички, които се сблъскват с тях за първи път - 2

И накрая, единичният модел

Singleton е креативен модел . Този модел гарантира, че има само едно копие на клас и предоставя глобална точка за достъп за този обект. От описанието трябва да стане ясно, че този модел трябва да се прилага в два случая:
  1. когато вашата програма изисква да бъде създаден не повече от един обект от определен клас. Например една компютърна игра може да има клас герой и само един обект герой, който описва единствения герой в играта.

  2. когато трябва да предоставите точка за глобален достъп до обект. С други думи, трябва да направите обекта достъпен от всяка точка на програмата. Уви, не е достатъчно просто да създадете глобална променлива, тъй като тя не е защитена от запис: всеки може да промени стойността на променливата, така че глобалната точка за достъп на обекта може да бъде загубена. Тези свойства на Singleton са необходими, например, когато имате обект, който работи с база данни, и трябва да получите достъп до базата данни от различни части на програмата. Singleton ще гарантира, че никой не пише code , който замества създадения преди това екземпляр.
Така че Singleton задоволява тези две нужди: трябва да има само един от определен вид обект в програмата и трябва да има глобален достъп до него. В примера на ниво 15 капитанът ви моли да приложите този модел за следната задача:
  1. Намерете пример за Singleton с мързелива инициализация.

  2. Създайте три единични класа — Слънце, Луна, Земя — в отделни файлове, като използвате същия принцип.

  3. внедритеПланетаинтерфейс в класове Слънце , Луна и Земя .

  4. В статичен блок на класа Solution извикайтеreadKeyFromConsoleAndInitPlanetметод.

  5. Прилагане наreadKeyFromConsoleAndInitPlanetфункционалност на метода:

    • 5.1. Прочетете един низов параметър от конзолата

    • 5.2. Ако параметърът е equals на един отПланетаконстантите на интерфейса, създайте подходящ обект thePlanet .

След внимателно прочитане на условията на задачата можем ясно да разберем защо е необходим Singleton тук. Наистина, от нас се иска да създадем екземпляр на всеки от следните класове: Слънце , Луна , Земя . Логично е да приемем, че трябва да създадем не повече от едно Слънце/Луна/Земя. В противен случай попадаме в абсурдна ситуация, освен ако разбира се не пишете вашата version на Star Wars. Внедряване на модела Singleton в Java в три стъпки В Java поведението на Singleton не може да бъде реализирано с помощта на обикновен конструктор, тъй като конструкторът винаги връща нов обект. Следователно всички реализации на Singletonсе свеждат до скриване на конструктора, създаване на публичен статичен метод, който контролира живота на единичния обект и "унищожаване" на всички новопоявяващи се обекти. Ако има достъп до Singleton , той трябва or да създаде нов обект (ако такъв все още не съществува в програмата), or да върне съществуващ. За да постигнете това:
  1. Трябва да дадете на класа частно статично поле, което съхранява един обект:

    
    public class LazyInitializedSingleton {
    	private static LazyInitializedSingleton instance; // #1
    }
    
  2. Направете конструктора (по подразбиране) частен. Това означава, че не може да бъде достъпен извън класа и няма да може да връща нови обекти:

    
    public class LazyInitializedSingleton {
    	private static LazyInitializedSingleton instance;
    private LazyInitializedSingleton(){} // #2
    } 
    
  3. Декларирайте статичен метод за създаване, който ще се използва за получаване на сингълтон:

    
    public class LazyInitializedSingleton {
        private static LazyInitializedSingleton instance;
            private LazyInitializedSingleton() {}
            public static LazyInitializedSingleton getInstance() { // #3
            if (instance == null) { // If the object has not yet been created
                instance = new LazyInitializedSingleton(); // Create a new object
            }
            return instance; // Return the previously created object
        }
    }
    
Горният пример е донякъде тромав, тъй като ние просто скриваме конструктора и предоставяме наш собствен метод instead of standardн конструктор. Тъй като тази статия има за цел да гарантира, че студентите на CodeGym влизат в контакт с този модел (и моделите на проектиране като цяло), тук няма да бъдат описани нюансите на по-сложните сингълтън реализации. Отбелязваме само, че в зависимост от сложността на програмата, този модел може да се нуждае от допълнително усъвършенстване. Например, в многонишкова среда (вижте статии за нишки), няколко различни нишки могат да имат достъп до метода singleton едновременно и codeът, описан по-горе, ще спре да работи, тъй като всяка отделна нишка може да създаде екземпляр на класа. В резултат на това все още има няколко различни подхода за създаване на правилни безопасни за нишки сингълтони. Но това е друга история =)

И накрая... Каква е тази мързелива инициализация, за която питаше капитанът?

Мързеливата инициализация се нарича още отложена инициализация. Това е програмен трик, при който ресурсоемка операция (а създаването на обект е ресурсоемка операция) се извършва при поискване, а не предварително. И така, Howво всъщност се случва в нашия Singleton Java code? С други думи, нашият обект се създава в момента на достъпа до него, а не предварително. Не трябва да приемате, че мързеливата инициализация е няHow си твърдо свързана с модела Singleton . Мързеливата инициализация се използва и в други модели за създаване на дизайн, като прокси и фабричен метод, но това също е друга история =)
Коментари
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION