Как перестать сомневаться в какую папочку положить класс и тп?

Question

[alex4answ]

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

Например, есть у меня DTO, Entity, они по сути дублируют друг друга, только Entity содержит/может содержать какую-то базовую логику, DTO - только логику записи/чтения.

Но они дублируют друг друга, что на первый взгляд не очень хорошо, но если вдуматься, то правильно.
И вот появляется задача, где нужно описать объект http.Response, можно ли использовать DTO или нужно использовать Entity, или нужно еще что-то, а в какие папочки это положить, а будет ли это правильно и тп.

В общем это порождает кучу вопросов, на которые не дать однозначные ответы, а хочется чтобы все было правильно, структурировано, чтобы соответствовать DRY и тд.

Как перестать долго думать и сомневаться над именами переменных, классов, функций, файлов, места расположения, архитектуры и тп ?

Comments

[Антон Р.]

Думать вообще полезно, а так, чтобы избежать дублирования делай наследование например.

[alex4answ]

Антон Р., но например вот пример с Entity и DTO, я не могу наследовать одно от другого, но они дублируют друг друга

[Антон Р.]

alex4answ, значит вынеси дублирующийся кусок в отдельный класс и импортируй где надо.

[Александр]

это норма, у тебя просто еще не достаточно опыта. Поработаешь, увидишь куда кладут файлы в продуктовых системах и все встанет на свои места. А о почитать можно о паттернах проектирования. Да посмотреть код других проектов не плохо было бы.

Answer 1

[Codebaker]

Вообще - думать и сомневаться - довольно полезно. Но.

Если это стало уже проблемой: задайте себе вопрос, а где мне это уже помогло? В предыдущем проекте? Как я там делал-то? Что и куда клал? Вызывает ли это боль сейчас? Если нет - переиспользуйте свой подход. Ок, кажется это решит проблему с вопросом что и куда класть.

Теперь с именами - назовите класс наиболее очевидно. Вот что сейчас в голову пришло? ResponseDTO? Ок, отличное начало. Назавтра поняли, что этот класс было бы лучше назвать ServerResponseDTO? Отлично! Есть такая фича: Refactoring, поддерживается почти всеми IDE, и уж точно поддерживается обыным переименованием - ну потратили вы на это пару минут, но стало же лучше? ОК, в следующем проекте подобные имена уже сами будут "всплывать", - это и будет ваш опыт.