Názory ke článku Seriál návrhových vzorů – 1. díl
Nad tímto mě nikdy nenapadlo se zamyslet, díky za rozšíření obzorů.
#2
Přesně na tento článek jsem si vzpomněl, když jsem zde četl o Sigletonu.
25. 4. 2012
#2
Ten článek ale poukazuje pouze na obtížné zajištění implementace singletonu v PHP, ne že je obecně tento návrhový vzor zlo...
20. 5. 2012
Skoda, ze ste trochu viac nespomenuli aj vyhody / nevyhody, spravne / nespravne pouzitie vzorov. Takto je to trochu nekompletne, a menej skusenym programatorom to sposobi par trablov v buducnosti, ked to paterny zoberu ako dogmu, ze takto sa to ma lebo je to pattern a nenaucia sa hned od zaciatku rozmyslat, kedy a preco je vhodne patterny pouzit, resp. ktory vybrat.
Specialne by ma ta argumentacia zaujimala pri Utility patterne, ktory pokladam za zlo v tejto implementacii. Porusuje totiz programovanie proti interfejsu a znemoznuje/stazuje neskorsie rozsirenie triedy, teda dost podstatne zhorsuje znovupouzitelnost a zvysuje pocet zavislosti v kode, co pri vacsich projektoch alebo pri pokuse pouzit triedy v dalsich projektoch moze byt dost problem.
Pri servisne orientovanom dizajne ako alternativu ponukam za interfejsmi schovane funktory, namiesto statickych funkcii. Balickovanie vyriesi vhodne zabalenie do namespacov. Riesi to vyssie uvedene problemy a nenapada ziadna podstatna nevyhoda, mozno je to trochu viac pisania, ale uz strednedobo to isto stoji za to.
20. 5. 2012
#7 brano
Presnejsie. Utility pattern by sa podla mal pouzit iba, ak ste si *isty*, ze danu funkcnost nebudete potrebovat menit ani rozsirovat. Co je - skoro nikdy. Viem si predstavit zakladne algoritmy nad kontajnermi (v C++ STL), stringami (vyhladavanie, replace), obrazkami (resize), ak su napisane dost vseobecne. Ale pisat tak aplikacnu/biznis logiku mi pride vyslovene zly napad, z vyssie uvedenych dovodov, viac aj navrhove principy SOLID (prip. po cesky).
20. 5. 2012
Este by som sa chcel spytat, preco je to posledne pouzitie v casti prepravka s komentarom "bez prepravky" zle? Je zle vzdy, alebo len existuje situacia, v ktorom by taketo nieco bolo zle?
20. 5. 2012
#6 sgf
Singleton povazujem za zlo. 1. Problem akademicky. Porusuje Single responsibility. Podla mna by trieda nemala vytvarat sama seba. V beznom svete sa maslo nevyrobi samo, vyrobia ho v tovarni. Ked uz teda modelujeme tie objekty. 2. Problem prakticky. Na vytvorenie sa pouzije staticka metoda. Teda volajuci musi poznat presny typ triedy ktoru vola. Porusuje to programovanie proti interfejsu, vytvara explicitne zavislosti tam, kde by nevyhnutne nemuseli byt a stazuje to rozsiritelnost a vymenitelnost kodu, rovnako ako aj znovupouzitelnost. 3. Poznamka k implementacii, nie k vzoru ako takemu. V niektorych jazykoch (C++) nie je zarucene poradie inicializacie statickych premennych, co moze vies k problemom, ked mate singletony zavisle kdeako na sebe.
20. 5. 2012
#10 brano
Btw. restauracia je jedna, len pokym majitel neotvori novu prevadzku, a nebude chciet mat vsetko v jednom informacnom systeme. A kolko roboty sme si mohli usetrit.
Hezky a názorně vysvětleno:) Využil jsem při studiu ke zkoušce :D
Díky
26. 11. 2015
Ještě doplním, Singleton lze velmi dobře použít s výčtem ENUM.
Použití Singletonu s enum je automaticky thread-safe, viz http://www.algoritmy.net/article/1326/Singleton