| 1Bot |
Отправлено: 2 января 2014 — 18:30 
|
Super Member
Покинул форум
Сообщений всего: 773
Дата рег-ции: Апр. 2009
Откуда: Днепропетровск
Репутация: 69
|
NordWest пишет:Суть такая.
В процессе копания в коде ExBB я неоднократно задавал себе вопрос а зачем в коде движка применяются классы?
Я так понимаю класс - это объект с набором свойств и методов. Оформлять что-то в виде класса имеет смысл только тогда, когда в процессе работы могут понадобиться как минимум несколько объектов этого класса. В нашем случае имеем класс FM. Но в процессе работы (если я правильно понимаю) мы создаем только один объект этого класса. Тогда нафига козе баян?
Я понимаю, что вероятно необходимость есть - просто я чего-то не учитываю. Буду признателен, если кто подскажет... 
Вы серьёзно не знаете, для чего нужны классы? Попробуем разобраться.
Давайте подумаем: что такое программирование? Программирование - это производство. Я имею в виду реально большие проекты. В которых не так уж часто встречаются особо умные куски кода, зато функциональности много, она не обязательно логично устроена (особенно часто такое бывает, если вы конструируете интерфейс пользователя), и, что немаловажно, проект поддерживают обычные программисты.
Это значит, что большая часть времени жизни кода уйдёт на его поддержку, а не начальную разработку.
Начинающие программисты не любят доводить что-то до совершенства. Они напишут прототип в виде одной очень сложной функции, и все - задание выполнено. В функции есть тысяча хитростей и зависимостей, которые автору просто удержать в голове. Но завтра автор заболеет, уйдёт в запой или вообще отстранится от разработки - и внезапно код должны поддерживать другие программисты.
У программиста при виде сложных функций начинает болеть голова. Он не может держать в голове сразу много понятий и зависимостей! И тут внезапно на помощь приходят классы. Классы позволяют уменьшить сложность. Когда программист разрабатывает класс, он думает обо всём классе и держит в голове весь класс. Но когда он разрабатывает другие классы, он думает больше не в терминах "я вызову функцию X, и она установит переменную Y", а в терминах классов: "я беру возраст пользователя", "я рисую эту картинку". Теперь голова болит гораздо меньше: вместо того, чтобы думать о всех функциях в проекте одновременно, программист думает только о немногих публичных функциях немногих публичных интерфейсов. Таким образом, в его коде меньше зависимостей: он не должен думать (вернее должен не думать!) о конкретной реализации возраста пользователя или там отрисовки картинки, он может про это забыть. Его код становится проще, этот код легче понимать, тестировать и поддерживать.
Кроме того, он больше не должен думать что-то типа "я добавляю пользователя в список модераторов, для этого мне надо обновить вот этот массив, вот ту хэш-таблицу, поставить флаг для обновления базы данных и не забыть ещё увеличить счётчик версий". Он просто говорит: "таблица модераторов, добавь в себя вот этого пользователя!". То есть теперь можно думать не в терминах внутренних структур данных, а в терминах семантики: программист пишет прямо то, что он хочет выразить, несмотря на то, что в языке не было раньше конструкций для выражения его мыслей. Мы видим, что программист на самом деле расширяет язык под свою предметную область, и может легко и адекватно выражать своё намерение. Такой код не только легче писать, но и легче поддерживать.
При этом эффективность кода может падать по сравнению кодом, учитывающим особенности реализации других классов, но мы сознательно идём на эту жертву: наша цель - чтобы код стал проще, яснее, чтобы он говорил сам за себя!
Обратите внимание, что этот подход - развитие процедурного подхода: там складывали код в процедуры, чтобы абстрагироваться от кода одной процедуры во время разработки другой (и код, который опирается на конкретику реализации, обычно считается плохим - потому что он не уменьшает количество абстракций, которые нужно держать в голове). Так и при объектном-ориентированном подходе уменьшается, в свою очередь, количество функций, которые надо держать в голове.
Кроме того, ООП даёт другие преимущества в виде наследования и полиморфизма, которые по мне концептуально менее важны. Хотя и очень приятны в использовании.
Таким образом, для маленького проекта, для которого вы можете держать все функции в голове, можно отказаться от использования классов. Но для достаточного большого, серьёзного проекта без помощи классов для уменьшения сложности не обойтись.
Резюме: классы нужны, чтобы абстрагироваться от сложности разработки. |
| |
|
| EgorViktorovich |
Отправлено: 3 января 2014 — 01:00
|
Newbie
Покинул форум
Сообщений всего: 23
Дата рег-ции: Нояб. 2013
Репутация: 1
[+]
|
Цитата:Резюме: классы нужны, чтобы абстрагироваться от сложности разработки.
Каким образом в ехвв? Если бы использовались просто функции, то они имели бы те же названия  Для внутренних функций не нужно было бы вызывать классы через глобал. Все функции находились бы в одном файле lib, а класс (функции?) загрузки файлов вызывался бы напрямую, без предварительной обработки в fm (кстати, догадываюсь, что именно этот "замечательный" ход с fm и не позволил "разработчику" догадаться как сделать мультизагрузку, наипростейшую по исполнению).
Ну, разве что можно вставлять в файлы .tpl, применение которых весьма спорно, ланги в виде {$fm->LANG['.........']}. Наверное это круче, чем <?=$lang['.........']?>.
Обычный набор функций был переведён в классы. Дальше со скриптом ничего не делалось. Узнал "разработчик" про классы, вот и впендюрил их. Узнал про константы - получите в нагрузку. Нужны ли, нет ли...
Всё, что сделано в ехвв, сделано для того, чтобы усложнить жизнь разработчику, а не наоборот, увы. И "абстрагироваться" от этого прелестного кода никак не возможно. |
| |
|
|
Сайт проекта ExBB
Чат на форуме
Помощь
Поиск
BanList
ExBB Community » Веб-разработка » Вопросы и ответы » PHP/Perl
Описание: Спрашиваю, как человек далёкий от классических теорий ООП
