Привет, сегодня разговор пойдет об общих принципах проектирования, общих принципах дизайна. Я расскажу о некоторых параметрах, которые стоят учитывать при выполнении качественного планирования, дизайна и так далее.
Про декомпозицию
Начнём с того, что любой дизайн это в первую очередь декомпозиция. У нас есть какая-то задача мы её декомпозируем на куски такого размера, которые можно свободно переварить. Под свободно переварить, я имею ввиду, что мы можем поместить эту информацию себе в голову и оперировать ей достаточно свободно, не испытывая какого-то дискомфорта. Если мы вдруг понимаем, что нам постоянно не хватает мозгов понять, что происходит, то значит мы взяли слишком крупные куски, и их надо поделить. Мы должны есть слона по кусочкам, и не пытаться проглотить его целиком.
СОВЕТ 1 || Конфигурация приложения и объектов не должна выполняться по месту.
Принцип простой, у нас есть данные, которые конфигурируется из вне, они публичные, и они должны заходить либо через единый конфигуратор, через объект который всё конфигурирует, либо через параметры класса. Ничего не должно конфигурируваться по месту, то есть мы не должны прямо в коде класса описывать вещи, относящиеся к конфигурации.
СОВЕТ 2 || Избегайте ситуаций, когда есть несколько мест конфигурирования.
Не следование первому совету влечет за собой множественные точки конфигурирования, то есть, когда мы в какой-то момент захотим что-то переделать, нам придется ни в одном месте всё поправить а залести в каждый класс и там поправлять параметры. Это плохо, поэтому если эта часть относятся к конфигурации мы её выносим, если нет, то мы её закрываем в области видимости приватной или защищённой.
СОВЕТ 3 || Избегайте хаотичных решений, старайтесь придерживаться соглашений, принятых в проекте.
Нужно быть последовательным, когда мы приняли какие-то шаги по разработке и потом поняли, что они плохие. И походу начинаем их корректировать, это плохо, потому что в течение проекта мы можем несколько раз сменить идеи, и в итоге у нас будет часть проекта выполнена в одном стиле часть в другому, часть в третьем. Единолично такие решения не принимаются, они должны приниматься всей командой.
СОВЕТ 5 || Обратите внимание не только на штатные ситуации, но и на исключения.
Всегда нужно думать об исключениях, да мы пытаемся сделать абстракцию, мы всегда выделяем главное и пытаемся найти общие правила и их запрограммировать, но каждая ситуация, которая возникает в продакшене теоретически может привести к большой проблеме. То, к чему мы больше всего готовимся, то, чего мы больше всего ожидаем как, правило не происходит. Чем больше мы подумаем об исключениях, тем стабильнее мы напишем в конечном итоге программу и, тем лучше будет мнение нашего заказчика о нас.
СОВЕТ 6 || Здравый смысл превыше соглашений
У нас должна быть структура, которая оптимально соответствует нашим требованиям, но при этом мы не должны ставить наши соглашения выше здравого смысла. Если мы видим, что, то что мы делаем это откровенная ошибка, то опять же путем обсуждения нужно внести исправления, и не делать заведомо глупого шага только потому, что это где-то в соглашениях у нас это прописано. Это часто относятся к декомпозиции, к принципу единственности, ответственности, и так далее.
СОВЕТ 7 || Здесь чётко по "Чистому коду" - полиморфизм лучше ветвления.
Очень часто у нас любят заниматься ветвлениями Switch, If, вместо того, чтобы сделать полиморфные сущности. Полиморфизм всегда однозначно лучше ветвление. Если вы хотите о чём-то подумать до написания программы как раз подумайте о полиморфном поведении ваших классов и методов.
Естественно, тему я не исчерпал, если вы считаете, что чего-то не хватает, буду рад если вы это напишите в комментариях. А у меня на этом всё, спасибо, что читали эту статью.