NordWest пишет:Суть такая.
В процессе копания в коде ExBB я неоднократно задавал себе вопрос а зачем в коде движка применяются классы?
Я так понимаю класс - это объект с набором свойств и методов. Оформлять что-то в виде класса имеет смысл только тогда, когда в процессе работы могут понадобиться как минимум несколько объектов этого класса. В нашем случае имеем класс FM. Но в процессе работы (если я правильно понимаю) мы создаем только один объект этого класса. Тогда нафига козе баян?
Я понимаю, что вероятно необходимость есть - просто я чего-то не учитываю. Буду признателен, если кто подскажет...
Вы серьёзно не знаете, для чего нужны классы? Попробуем разобраться.
Давайте подумаем: что такое программирование? Программирование - это производство. Я имею в виду реально большие проекты. В которых не так уж часто встречаются особо умные куски кода, зато функциональности много, она не обязательно логично устроена (особенно часто такое бывает, если вы конструируете интерфейс пользователя), и, что немаловажно, проект поддерживают обычные программисты.
Это значит, что большая часть времени жизни кода уйдёт на его поддержку, а не начальную разработку.
Начинающие программисты не любят доводить что-то до совершенства. Они напишут прототип в виде одной очень сложной функции, и все - задание выполнено. В функции есть тысяча хитростей и зависимостей, которые автору просто удержать в голове. Но завтра автор заболеет, уйдёт в запой или вообще отстранится от разработки - и внезапно код должны поддерживать другие программисты.
У программиста при виде сложных функций начинает болеть голова. Он не может держать в голове сразу много понятий и зависимостей! И тут внезапно на помощь приходят классы. Классы позволяют уменьшить сложность. Когда программист разрабатывает класс, он думает обо всём классе и держит в голове весь класс. Но когда он разрабатывает другие классы, он думает больше не в терминах "я вызову функцию X, и она установит переменную Y", а в терминах классов: "я беру возраст пользователя", "я рисую эту картинку". Теперь голова болит гораздо меньше: вместо того, чтобы думать о всех функциях в проекте одновременно, программист думает только о немногих публичных функциях немногих публичных интерфейсов. Таким образом, в его коде меньше зависимостей: он не должен думать (вернее должен не думать!) о конкретной реализации возраста пользователя или там отрисовки картинки, он может про это забыть. Его код становится проще, этот код легче понимать, тестировать и поддерживать.
Кроме того, он больше не должен думать что-то типа "я добавляю пользователя в список модераторов, для этого мне надо обновить вот этот массив, вот ту хэш-таблицу, поставить флаг для обновления базы данных и не забыть ещё увеличить счётчик версий". Он просто говорит: "таблица модераторов, добавь в себя вот этого пользователя!". То есть теперь можно думать не в терминах внутренних структур данных, а в терминах семантики: программист пишет прямо то, что он хочет выразить, несмотря на то, что в языке не было раньше конструкций для выражения его мыслей. Мы видим, что программист на самом деле расширяет язык под свою предметную область, и может легко и адекватно выражать своё намерение. Такой код не только легче писать, но и легче поддерживать.
При этом эффективность кода может падать по сравнению кодом, учитывающим особенности реализации других классов, но мы сознательно идём на эту жертву: наша цель - чтобы код стал проще, яснее, чтобы он говорил сам за себя!
Обратите внимание, что этот подход - развитие процедурного подхода: там складывали код в процедуры, чтобы абстрагироваться от кода одной процедуры во время разработки другой (и код, который опирается на конкретику реализации, обычно считается плохим - потому что он не уменьшает количество абстракций, которые нужно держать в голове). Так и при объектном-ориентированном подходе уменьшается, в свою очередь, количество функций, которые надо держать в голове.
Кроме того, ООП даёт другие преимущества в виде наследования и полиморфизма, которые по мне концептуально менее важны. Хотя и очень приятны в использовании.
Таким образом, для маленького проекта, для которого вы можете держать все функции в голове, можно отказаться от использования классов. Но для достаточного большого, серьёзного проекта без помощи классов для уменьшения сложности не обойтись.
Резюме: классы нужны, чтобы абстрагироваться от сложности разработки.
