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

Question

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

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

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

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

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

Answer 1

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

Например, вы определяете класс Car.class с другим режимом управления.Car (.class) имеет член maxSpeed, который устанавливается установщиком: Car.maxSpeedSet (int mode).тогда пользователь не может напрямую узнать или изменить значение для maxSpeed, кроме как путем изменения его режима с помощью метода.

Таким образом, пользователям не нужно заботиться или писать функцию о том, как maxSpeed ​​получается изРежим.И когда вам нужно изменить функцию: maxSpeed ​​= f (mode), вам не нужно менять ее везде, где используется автомобиль.вы просто измените метод maxSpeedSett ().идеально подходит для инкапсуляции и обслуживания, не так ли?

если член только: x = a, 'public' кажется достаточно хорошим, но убедитесь, что вы не измените метод назначения в будущем, особенно когдаслишком много зависимости от класса.

Answer 6

Узнайте больше о принципах дизайна SOLID SOLID

Answer 7

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