Я полностью согласен с
BoShurik - это действительно признак плохой архитектуры. Такой подход может быть оправдан в каком-то конкретном наборе классов, но он явно излишний в общем случае.
Представьте что вы будете использовать какой-либо framework или внешнюю библиотеку - там не будет этих методов. Представьте что какой-то из ваших классов не требует подобного функционала - тогда наличие этих методов будет нарушением
принципа SOLID.
В целом подобный функционал обычно необходим только для классов используемых для хранения данных (value objects, entities, кастомные струкруры и т.п.). Для них можно создавать подобные базовые классы (хотя для entities, например в Doctrine, принято использовать getters / setters) либо же использовать traits. Для классов же отвечающих за логику приложения этот функционал просто не нужен.
Подобный функционал также несколько сложнее чем кажется на первый взгляд. Например что вы будете делать в случае если вам потребуется сохранить не скалярное значение, а массив значений или, ещё лучше, массив объектов определённого типа? Как вы планируете реализовать обеспечение валидации данных при использовании подобных методов? Как планируете работать с библиотеками, опирающимися на метаданные (те же аннотации в Doctrine и ещё куче библиотек)?
Также многие IDE (например PHPStorm) умеют генерировать getters / setters по описанию полей класса, это существенно экономит время на создание подобных классов. Кроме того они, при описании корректных PHPDocs позволяют писать намного более безопасный код беря на себя проверки совпадения типов и т.п.
Я в своё время писал
библиотечку для создания произвольных структур которая как раз реализовывала подобный функционал и, хотя она в целом получилась довольно удачной - практика показывает что у такого подхода есть масса ограничений.