Питання Що таке погано про синглетонів? [ЗАЧИНЕНО]


The єдиний малюнок є повністю оплаченим членом GoFс зразки книги, але це останнім часом здається сирітким у світі розробника. Я до сих пір використовую дуже багато синглтонів, особливо для заводські класи, і поки ви повинні трохи обережно ставитись до проблем із багатопотоковим (на зразок будь-якого класу), я не розумію, чому вони такі жахливі.

Стічні переповнення особливо здається припустити, що всі погоджуються з тим, що Singletons є зла. Чому?

Будь ласка, підтримайте свої відповіді за допомогою "фактами, посиланнями або спеціальними знаннями"


1737


походження


Я повинен сказати, що використання єдиного дизайну спалило мене нещодавно, тому що я намагався адаптувати цей код. Як я роблю це у вільний час, я майже ледачий, щоб переробити це. Погана новина для продуктивності. - Marcin
У відповідях багато "мінусів", але я також хотів би побачити деякі хороші приклади того, коли модель добре, щоб протиставити себе поганому ... - DGM
Я написав повідомлення блогу на цю тему кілька місяців тому: jalf.dk/blog/2010/03/... - і дозвольте мені просто сказати це прямо. Я не можу особисто думати про єдину ситуацію, коли синглтон є правильним рішенням. Це не означає, що така ситуація не існує, але ... називаючи їх рідкісним - це заниження. - jalf
@AdamSmith це не означає, що ти мати до, але це означає, що ви може отримати доступ до нього так. І якщо ви не маєте наміру доступу до нього так, то є мало причин, щоб зробити це єдиним в першу чергу. Отже, ваш аргумент насправді "немає шкоди для створення singleton, якщо ми цього не робимо лікувати це як синглтон. Так, здорово. Моя машина також не забруднює, якщо я не їздити в цьому. Але тоді легше просто не придбати машину в першу чергу. ;) (повне розкриття: у мене фактично немає машини) - jalf
Найгірша частина цієї всієї теми полягає в тому, що люди, які ненавидять одиночні люди, рідко дають конкретні пропозиції щодо того, що використовувати замість них. Наприклад, посилання на журнальні статті та саморозповсюджувані блоґи наведено далі ні використовувати синглетони (і всі вони чудові причини), але вони надзвичайно тонкі на заміни. Багато ручної роботи, хоча. Ті з нас, що намагаються навчити нових програмістів, чому б не користуватися singletons, не мають багатьох чудових контрприслів сторонніх розробників, щоб вказати лише придумані приклади. Це втомило. - Ti Strga


Відповіді:


Парафраз з Брайан Баттон:

  1. Як правило, вони використовуються як глобальні приклади, чому це так погано? Оскільки ви закриваєте залежності вашої програми в своєму коді, замість того, щоб експонувати їх через інтерфейси. Зробити щось глобальне, щоб уникнути передачі навколо це запах коду.

  2. Вони порушують принцип єдиної відповідальності: в силу того, що вони контролюють власне створення та життєвий цикл.

  3. Вони по суті призводять до того, що код буде жорстким пов'язаний. Це робить тестування їх під час тестування досить складним у багатьох випадках.

  4. Вони несуть державний стан протягом усього життя програми. Ще один удар по тестуванню, оскільки в вас може виникнути ситуація, коли потрібно замовити тести, які є великими, ні для тестування одиниць. Чому? Оскільки тестування кожного підрозділу має бути незалежним від іншого.


1148



