Bůh namítá - God object

Tento článek obsahuje a seznam doporučení, související čtení nebo externí odkazy, ale její zdroje zůstávají nejasné, protože jí chybí vložené citace. Prosím pomozte zlepšit tento článek představuji přesnější citace. (Březen 2012) (Zjistěte, jak a kdy odstranit tuto zprávu šablony)

v objektově orientované programování, a Bůh namítá je objekt že ví moc nebo dělá příliš mnoho. Objekt Bůh je příkladem anti-vzor.

Běžnou technikou programování je samostatný velký problém do několika menších problémů (a rozděl a dobýt strategii ) a pro každou z nich vytvořit řešení. Jakmile budou vyřešeny menší problémy, bude vyřešen velký problém jako celek. Proto daný objekt pro malý problém potřebuje vědět jen o sobě. Podobně existuje pouze jedna sada problémů, které musí objekt vyřešit: jeho vlastní problémy. Toto také následuje Princip jedné odpovědnosti.

Naproti tomu program, který využívá předmět Boha, tento přístup nenásleduje. Většina z celkové funkčnosti takového programu je zakódována do jediného „vševědoucího“ objektu, který udržuje většinu informací o celém programu a také poskytuje většinu metody za manipulaci s těmito údaji. Protože tento objekt obsahuje tolik dat a vyžaduje tolik metod, jeho role v programu se stává podobnou Bohu (vševědoucí a všeobjímající). Místo toho, aby programové objekty mezi sebou přímo komunikovaly, spoléhají se ostatní objekty v programu na většinu svých informací a interakcí na jediný Boží objekt. Protože tento objekt je úzce spojeno na (odkazováno) na tolik jiného kódu se údržba stává obtížnější, než by to bylo u rovnoměrněji rozděleného programovacího designu. Změny provedené v objektu ve prospěch jedné rutiny mohou mít nežádoucí účinky na jiné nesouvisející rutiny.

Bůh objekt je objektově orientovaný analog nepoužívání podprogramy v procedurální programovací jazyky nebo příliš mnoho použití globální proměnné ukládat informace o stavu.

Zatímco vytváření objektu God je obvykle považováno za špatnou programovací praxi, tato technika se občas používá v těsných programovacích prostředích (např mikrokontroléry ), kde je zvýšení výkonu a centralizace ovládání důležitější než udržovatelnost a elegance programování.

Viz také

• Ravioliho kód - opačný vzor

Další čtení

• Riel, Arthur J. (1996). „Kapitola 3: Topologie akčně orientovaných vs. objektově orientovaných aplikací“. Objektově orientovaná designová heuristika. Boston, Massachusetts: Addison-Wesley. ISBN  0-201-63385-X. 3.2: Nevytvářejte božské třídy / objekty ve vašem systému. Buďte velmi podezřelí z abstrakce, jejíž název obsahuje Driver, Manager, System nebo Subsystem.
• Anti-Patterns and Worst Practices - Monster Objects.