[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: ООП или ООП. Что выбрать?
twin
С основными пунктами подготовительных работ я вроде как закончил.

Теперь самое время выбрать методологию программирования. От этого в большой степени зависит разработка архитектуры. А это следующий пункт "меню" этап развития.

Так вот, что за странное название темы, спросите вы. Все просто.

Объектно Ориентированное Программирование почему то трактуется, как Объектно Обязательное. Даже в Википедия ссылается на определение гуру ООП Алана Кёртиса (который кстати мне в отцы годится). В этом определении первой красной строкой стоит:
Всё является объектом.
И дальше принципы взаимодействия:
чтобы место не тратить
Вычисления осуществляются путём взаимодействия (обмена данными) между объектами, при котором один объект требует, чтобы другой объект выполнил некоторое действие. Объекты взаимодействуют, посылая и получая сообщения. Сообщение — это запрос на выполнение действия, дополненный набором аргументов, которые могут понадобиться при выполнении действия.

Каждый объект имеет независимую память, которая состоит из других объектов.

Каждый объект является представителем класса, который выражает общие свойства объектов (таких, как целые числа или списки).

В классе задаётся поведение (функциональность) объекта. Тем самым все объекты, которые являются экземплярами одного класса, могут выполнять одни и те же действия.

Классы организованы в единую древовидную структуру с общим корнем, называемую иерархией наследования. Память и поведение, связанное с экземплярами определённого класса, автоматически доступны любому классу, расположенному ниже в иерархическом дереве.


Но это вобщем то нормально, ничего страшного нет. Страшнее другое. Что обязательным условием ООП сейчас считается использование общепринятых паттернов. Причем отступление от них объявляется ереcью, и допустивший сей грех предается анафеме.

Я много перелопатил информации и нашел массу интересного. У того же Фаулера есть такое наблюдение:
Цитата
Суть в том, что часто паттерны используются чересчур активно. Известна история о программисте, который, прочитав в первый раз книгу Банды Четырех, ухитрился использовать 16 паттернов в 32 строчках кода. Помню замечательный вечер, подогретый всего-навсего одним стаканчиком солода, когда мы с Кентом набрасывали статью под названием "Не паттерны проектирования: 23 дешевых трюка", где рассказали о таких вещах, как использование оператора "if" вместо паттерна "стратегия". В каждой шутке есть доля правды. Паттерны нередко используются там, где без них вполне можно было бы обойтись, однако это не делает хуже саму идею. Весь вопрос в том, как вы их используете.

К чему я клоню и с чего вдруг эта тема. В ветке обсуждения концепции Oyeme удивился, что в концептуальном описании есть такая строка:
Фреймворк дает свободу программисту, не создавая каких-либо структурных ограничений и конвенций
Цитата (Oyeme @ 5.10.2015 - 08:42)
Он и никогда и не ограничивал.
Если у человека нет в рамок и правил - Хаос и анархия

Декларативная строка на првый взгляд, риторическая. Мне тоже сначала так показалось. А потом я задумался. А ведь действительно, прав Фаулер. Паттерны уже возвели в ранг закона. И фреймворки сейчас тоже диктуют условия. ORM, DI, и прочая прочая.

Некоторые из них уже объявили антипаттернами. Теперь мало того, что нужно обязательно юзать "хорошие" паттеры, и ни в коем случае нельзя "плохие"

В той же ветке chee высказался, что анимичные модели, это зло.
Цитата (chee @ 5.10.2015 - 14:40)
Используя MVCS в таком понятии котором он трактуется тут, можно прийти к анимичным моделям, что существенно влияет на восприятие кода, в негатином плане конечно.

А этот шаблон оказывается достаточно популярен и имеет много приверженцев. Подробности плюсов расписывать сейчас не буду, не о том речь.

А речь о том, какую парадигму выбрать. Объектно Ориентированное или всё же Объектно Обязательное Программирование.

Разница в каноничности. Дело в том, что я хочу для организации разработки применить методологию XP, а адепты этой технологии мало ориентируются на популярные паттерны и не ставят цели ООП ради ООП. Кроме того, в сервис-ориентированной архитектуре многие паттерны или малопригодны, или не подходят совсем. Тот же DI контейнер на мой взгляд не очень вписывается в концепцию. На локальном уровне да, можно использовать всё. Упор на слово "можно", а не "обязательно".

Пока было мало времени досконально разобраться в вопросе. Может поделитесь мыслями, какими подводными камнями усеян этот путь? Ну кроме плевков адептов конечно в мою сторону в будущем. smile.gif

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.