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

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

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


java decomposition
person kontrarian    schedule 16.08.2010    source источник
comment
Спасибо всем за отличный ответ. Очень признателен   -  person kontrarian    schedule 18.08.2010

Ответы (5)


arrow_upward
10
arrow_downward

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

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

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

  • Легче повторно использовать
  • Легче тестировать
  • Легче читать и понимать
  • Легче отлаживать

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

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

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

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

person Benjamin Wootton    schedule 16.08.2010
comment
это зависит. Удобочитаемости не способствует слишком много (или, скорее, слишком мало) методов. Метод может стать настолько маленьким, что ничего не скажет вам о программе, которую вы пытаетесь понять. Но в пределах разумного, вы правы, короткие методы предпочтительнее. - person jalf; 16.08.2010

arrow_upward
13
arrow_downward

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

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

person jalf    schedule 16.08.2010

arrow_upward
4
arrow_downward

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

person hhbarriuso    schedule 16.08.2010

arrow_upward
2
arrow_downward

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

person Noel M    schedule 16.08.2010

arrow_upward
2
arrow_downward

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

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

Всегда есть исключения. Нет никакого ПРАВИЛЬНОГО пути. Ваша работа будет улучшаться с опытом.

person Andrew    schedule 16.08.2010