Частные вспомогательные методы и общедоступные методы статической утилиты в Java

Ответ 1

"Неправильное" мышление здесь.

Вы не переделываете свои классы, потому что инструменты жалуются на то или иное.

Вы хотите улучшить качество вашего исходного кода; и такие инструменты могут помочь определить "темы, о которых стоит подумать". Вы принимаете их отзывы как подсказку; не как "порядок".

Поэтому вы не беспокоитесь о "строках кодов" внутри класса. Вместо этого вы беспокоитесь о обязанностях, которые имеет этот класс. Значение: количество номеров строк само по себе не является проблемой, но нарушения принципа единой ответственности.

Таким образом: вы отступаете и проверяете, что именно делает ваш класс. И когда это явно делает больше, чем одно, вы извлекаете такие аспекты в другие классы!

Значение: если вы действительно обнаружите, что весь этот код "принадлежит" к ответственности этого класса; затем держите его там. Не начинайте вводить внутренние детали реализации в несвязанные вспомогательные классы; просто потому, что какой-то инструмент предупреждает вас о количестве строк.

С другой стороны, превращение частных методов во что-то, что статично/защищено пакетом, позволит вам использовать unit test эти методы. Это может быть преимуществом. Но, как сказано: до тех пор, пока мы говорим о деталях реализации, они должны оставаться закрытыми; и в любом случае они не должны быть проверены на единицу.

Код длинной истории: знайте и понимайте, что такое "чистый код"; и попытайтесь следовать изложенным там идеям.

Ответ 2

Разделение методов должно осуществляться по назначению/приложению/логике (вы называете это), а не по техническим свойствам.

Длинный исходный код, вероятно, можно разделить на несколько классов малого размера, каждый из которых имеет свою собственную цель/ответственность.

Ответ 3

Качество кода не может быть измерено количеством строк. Если вы обнаружите, что файл класса растет с каждым днем, убедитесь, что ваш класс следует принципу единой ответственности.

Если ваш класс не соответствует принципу, разделите его на отдельные классы и превратите классы в пакет.

Иначе вы можете сделать свой базовый класс абстрактным классом и сделать ваши методы использования abstract. Имейте дочерний класс, который расширяет базовый класс, обеспечивающий реализацию абстрактных методов в базовом классе.

Вот хороший ответ SO, когда вы можете сделать свои методы статическими

Как сказал @Zack Jannsen,

"статический" часто ценный, когда вы знаете, что что-то не изменится экземпляров. Если это так, я бы действительно подумал о "Single Принцип ответственности", который предполагает, что класс должен иметь один и, следовательно, только одна причина для изменения. Я чувствую, что нужно рассмотрите возможность перемещения функции "ConvertMpgToKpl (double mpg)" и аналогичные методы, к их собственному классу. Целью объекта автомобиля является позволяют создавать экземпляры автомобилей, а не сравнивать их. Они должны быть внешними по отношению к классу.

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

• Метод создает согласованный результат, основанный на входных аргументах
• Вам всегда нужно, чтобы этот метод был в памяти (т.е. вам нужен метод довольно часто). Лучше бы получить доступ к огромному методу, к которому можно было бы получить доступ всего лишь несколько раз с помощью создания объекта, а не для доступа через static
• Полезные методы, которые используются довольно часто, могут быть сделаны как static

Ответ 4

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

Кроме того, я полностью согласен с ответом GhostCat в плане общего мышления. Что касается размера класса - это может быть проблемой, но, как правило, я не беспокоюсь об этом. То, что я действительно ищу, - это размер ваших методов. Мне нравятся короткие и понятные методы, начиная с его имени и имен параметров, порядка и логики. Если есть большая часть внутренней логики - извлеките ее в отдельный метод. Это делает код гораздо более читабельным и поддерживаемым.