В «Фактах и заблуждениях разработки программного обеспечения» Роберт Л. Гласс говорит:
Факт 15. Повторное использование в малом является хорошо решенной проблемой.
Факт 16. Повторное использование в целом остается в основном нерешенной проблемой.
Факт 17. Повторное использование в целом лучше всего работает в семействах связанных систем.
Другими словами, вы можете повторно использовать модули, но только между приложениями, которые работают очень похоже. Попытка сделать модули настолько универсальными, чтобы вы могли повторно использовать их в любом приложении, слишком сложна. В итоге вы создаете модули, которые настолько настраиваемы, что они слишком сложны в использовании и содержат много кода для обработки сценариев, которые бесполезны для данного приложения.
Было бы лучше написать собственный модуль для каждого приложения, который выполняет только то, что нужно каждому приложению, и не более того. Это особенно важно для такого языка, как PHP, где код загружается при каждом запросе, поэтому объем кода оказывает значительное влияние на производительность.
Повторное использование более детальной функциональности отличается. Использование, скажем, ведения журналов, между приложениями достаточно схоже, независимо от того, насколько приложения отличаются друг от друга. Вот почему большинство фреймворков действительно хорошо работают с классами стилей обслуживания общего назначения.
Комментарий от @A_Var:
Вы можете сделать класс многоразовым, если заранее знаете диапазон возможных функций и, следовательно, те части, которые должны быть расширяемыми. Это относительно просто для простого класса, который одинаково используется в каждом приложении. Я упомянул пример регистрации. Это то, что Glass называет многократным использованием .
Но мы не говорим о простых классах. Если вы попытаетесь сделать то же самое со сложным модулем (например, несколько классов для обработки нескольких экранов, форм, разных схем баз данных и т. Д.), Слишком сложно написать код, который будет достаточно универсальным, чтобы покрыть все конкретные потребности каждое приложение. В итоге вам потребуется больше кода в универсальном модуле, чем общая сумма кода, необходимого для написания отдельных модулей для каждого приложения.
Кроме того, тестирование становится очень дорогостоящим, потому что любое изменение, которое вы вносите в базовый модуль, требует повторного тестирования всех приложений, которые его используют и расширяют.
В конце концов, создание нового модуля для каждого приложения занимает меньше времени, и вы можете добиться максимальной эффективности, используя повторно используемые компоненты, которые более детализированы.