Я не згоден з тобою. Оскільки коментарям дозволено лише 600 символів, я написав публікацію блогів, щоб прокоментувати це, будь ласка, перегляньте посилання нижче. jorudolph.wordpress.com/2009/11/22/singleton-considerations - Johannes Rudolph
Що стосується пунктів 1 та 4, то я думаю, що singletons корисні, і насправді майже ідеально підходять для кешування даних (особливо з БД). Зростання продуктивності далеко відстає від ускладнень, пов'язаних з тестуванням моделей одиниць. - Dai Bok
@Dai Bok: "Для кешування даних (особливо з БД)" використовуйте проксі-шаблон для цього ... - paxos1977
Вау, відмінні відгуки. Напевно, я використовував тут надто агресивну формулювання, тому, будь ласка, майте на увазі, що я відповідаю на негативно сформоване питання. Мій відповідь мав бути коротким списком "анти-візерунків", які трапляються внаслідок поганого використання Сінглтона. Повне розкриття; Час від часу я також використовую Singletons. Існує набагато нейтральніші запитання стосовно СО, що дадуть чудові форуми, коли Сінглтони можна вважати гарною ідеєю. Наприклад, stackoverflow.com/questions/228164/... - Jim Burger
Вони не настільки великі для кешування в багатопоточному середовищі. Ви можете легко перемогти кеш з декількома темами, що борються за обмежений ресурс. [підтримується синглтон] - monksy


Синглетони вирішують одну (і лише одну) проблему.

Суперечка з ресурсами.

Якщо у вас є якийсь ресурс

(1) може мати лише один екземпляр, і

(2), вам потрібно керувати цим єдиним екземпляром

вам потрібен а синглтон.

Є немало прикладів. Файл журналу є великим. Ви не хочете просто відмовитися від одного файлу журналу. Ви хочете обмити, синхронізувати і закрити його належним чином. Це приклад єдиного спільного ресурсу, який потрібно керувати.

Це рідко, коли вам потрібен синглтон. Причина, чому вони погані, - це те, що вони почуваються як глобальний і вони повністю оплачені членом GoF Шаблони дизайну книга

Коли ви думаєте, що вам потрібна глобальна, ви, напевно, роблять жахливу помилку дизайну.


399



Обладнання - це також приклад? Вбудовані системи мають багато апаратного забезпечення, яке може використовувати синглтони - або, можливо, один великий? <усмішка> - Jeff
Повністю згоден. Там дуже багато чітко визначено, що "ця практика погана" розмовляє, плаваючи навколо без будь-якого визнання, що практика може мати своє місце. Часто ця практика є лише "поганою", оскільки її часто використовують неправильно. Існує нічого принципово невірного з шаблоном Сінглтона, якщо воно застосовується належним чином. - Damovisa
Реальні, за принципом синглетони дуже рідкі (і черга принтера, звичайно, не одна, і це не файл журналу - див. Log4j). Частіше за все, апаратне забезпечення - це синглтон за збігом, а не за принципом. Все обладнання, підключене до ПК, в кращому випадку є випадковим синглтоном (думаю, кілька моніторів, мишей, принтерів, звукових карт). Навіть детектор частинок 500 мільйонів доларів є одиночним за збігом і бюджетними обмеженнями, які не застосовуються в програмному забезпеченні, таким чином: немає одиночного. У телекомунікаціях ні телефонний номер, ні фізичний телефон не є одиночними (думаю ISDN, call-центр). - digitalarbeiter
Обладнання може мати лише один екземпляр різноманітних ресурсів, але обладнання не програмне забезпечення. Немає причин, що єдиний послідовний порт на платі розвитку повинен бути моделюється як Singleton. Дійсно, моделюючи це так, тільки ускладнить з'єднання з новою платою, яка має два порти! - dash-tom-bang
Отже, ви повинні написати два однакових класів, копіюючи багато коду, просто так, ви можете мати два синглетони, що представляють два порти? Як просто використовувати два глобальні об'єкти SerialPort? Як не моделювати апаратні засоби як класи взагалі? І чому б ви використовували синглетони, що також означає глобальний доступ? Ти хочеш кожен функція у вашому коді, щоб мати доступ до послідовного порту? - jalf


Деякі кодируючі сноби дивляться на них як на прославлену глобальну. Так само, як багато людей ненавидять йти до висловлювання Є інші, які ненавидять ідею коли-небудь використовувати глобальний. Я бачив, як деякі розробники йдуть надзвичайно довго, щоб уникнути глобальний тому що вони вважали використання одного як допущення провалу. Дивно, але правда.

