Разложение в Java, когда достаточно?

Question

Я студент первого курса информатики.В настоящее время мы программируем на Java, и я часто пытаюсь разложить мою программу на методы с именами, чтобы моя логика основного метода могла читать как можно ближе к псевдокоду.

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

Answer 1

Основное правило - Принцип единой ответственности .Каждая единица кода должна отвечать за ровно одну вещь.Это относится как к методам, так и к классам.Если вы можете указать простое и краткое имя для каждого из ваших многочисленных частных методов для , тогда это нормально.Если вы можете только описать это как «часть» более крупной операции, то, вероятно, это не должен быть отдельный метод.

Но, исходя из вашего вопроса, похоже, вы уже делаете это правильно.*

Answer 2

Большинство новых разработчиков идут другим путем - огромные функции, которые имеют много обязанностей.Ваша ситуация бесконечно предпочтительна для этого!

Существует очень мало недостатков в создании большого количества маленьких методов и много преимуществ!

Короткие методы:

• Прощедля повторного использования
• Легче для проверки
• Легче для чтения и понимания
• Легче для отладки

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

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

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

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

Answer 3

Я думаю, что наиболее важной частью взлома кода является Принцип единой ответственности (SRP) .Каждый объект должен иметь одну ответственность, и эта ответственность должна быть полностью заключена в класс

Answer 4

Мое общее правило заключается в том, что если функция не помещается на одном экране (например, старый терминал с 24 строками на 80 столбцов), то для этого должна быть веская причина. Иногда есть. Вы должны иметь в виду, что, в общем, любой, кто читает вашу функцию, должен понимать все это. Когда это долго, это труднее сделать.

Как говорится, две или три строковые функции мало что добавляют. Они часто СЛИШКОМ просты для понимания сами по себе, и имя, которое вы им дадите, не будет содержать столько информации, сколько сам код, когда встроен в более длинную функцию.

Всегда есть исключения. Там нет никакого правильного пути. Ваша работа улучшится с опытом.

Answer 5

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