Запах кода вызывать публичный метод в приватном методе того же экземпляра объекта?
Запах кода вызывать публичный метод в приватном методе того же экземпляра объекта?
Ответы:
Нет не плохого запаха. Это может быть необходимо, почему вы подозреваете, что это неправильно? Метод на атомарном уровне - это независимая сущность, которая выполняет задачу. Пока он выполняет задачу, любой, кто имеет к ней доступ, может вызывать ее, чтобы выполнить задачу.
Код пахнет? Да, не очень плохой, но хороший показатель того, что у класса может быть слишком много обязанностей.
Воспринимайте это как признак того, что класс, возможно, должен быть разбит на разные объекты, частные методы на самом деле не должны вызывать открытые методы одного и того же объекта, безусловно, в чистом ОО-дизайне.
Конечно, после того, как вы проверили класс и стали ясны причины вызова метода, это может быть вполне разумным вариантом, в общем случае можно ожидать, что служебные методы для класса будут частными, но если один из них достаточно полезен для быть публичным и использоваться другими методами, я, как правило, ожидаю, что эти методы также будут публичными.
Как и для всех запахов кода, это мотивация для дальнейшей проверки кода, рационализации и, возможно, рефакторинга, но не повод для тревоги.
Это может привести к неприятным сюрпризам, если кто-то, кто не прочитал исходный код этого класса, попытается создать его подкласс и переопределить открытый метод. Является ли это реальной проблемой, очевидно, зависит от вашей ситуации. Может быть, вам стоит подумать о том, чтобы сделать публичный метод или даже финал класса.
Нет. Что еще нужно сделать в этом случае? Сделать приватный метод общедоступным или публичный метод частным? Скопировать и вставить код из открытого метода в приватный?
Нет , здесь нет неприятного запаха.
если мы реализуем интерфейс очереди со списком, то не плохо ли просто вызывать нужные функции списка, чтобы легко добиться реализации очереди?
если у вас есть что-то, и вы хотите преобразовать это во что-то другое (например, обертку), то это не плохой запах, его возможность повторного использования кода с шаблоном дизайна действует на функциональном уровне (является ли функция объектом?)
Я знаю, что это старый пост, но я спорю об этом на работе. Я «действительно» считаю это запахом кода и не могу понять, почему вы захотите это сделать. Если закрытый метод должен вызывать открытый метод, то содержимое открытого метода должно быть взято и помещено в закрытый метод, который затем могут вызвать оба метода. Зачем?
Открытый метод может содержать тесты, которые не нужны, когда вы выполняете код внутри. Возможно, он получит UserObj и захочет проверить пользовательские разрешения, например.
После публичного вызова у вас может возникнуть требование заблокировать объект, если вы используете многопоточность, поэтому внутренне вы не захотите вызывать открытый метод.
Более вероятно, чтобы ввести круговые ошибки и бесконечные циклы и исключения из памяти, на мой взгляд.
Просто и просто, плохой дизайн и "ленивый". Публичные методы обеспечивают доступ к внешнему миру. Там нет причин выходить на улицу, когда вы уже внутри.
Представь себе обратное. Вы находитесь в приватном методе, и вам нужна функциональность в публичном методе. Что если вы не можете вызвать этот публичный метод из частного. Чтобы ты делал?
Ответ очевиден: если вам нужна функциональность открытого метода, вы должны иметь возможность вызывать этот метод из методов этого класса или из других классов.
В моем коде я часто создаю ленивые загрузчики загрузки, то есть объект инициализируется при первом запросе, а затем повторно использует тот же экземпляр объекта. Однако объект, созданный с использованием отложенной загрузки, подразумевает, что он не обязательно может быть создан в любой заданной точке. Вместо того, чтобы оборачиваться вокруг последовательности вызовов, чтобы я знал, что этот объект уже создан или повторяет тот же код отложенной загрузки внутри другого метода, я просто вызываю отложенный загрузчик всякий раз, когда мне нужен этот объект.
Точно так же, как вы можете использовать публичные методы разумно, вы также можете использовать их неправильно. Примером этого может быть открытый метод, который обрабатывает свои параметры перед вызовом другого частного метода. Было бы ошибкой вызывать этот публичный метод случайно просто потому, что у вас одинаковые параметры. Ошибка тонкая, но это ошибка проектирования больше, чем что-либо еще, и она требует, чтобы вы научились управлять параметрами внутреннего метода, а не параметрами открытого метода.
Поэтому, чтобы ответить на ваш вопрос, это, конечно, неплохой код, если вы используете его правильно.
Вопрос, который вам нужно задать себе: почему у вашего класса такие же потребности, как и у клиентов вашего класса? Обычно у класса очень разные потребности от своих клиентов. Так что да, это признак того, что у вас есть
(а) публично раскрыть что-то, что должно быть частным; или
(б) поведение класса недостаточно узкое (подумайте о принципе единой ответственности).