Олег уже по сути изложил эту мысль, но я ее перефразирую. Суть DRY, как мне кажется, не в том чтобы бороться с дублирующимся
кодом, а в том, чтобы бороться с дублирующимися
концепциями. Объясню: какой-то кусок
кода в двух местах проекта может быть схожим - появляется искушение вынести его в одну функцию или класс, однако
концепции (дальнейшие планы) на эти куски кода могут быть совершенно разными, и в будущем, по мере детализации первоначальной бизнес идеи, эти два куска кода станут совершенно не похожими друг на друга.
В данном случае: если у фирмы, магазина и категории продуктов изначально разный набор параметров, и в будущем есть опасения, что этот набор будет еще более различным, то не стоит эти параметры объединять в какой-то общий класс. Это можно было бы сделать, если, например, стояло бизнес-требования (
концепция) реализовать унифицированный набор параметров для всех сущностей. В таком случае да - не стоило бы одну
концепцию расчленять на разные части кодовой базы.
Если подытожить: не стоит бояться дублирующегося кода - стоит бояться дублирующихся концепций. В конечном счете не очень существенно сделать код короче убирая дублирующиеся куски - с эти справятся компиляторы или минимизаторы, которые кажется иногда обобщают дублирующийся
код для оптимизации и в дальнейшем сводят весь огромный проект к одной длинной строке или бинарнику. С точки зрения архитектора по настоящему важно сделать код понятным и удобным для доработок. Это одна из основных целей программиста, имхо.