На практиці Синглтон шаблон - це просто програма, яка є корисною частиною вашого набору інструментів концепцій. Час від часу ви можете виявити, що це ідеальне рішення, і тому його використовуйте. Але використовуючи це просто так ви можете похвалитися використанням a шаблон дизайну є настільки ж дурним, як і відмову будь-коли використовувати його, тому що це просто а глобальний.


307



Невдача, яку я бачу в Сінглтоні, полягає в тому, що люди використовують їх замість глобалів, оскільки вони як-то "кращі". Проблема (як я бачу), що речі, які Синглтон приносить до столу у цих випадках, не мають значення. (Конструкція-на-перше використання є тривіальним для реалізації в не-синглтоні, наприклад, навіть якщо це фактично не використовується конструктором для цього). - dash-tom-bang
Причина, яку ми "дивимося" на них, полягає в тому, що "ми" дуже часто бачимо, що вони звикли неправильно, і це дуже часто. "Ми" знаємо, що у них є місце справи. - Bjarke Freund-Hansen
@ Філ, ви сказали: "час від часу ви можете виявити, що це ідеальне рішення, і, отже, використовуйте його". Гаразд, так точно котрий Справа, чи будемо ми виявити корисну одиницю? - Pacerier
@Pacerier щоразу, коли виконуються всі наступні умови: (1) вам потрібен лише щось, (2) вам потрібно передавати цю одиницю як аргумент у великій кількості викликів методу, (3) ви готові прийняти шанс щось перезаписатися коли завгодно в обмін на негайне зменшення розміру та складності вашого коду, не пропускаючи шкідливу річ навколо скрізь. - antinome
Я не відчуваю, що це відповідає ні на що, він просто говорить, що "іноді це може підходити, інколи це не може". Добре, але чому і коли? Що робить цю відповідь більш ніж на Аргумент до модерації? - Guildenstern


Міско Еверіді, від Google, має кілька цікавих статей саме у цій темі ...

Синглетони - патологічні брехуни має приклад тестування одиниці вимірювання, який показує, як синглтони можуть ускладнити виявлення ланцюгів залежності та запуску або тестування програми. Це досить екстремальний приклад зловживань, але те, що він робить, все ще є дійсним:

Сінглетони - це не що інше, як глобальна держава. Глобальна держава робить це таким чином, щоб ваші об'єкти могли таємно перебирати речі, які не заявлені у своїх API-інтерфейсах, і, як наслідок, Singletons перетворюють ваші API на патологічних брехунів.

Де пройшли всі Singletons вказує на те, що ін'єкції залежності дозволяють легко отримати екземпляри для конструкторів, які потребують їх, що полегшує основну потребу позаду поганих глобальних Singletons decried в першій статті.


200



Статті Міско на цю тему - це найкраще, що відбувається на цьому момент. - Chris Mayer
Перша ланка фактично не вирішує проблему з синглетонами, а скоріше припускає статичну залежність всередині класу. Можна виправити даний приклад, пропустіть параметри, але все одно використовуйте синглетони. - DGM
@ DGM: Точно - насправді, існує величезний логічний від'єм між розділом "обгрунтування" та частиною "Одиночники є причиною". - Harper Shelby
Стаття кредитної картки Misko - це крайній приклад неправильного використання цієї моделі. - Alex
Читання другої статті Singletons насправді є частиною описаної моделі об'єкта. Однак, замість того, щоб бути доступними в усьому світі, вони є приватними для об'єктів Factory. - FruitBreak


Я думаю, що плутанина обумовлена ​​тим фактом, що люди не знають реального застосування моделі Синглтона. Я не можу цього підкреслити. Сінглтон є ні шаблон для обертання глобалів. Шаблон Singleton повинен використовуватися лише для того, щоб гарантувати це один і єдиний екземпляр даного класу існує під час роботи.

Люди думають, що Сінглтон є злом, тому що вони використовують його для глобальних голосів. Саме через цю плутанину Сінглтон дивиться вниз. Будь ласка, не плутати Синглтони та Глобали. Якщо використовується для цілей, для яких вона була призначена, ви отримаєте надзвичайні переваги від моделі Синглтона.


103



