Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Системный анализ, проектирование и UML > Божественный объект


Автор: Smorodin 24.10.2012, 10:33
Добрый день!
Прошу порщения, если не в тот раздел.

Цитата

В объектно-ориентированном программировании божественный объект (англ. God object) — это объект, который хранит в себе «слишком много» или делает «слишком много». Является примером анти-паттерна.
Основная идея модульного программирования состоит в том, что большая задача делится на меньшие относительно независимые подзадачи (принцип «разделяй и властвуй»). В развитии модульного программирования — объектно-ориентированном программировании — этот принцип выражается в создании множества объектов, каждый из которых решает только свою собственную задачу.
Подход «божественного объекта» противоположен этому принципу: основная часть функциональности программы кодируется в одном объекте. Так как этот объект хранит большое количество данных и имеет много методов, его роль в программе становится «божественной» (всеобъемлющей).


И вот конкретная ситуация:

есть некий класс API:

Код

class API_Class {
    public var DB;
    public var CACHE;
    // и так далее

    public function initDB(array CONF) {
        this.DB = new DataBase(CONF);
    }
}


и используется он так:
Код

var API = new API_Class;
API.initDB(CONF);


И где нибудь в модуле/подсистеме:
Код

global API;
API.DB.execute(QUERY);


То есть API - это некое хранилище, посредник к другим независимым объектам, не хранящий в себе ничего, кроме ссылок.

Будут ли сложности при поддержке такого кода?
Лично для меня - это хорошее решение, все изменения других классов никак не повлияют на API, и никаких изменений в него писать не надо. Например, если мы изменим MSSQL на MySQL - максимум, это в методе initDB указать другой класс работы в бд, при этом будет полная совместимость всего кода, работающего через API.DB (есть четкое описание API-методов для всех классов: user, db, cache, route... и они обязаны ему соответствовать).

Так вот, плохо это, или хорошо?
Лично я описание анти-паттерна понял очень буквально: "в одном объекте хранится вообще все и все методы", в нашем же случае - это не так.
Является ли вышеописанная реализация антипаттерном?

Спасибо!

Автор: Фридрих 26.1.2013, 04:45
Очень хороший подход! Об этом я говорю на своей страничке "http://reforma-os.webnode.ru/".....
Сама по себе монолитность - это консерватизм, что не дает быстро развиваться новым идеям, потому что надо будет переписывать весь код,
а это не малые затраты.... Я ищу людей заинтересовваных в развиитии проекта, который у меня есть, начинать можно с малого,
заработать можно не плохо будет....

Автор: Cтpaнник 12.7.2013, 13:18
Описанная реализация не является антипаттерном, зато является паттерном. И именуется он Фасад (Facade).

Автор: BuShaRt 16.10.2013, 14:55
Думаю, что сам по себе API не должен инициализировать другие объекты внутри себя. Должна быть фабрика, которая будет инициализировать объекты окружения и инъектить их в этот объект. Т.е. объект как бы просто предоставляет мультиинтерфейс к другим интерфейсам, но не содержит информации о том, как инитить эти интерфейсы.

А вот юзать глоабальные переменные - вот это хреновая практика, попробуйте юзать паттерн сингильтон.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)