Модераторы: Се ля ви
  

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> Божественный объект, Является ли конкретная реализация ан-пат 
:(
    Опции темы
 
Стоит ли так делать?
Так делать можно [ 6 ]  [50.00%]
Нужно искать другое решение [ 5 ]  [41.67%]
Автор идиот [ 1 ]  [8.33%]
Всего проголосовавших: 12
В этом опросе возможен один вариант ответа
Гости не могут голосовать 
Smorodin
Дата 24.10.2012, 10:33 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Добрейший
**


Профиль
Группа: Участник
Сообщений: 285
Регистрация: 10.4.2006
Где: Пермь

Репутация: нет
Всего: 1



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

Цитата

В объектно-ориентированном программировании божественный объект (англ. 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... и они обязаны ему соответствовать).

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

Спасибо!


--------------------
Сделать можно все, только вопрос - когда?
PM MAIL Skype   Вверх
Фридрих
Дата 26.1.2013, 04:45 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 4
Регистрация: 26.1.2013

Репутация: нет
Всего: нет



Очень хороший подход! Об этом я говорю на своей страничке "http://reforma-os.webnode.ru/".....
Сама по себе монолитность - это консерватизм, что не дает быстро развиваться новым идеям, потому что надо будет переписывать весь код,
а это не малые затраты.... Я ищу людей заинтересовваных в развиитии проекта, который у меня есть, начинать можно с малого,
заработать можно не плохо будет....
PM MAIL   Вверх
Cтpaнник
Дата 12.7.2013, 13:18 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 53
Регистрация: 12.10.2008
Где: Россия, Санкт-Пет ербург

Репутация: нет
Всего: нет



Описанная реализация не является антипаттерном, зато является паттерном. И именуется он Фасад (Facade).
PM MAIL   Вверх
BuShaRt
Дата 16.10.2013, 14:55 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1391
Регистрация: 29.6.2006

Репутация: нет
Всего: 6



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

А вот юзать глоабальные переменные - вот это хреновая практика, попробуйте юзать паттерн сингильтон.
PM MAIL ICQ   Вверх
Google
  Дата 23.5.2019, 19:48 (ссылка)  





  Вверх
  
Ответ в темуСоздание новой темы Создание опроса
Правила форума "Системный анализ, проектирование и UML"
Се ля ви

Форум "Системный анализ, проектирование и UML" предназначен для обсуждения вопросов, так или иначе связанных с этапами жизненного цикла автоматизированных (программных, информационных, автоматических) систем:

• предпроектные обследования объектов автоматизации;

• разработка концепции создания систем;

• моделирование бизнес-процессов (в т.ч. на UML);

• проектирование архитектуры систем;

• управление проектами;

• управление качеством;

• CASE-средства;

• реинжиниринг.


Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, Се ля ви.

 
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | Системный анализ, проектирование и UML | Следующая тема »


 




[ Время генерации скрипта: 0.1310 ]   [ Использовано запросов: 23 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.