Що таке один примірник, доступний у всьому додатку? Ой Глобальний. "Синглтон є ні шаблон для обертання глобалів "або наївний, або оманливий, як за визначенням, шаблон обгортає клас навколо глобального екземпляра. - cHao
Звичайно, ви можете створювати один екземпляр класу, коли починається ваша програма, і вставляти цей екземпляр через інтерфейс у щось, що його використовує. Реалізація не повинна турбуватися, що може бути лише один. - Scott Whitlock
@Dainius: Нарешті, це не так. Звичайно, ви не можете довільно замінити екземпляр іншим. (За винятком тих, що викликають facepalm моменти, коли ви робите. Я дійсно бачив setInstance Проте це важко, хоча це те, що навряд чи важливо, - що той факт, що "необхідний" синглтона також не знав, як тремтять речі про інкапсуляцію, або що не так з мінливою глобальною державою, тому він допоміжним чином (?) надав сетери для кожного. сингл поле (І так, це трапляється багато. Майже кожна сингл, яку я коли-небудь бачив у дикій природі, міг змінюватися за дизайном, і часто це незрозуміло.) - cHao
@Dainius: У великій мірі ми вже маємо. "Переважна композиція над успадкуванням" вже давно є справою. При спадщині є Безумовно, найкращим рішенням ви, звичайно, можете користуватися ним. Однакова річ з синглетонами, глобалами, різьбленням gotoі т. д. Вони можуть робота у багатьох випадках, але, чесно кажучи, "творів" недостатньо - якщо ви хочете йти проти звичайної мудрості, ви краще зможете продемонструвати, як ваш підхід краще ніж звичайні рішення. І я ще не бачив такого випадку для моделі Сінглтона. - cHao
Щоб ми не спілкувалися один з одним, я не просто говорив про загальнодоступний екземпляр. Для цього є багато випадків. Те, про що я говорю (зокрема, коли я кажу "capital-S Singleton") - це структура SingleFold GoF, яка вкладає цей єдиний глобальний екземпляр у самий клас, виставляє його через getInstanceабо аналогічним чином названий метод, і запобігає існуванню другої інстанції. Чесно кажучи, у такому разі ви, можливо, навіть не мають один екземпляр - cHao


Одна досить погана річ про синглетони полягає в тому, що ти не можеш розширити їх дуже легко. Ви в основному повинні будувати в певному вигляді візерунок декоратора або якась така річ, якщо ви хочете змінити свою поведінку. Крім того, якщо в один прекрасний день ви хочете мати кілька способів зробити це одне, це може бути досить важким для зміни залежно від того, як ви викладете свій код.

Слід зауважити, що, якщо ви використовуєте синглетони, спробуйте передати їх тим, хто їх потребує, а не мати доступ до нього безпосередньо ... Інакше, якщо ви коли-небудь вирішите мати кілька способів зробити те, що робить синглтон, це буде досить важко змінити, оскільки кожен клас вбудовує залежність, якщо він безпосередньо отримує доступ до singleton.

Так в основному:

public MyConstructor(Singleton singleton) {
    this.singleton = singleton;
}

а не:

public MyConstructor() {
    this.singleton = Singleton.getInstance();
}

Я вірю, що такий зразок називається ін'єкція залежності і, як правило, вважається гарною справою.

Як і будь-який шаблон, хоча ... Подумайте про це і подумайте, чи його використання в даній ситуації є невідповідним чи ні ... Правила, як правило, порушуються, і візерунки не слід застосовувати волі ніколи без думки.


71



Гей, якщо ви робите це скрізь, то вам доведеться передати посилання на singelton скрізь і, отже, у вас більше немає синглтона. :) (Котрий, як правило, хороша IMO.) - Bjarke Freund-Hansen
@ BjarkeFreund-Hansen - Нісенітниця, про що ти говориш? Синглтон - це просто екземпляр класу, який інстатируется один раз. Посилання на такий синглтон не копіює фактичний об'єкт, він просто посилається на нього - ви все-таки отримали той самий об'єкт (читай: Singleton). - M. Mimpen
@ M.Mimpen: Ні, капітал-S Singleton (це те, що обговорюється тут) є екземпляром класу, який (а) гарантії що тільки один екземпляр коли-небудь буде існувати, і (б) буде доступ через власну вбудовану глобальну точку доступу класу. Якщо ви заявили, що нічого не слід кликати getInstance(), то (б) не зовсім вірно. - cHao
@cHao я не слідкую за тобою або ти не розумієш, кого я коментую - а це Бьярк Фройнд-Хансен. Б'ярк стверджує, що маючи декілька посилань на одиночну таблицю, має кілька синглтонів. Це, звичайно, не так, оскільки немає глибоких копій. - M. Mimpen
@ М.Мімпен: Я беру його коментар, щоб більше послатися на семантичний ефект. Як тільки ви забороните дзвінки getInstance(), ви ефективно викинули одну корисну різницю між схемою Синглтона та звичайним посиланням. Що стосується решти коду, одинокість більше не є власністю. Тільки дзвонив getInstance() коли-небудь потрібно знати або навіть дбати про те, скільки випадків існує. Тільки з одного абонента, він більше коштує та гнучкість для класу, щоб надійно виконувати єдину силу, ніж для того, щоб абонент просто зберігав посилання та повторно його використовував. - cHao


