Должен ли я разрабатывать свое программное обеспечение в соответствии с парадигмой или в соответствии с инструментами, предоставляемыми языком?

Question

Поясню вопрос на примере: В Zend Framework, когда вы хотите добавить функциональность в класс представления, вы можете использовать так называемый класс Helper.
Вспомогательный класс - это класс, который имеет один метод (такой же, как имя класса), который становится доступным в каждом из представлений (по отражению вспомогательный метод переносится методом представления)
Это очень организовано и чисто, НО, это означает дополнительное включение для каждого такого помощника и некоторые игры с отражением. Обе вещи берут свое терпение на производительность.

Я думал, что вместо разработки помощника для метода, который я хочу добавить к представлению (каждый в отдельном файле), я напишу один помощник со списком функций стиля C (т.е. не статические методы класса, реальные функции) который может использоваться только в классе View (поскольку помощники View включены только в View).

Итак, это смешение некоторых процедурных процедур с ОО, но выигрыш в производительности очевиден, и в любом случае, помощники - это одиночные методы, которым обычно не требуется поддерживать состояние ...

Кто-то скажет: «Так что продолжайте с процедурной, это лучше в плане производительности», Нет, я очень хорошо осведомлен о преимуществах ОО, за исключением этого небольшого вопроса,
Итак, я должен придерживаться одной парадигмы или смешивать их?

Answer 1

Единственный способ ответить на ваш вопрос - дать плюсы и минусы для каждого дизайнерского решения.

Обычно для процедурного проектирования лучше всего, когда требуется минимальное участие в управлении состоянием, для обработки без сохранения состояния, преобразования данных в один прием. Примерами процедурной обработки могут быть: все виды математических функций, преобразования строк, преобразования массивов, прямой доступ к памяти и т. П.

Хотя ООП отлично подходит для контроля состояния. Замечательно использовать ООП для таких вещей, как элементы пользовательского интерфейса (миллионы примеров из учебников), программирование сокетов (открыто, прослушивание, закрыто, другие состояния), реализации протоколов также выигрывают. Все, что включает в себя несколько экземпляров и конечные автоматы , прекрасно реализуется.

В таком случае обычной практикой является смешивание одноразовых функций для простой обработки со сложными элементами управления состоянием в классах. Методы в классах будут использовать функции для внутренней обработки данных.

Взлом чего-либо вместе может сработать для кратковременного непроизводственного кода. Но после нескольких обновлений вы можете в конечном итоге искать соус для спагетти для вашего кода. Всегда хорошо иметь преднамеренный дизайн для кода, в отличие от специального кодирования.

Другим аспектом является распространенная практика в рамках . Если в Zend Framework является обычной практикой иметь смешанные реализации (ООП и функционал для простых преобразований), нет особых причин не делать этого. Если это не так, лучше придерживайтесь одного подхода, иначе вы столкнетесь с проблемами сопровождения, и другие люди будут тратить часы и дни на понимание вашего кода.

Также необходимо изучить каждый бит технических ограничений делать то, что вы делаете:

• Если используется компилятор (в отличие от интерпретатора) и компоновка, убедитесь, что там нет проблем
• Если ваш код разбит на модули (библиотеки), обязательно убедитесь, что смешивание не нарушит совместимость
• Если есть проблемы с производительностью, определите их количество; как только вы это сделаете, решение может стать проще
• Проведите множество тестовых приложений, чтобы проверить свой выбор - неожиданные сбои, медленный запуск / остановка, повреждение данных, перепрыгивание через обручи для достижения цели - все указывает на то, что выбор не является оптимальным. Знание почему так же важно, как и знание что .

Answer 2

first: OOP - это подмножество структурированного программирования, которое является подмножеством процедурного, так что вы не идете настолько далеко от парадигмы, как вы предполагаете. («парадигма», какое уродливое и злоупотребленное слово)

секунда: ООП, это стиль дизайна, а не языковая функция. использование функций вместо методов не делает вашу программу менее ООП, если вы поддерживаете (концептуальные) инкапсуляции.

третье: даже самый большой ООП-код в PHP должен использовать встроенные функции на каком-то уровне. поэтому, почти по определению, использование функций не может быть «анти-ООП».

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

Answer 3

Вы должны проектировать в соответствии с вашими нефункциональными требованиями. Например, если пропускная способность является вашей целью, вы должны пойти по пути производительности. Но если ваша цель заключается в поддержке, возможно, вы должны сделать свой код более читабельным, чем помещать весь нечитаемый код, оптимизированный для производительности.

Рамки оставляют вам пространство для решения вещей. ООП само по себе это просто концепция. Так что не грех использовать функции в стиле C в ОО-программе, ИМХО. Если это уместно, тогда дерзайте.