Когда использовать частные методы?

Question

Я понимаю, что означает public/protected/private accessors на Java или PHP. Однако, когда вы решите, сделать ли метод приватным?

Представьте, что у меня есть класс, который обрабатывает строки конфигурации - они должны соответствовать определенному регулярному выражению, и если да, то выполняется дальнейшая логика, чтобы убедиться, что строки действительны.

В настоящее время этот код используется в частном методе в классе конфигурации. Этот класс принимает строки конфигурации, а затем возвращает значения в код клиента после проверки строк.

Однако я хочу, чтобы блок проверил код проверки, поэтому, возможно, он должен быть в другом классе. Обычно я этого не делаю, хотя знаю, что код будет повторно использован. Если он будет использоваться только одним классом, как в этом случае, я обычно просто делаю метод приватным.

Итак, мой вопрос: какие правила проектирования должны информировать программиста о том, что конкретный метод должен быть закрытым по сравнению с тем, чтобы быть перемещенным в его собственный класс?

Answer 1

Single Responsibility Principle - это то, что я обычно имею в виду. Также подумайте, действительно ли вам нужна проверка в этом классе или если она не имеет к этому никакого отношения (возможно, проверка не должна обрабатываться в логике домена, а на другом уровне над ней). Частные методы, как вы, вероятно, уже знаете, не должны тестироваться в модульных тестах, поэтому, если вам действительно нужно протестировать такую ​​функциональность, возможно, вы должны поместить ее в свой собственный класс проверки, ответственный только за проверку, а затем протестируйте его.

Answer 2

Тогда, если функция i используется только локально в объекте, и я не хочу показывать другим объектам ее, потому что я могу использовать ее в будущем и ошибаться, и это будет бесполезно в моем коде, я не должен думать много, чтобы подумать, какую функцию я должен использовать и что я не могу использовать.

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

Answer 3

Оставьте частные методы проверки в том же классе и сделайте единичный тестовый класс другом этого класса (в C++, по крайней мере, на Java, поместите модульный тест в тот же пакет).

Answer 4

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

Answer 5

Реализовать вам логику проверки как strategy как в strategy pattern. Таким образом, вы можете не только тестировать их отдельно, но и легко заменять логику проверки, если и когда это необходимо.

Так что сделайте отдельный класс Validator, который реализует интерфейс IValidator. Затем составите ваш класс Configuration с соответствующим валидатором на , введя в качестве зависимости в конструкторе конфигурации.

Answer 6

Подробнее о SOLID принципы проектирования SOLID