Єдиний малюнок не є проблемою сама по собі. Проблема полягає в тому, що цей шаблон часто використовується людьми, які розробляють програмне забезпечення з об'єктно-орієнтованими інструментами, не маючи міцного розуміння OO-концепцій. Коли в цьому контексті вводяться синглетони, вони, як правило, перетворюються на некеровані класи, які містять допоміжні методи для кожного невеликого використання.

Синглетони також є проблемою з точки зору тестування. Вони схильні робити ізольовані одиничні тести важко написати. Інверсія контролю (IoC) і ін'єкція залежності це шаблони, призначені для подолання цієї проблеми в об'єктно-орієнтованій формі, що піддається самостійному тестуванню.

В сміття збирається середовище синглетони може швидко стати проблемою щодо управління пам'яттю.

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


65



Я знаю, це багаторічна тема. привіт @ Kimoz ви сказали: - синглтони можуть швидко стати проблемою щодо управління пам'яттю. Хотів би детальніше пояснити, якою може бути проблема, пов'язана з колекцією одиночних та сміття. - Thomas
@ Кімоз, запитання "Чому єдиний модель не є проблемою сама по собі?" і ви просто повторили цю точку, але не надали навіть жодного допустимого випадку використання шаблону singleton. - Pacerier
@Томас, тому що за одним визначенням існує лише один екземпляр. Отже, зазвичай складно присвоїти єдину посилання на нуль. Це можна зробити, але це означає, що ви повністю контролюєте точку, після якої синглтон не використовується у вашому додатку. І це рідко, і, як правило, зовсім протилежне тому, що шукають одиночні ентузіасти: простий спосіб зробити єдиний примірник завжди доступний На деяких DI-програмах, таких як Guice або Dungeon, неможливо позбутися синглтона і воно залишається назавжди в пам'яті. (Незважаючи на те, що контейнер із синглетонами набагато краще, ніж домашні). - Snicolas


Синтетон реалізується за допомогою статичного методу. Статичні способи уникаються людьми, які проводять тестування, тому що їх не можна висміювати або придушувати. Більшість людей на цьому сайті є великими прихильниками одиничного тестування. Як правило, найбільш прийнятна конвенція, щоб уникнути їх використання інверсія контролю візерунок


52



Це більше схоже на проблему, пов'язану з тестуванням пристроїв, які можуть перевіряти об'єкти (одиниці), функції (блоки), цілі бібліотеки (блоки), але не виконувати будь-які статичні дії у класі (також одиниці). - v010dya
Чи не вважаєте ви, щоб у будь-якому випадку приховати всі зовнішні посилання? Якщо ви, то в чому полягає проблема з moc singleton, якщо ні, чи дійсно ви проводите тестування? - Dainius
@ Dainius: знущання випадки набагато менше проблем, ніж глузування класів. Ви могли б екстрагувати іспитовий клас з іншої частини програми та перевірити підробкою Singleton клас Однак це надзвичайно ускладнює процес тестування. Для одного, тепер вам потрібно буде вивантажувати класи за бажанням (не дуже варіант для більшості мов) або запустити нову віртуальну машину для кожного тесту (прочитайте: тести можуть тривати тисячі разів). Для двох, однак, залежність від Singleton це деталі впровадження, яка тепер витікає з усіх ваших тестів. - cHao
Powermock може зловживати статичним матеріалом. - Snicolas


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

