"Монолитные" классы страниц - это запах кода?

Я новичок в PHP, и я пытаюсь создать сайт в первый раз, не используя фреймворк (nb, я ничего не имею против фреймворков, я просто думаю, что я должен научиться коду с нуля, прежде чем изучать фреймворк сверху Это похоже на изучение Javascript перед обучением JQuery).

Мне нравится OOP в концепции, поэтому я начал там. Я думаю, что улавливать все script определяет, какой тип страницы нужен, а затем передать (дезинфицированный) script вход в класс, который его обрабатывает, где класс является подклассом общего класса страниц, который включает в себя общие методы обработки таких вещей, как отправка HTTP-кодов и "виртуальный" метод отображения для фактического отображения страницы.

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

Кроме того, у меня есть небольшая проблема, которая убеждает меня в том, что существует необходимость в неличных методах внутри любой страницы или ее детей. Я думаю, что это побочный эффект в моем мышлении из-за того, что PHP является языком сценариев. Поскольку это a script, это неинтерактивные и входные данные определяются при запуске script (т.е. POST и GET vars). Похоже, что без внешних воздействий на страницу, кроме других объектов, где страница берет данные, а не предоставляет ее, нет необходимости в публичном методе, за исключением, очевидно, конструктора и метода generate, который я чувствую может просто вызываться из конструктора.

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

Так скажи мне: мой дизайн смешно вонючий? Как я могу реорганизовать это на что-то разумное?

3 ответа

Частные методы несколько сложнее для unit-test, а монолитные классы обычно являются индикатором отсутствия Разделение проблем в архитектуре. Классы должны иметь отличную ответственность. Группировка слишком большой ответственности в один класс часто создает объект Бога. Попробуйте следовать установленному design шаблонам до решить сложность в основе программного обеспечения.


Если вы не хотите использовать существующую инфраструктуру, это похвально; однако нет ничего плохого в использовании принципов, которые применяют. Я предлагаю реализовать свой собственный MVC. Это поможет вам не только понять язык, но и значительно упростит более позднее внедрение структуры.

Многие источники о том, как это сделать, существуют здесь один. И еще.

licensed under cc by-sa 3.0 with attribution.