Публичные статические методы - плохой знак?

Question

Я только что прочитал эту статью здесь: http://hamletdarcy.blogspot.com/2008/04/10-best-idea-inspections-youre-not.html,, и последний бит, в частности, заставил меня задуматься о моем коде, в частности, совет:

Что в мире являетсяпубличный метод делает на вашем объекте, который не зависит от каких-либо полей в объекте?Это, конечно, запах кода.Проблема в том, что «авто-исправление» для проверки заключается в применении статического ключевого слова.Нееет.Это не то, что вы хотите сделать.Публичный метод без какой-либо зависимости от состояния объекта не может быть частью объекта, который имеет однозначно заданный устав.Это просто не связно и должно быть размещено где-то еще.Итак: если метод является закрытым, примите автоматическое исправление, но если метод является общедоступным, не делайте этого.

Код, по сути, является преобразователем объекта.Он берет объект типа A и преобразует его в другой тип.

Моя иерархия выглядит следующим образом:

Интерфейс ObjectTransformer -> GenericObjectTransformer

, а затем ниже этого, GenericObjectTransformerрасширяется ObjectTransformerA и ObjectTransformerB

Теперь некоторые функции требуются как ObjectTransformerA, так и ObjectTransformerB, но на самом деле не зависят ни от каких переменных экземпляра GenericObjectTransformer, поэтому это защищенный статический метод в GenericObjectTransformer.

Это нарушение вышеуказанного правила?Очевидно, что это защищенный, а не общедоступный, но все же это метод, доступный извне класса, который не имеет ничего общего с самим классом?

Есть мысли?

Answer 1

Я не согласен с выдержкой, которую вы вытащили.

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

Только потому, что метод статический и не имеет отношения к состоянию, неозначает, что он подпадает под категорию «низкая сплоченность».Сплоченность / функциональность не зависит от состояния.

Когда вы пытаетесь определить связность, подумайте о роли класса в целом, а не только переменных экземпляра.Если логика, на которую вы смотрите, связана с общей концепцией (GenericObjectTransformer), то оставьте ее там.

Если это обычная процедура для вычисления орбиты Луны или глубины океана, переведите ее в полезный класс (еще одна вонючая область нашего поля).

Answer 2

Это кажется немного нечистым, но кажется предпочтительнее тех альтернатив, которые я могу придумать.

Я думаю, что оригинал

Открытый метод без какой-либо зависимости на состоянии объекта не может быть частью объекта, который имеет однозначно заявленный устав.

Ваша ссылка слишком черно-белая, а ваша ситуация еще более серая.

Имея защищенный метод, вы прекрасно документируете, что он предназначен для использования производными классами. Если вы не поместите его в базовый класс, то, вероятно, он должен перейти в некоторый класс ObjectTransformUtility. Это победа? Больше артефактов, больше мест для поиска.

Одна мысль: если ваш класс ObjectTransormer претерпевает значительные изменения, то насколько вероятно, что вам потребуется изменить эти служебные методы. В конце концов, если их задача - работать с интерфейсом объекта, то на самом деле их сплоченность достаточно высока.