Розглянемо таку ситуацію: як розробник, вам потрібно створити веб-додаток, що має доступ до бази даних. Щоб забезпечити, щоб одночасні виклики бази даних не конфліктували один з одним, ви створюєте thread-save SingletonDao:

public class SingletonDao {
    // songleton's static variable and getInstance() method etc. omitted
    public void writeXYZ(...){
        synchronized(...){
            // some database writing operations...
        }
    }
}

Таким чином, ви впевнені, що існує лише одна сингл у вашій програмі, і вся база даних проходить через це SingletonDao. Сьогодні ваше виробниче середовище виглядає так: Single Singleton

Все добре, поки що.

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

Many singletons

Це звучить дивно, але тепер у вашому додатку є багато синглтонів. І це саме те, що синглтон не повинен бути: має багато об'єктів. Це особливо погано, якщо ви, як показано в цьому прикладі, хочете зробити синхронізовані дзвінки в базі даних.

Звичайно, це приклад поганого використання синглтона. Але повідомлення цього прикладу є таким: Ви не можете покладатися на те, що у вашій програмі є рівно один екземпляр синглтона, особливо коли мова йде про кластеризацію.


42



якщо ви не знаєте, як реалізувати синглтон, ви не повинні це робити. Якщо ви не знаєте, що ви робите, ви повинні з'ясувати, що перше, і тільки після цього зробити те, що вам потрібно. - Dainius
Цікаво, у мене є питання. Тож яка саме проблема, якщо синглетони - кожен на іншому комп'ютері / JVM - підключаються до єдиної бази даних? Обсяг Singletons є лише для цього конкретного JVM, і це все ще є вірним навіть у кластері. Замість того, щоб просто філософсько сказати, що ця конкретна ситуація є поганою, оскільки наше намір було єдиним об'єктом в рамках програми, я був би радий побачити будь-які технічні проблеми, які можуть виникнути внаслідок цієї процедури. - Saurabh Patil


  1. Це легко (ab) використовується як глобальна змінна.
  2. Класи, що залежать від синглетсонів, відносно складніше для одиничного тесту в ізоляції.

34





Монополія - ​​це диявол і синглетони з невизначеним / змінюваним станом справжньої проблеми ...

Після прочитання Синглетони - патологічні брехуни як це було запропоновано в відповідь Джейсона Я наткнувся на цю маленьку лаконіку, яка надає найкращий приклад як синглетони часто використовуються неправильно.

Глобальний поганий, тому що:

  • a. Це викликає конфлікт імен
  • б Це викриває державу необгрунтовано

Коли мова заходить про Singletons

  • a. Явний спосіб їх називати їх, запобігає конфліктам, тому наведіть a. це не проблема
  • б Сіндлетони без держави (як фабрики) не є проблемою. Синглетони з державою можуть знову опинитися в двох категоріях: ті, які незмінними або пишуть один раз і читати багато (config / files). Це не погано. Змінні Сінглтони, які є тими, яким ти говориш.

У останньому заяві він згадує концепцію блогу "синглетони - брехуни".

Як це стосується монополії?

Щоб почати гру монополії, спочатку:

  • Перш за все ми встановлюємо правила, щоб кожен знаходився на тій же сторінці
  • кожному дано рівний початок на початку гри
  • Тільки один набір правил представлений, щоб уникнути плутанини
  • правила не можуть змінюватися протягом всієї гри

Тепер для когось, хто цього не зробив дійсно грали монополію, ці стандарти ідеальні в кращому випадку. Поразка в монополії важко проковтнути, оскільки монополія - ​​це гроші, якщо ви програєте, вам доведеться ретельно спостерігати за тим, як решта гравців закінчують гру, і втрати зазвичай бувають швидкими та дробовими. Отже, правила, як правило, згорнуті в певний момент, щоб служити інтересам деяких гравців за рахунок інших.

Отже, ти граєш монополією з друзями Боба, Джо та Едом. Ви стрімко будуєте свою імперію і витрачаєте частку ринку на експоненціальну ставку. Ваші супротивники слабшають, і ви починаєте пахнути кров'ю (образно). Ваш приятель Боб поставив всі свої гроші в мережу, щоб створити якнайменше дешеві властивості, але він не отримує високої рентабельності інвестицій, як він очікував. Боб, як удар невдачі, опускається на ваш Boardwalk і вилучається з гри.

Тепер гра йде від дружніх кубиків до серйозного бізнесу. Боб був зроблений на прикладі провалу, і Джо та Ед не хочуть вдаватися, як "цей хлопець". Отже, будучи провідним гравцем, ви раптово стаєте ворогом. Джо та Ед починають займатися під торгівельними операціями за столом, ін'єкціями за спиною, недооціненими обмінними послугами і взагалі щось, щоб послабити вас як гравця, поки один з них не підніметься на вершину.

Тоді, замість того, щоб одне з них перемогти, процес починається зовсім. Раптово кінцевий набір правил стає рухомим об'єктом, і гра переростає у тип соціальних взаємодій, які складуть основу кожного високо оціненого телевізійного шоу реальності з тих пір, як Survivor. Чому, оскільки правила змінюються, і немає єдиної думки щодо того, як / чому / що вони повинні представляти, і що ще важливіше, ніхто не приймає рішення. Кожен гравець у грі, в той момент, робить свої власні правила, і хаос відбувається, поки двоє з гравців занадто втомилися, щоб тримати шараді і повільно здаватися.

Отже, якщо журнал правил для гри точно представляв одиночний, то монопольний зразок правил стане прикладом зловживань.

Як це стосується програмування?

Окрім усіх очевидних проблем потокової безпеки та синхронізації, що містять змінні синглетони ... Якщо у вас є один набір даних, який можна одночасно читати / маніпулювати кількома різними джерелами одночасно і існувати протягом всього терміну виконання програми, це, напевно, хороший час, щоб відступити і запитати: "Чи я тут використовую правильний тип структури даних".

Особисто я бачив, як програміст зловживає синглтон, використовуючи його як певну схему зшивання бази даних перехресного потоку в додатку. Працюючи над кодом безпосередньо, я можу засвідчити, що це було повільним (через все замикання нитки, необхідні для того, щоб зробити його безпечним для потоку) і кошмар для роботи (через непередбачуваний / переривчастий характер помилок синхронізації), і практично неможливо випробувати під "виробничими" умовами. Звичайно, система могла бути розроблена з використанням опитування / сигналізації, щоб подолати деякі проблеми продуктивності, але це не вирішить проблеми з тестуванням, і чому турбує, коли "реальна" база даних може вже виконувати ті самі функції набагато більш надійною / масштабована манера.

Є Сінглтон тільки варіант, якщо вам потрібен те, що забезпечує singleton. Запис-єдиний екземпляр об'єкта. Це ж правило повинно бути каскадом для властивостей / учасників об'єкта.


30



Що робити, якщо одиночка готує деякі дані? - Yola
@Yola Це дозволить скоротити кількість записів, якщо синглтону планується оновити за заданим та / або фіксованим графіком, тим самим зменшуючи спонукання до потоку. Тим не менше, ви не зможете точно перевірити будь-який код, який взаємодіє з одиночним, якщо ви не придумаєте екземпляр, який не єдина, що імітує таке саме використання. Люди TDD, ймовірно, будуть придатні, але це буде працювати. - Evan Plaice
@EvanPlaice: Навіть з макетом, у вас є деякі проблеми з кодом, який говорить Singleton.getInstance(). Мова, яка підтримує відображення, може працювати навколо цього, встановивши поле, в якому зберігається One True Instance. ІМО, однак, тести стають трохи менш надійними, як тільки ви приймаєте на обговорення з приватною державою іншого класу. - cHao