Вопрос по break, oop, continue, c#, java – Почему плохой практикой является использование меток прерывания / продолжения в ООП (например, Java, C #)? [закрыто]

7

Мне сказали, что использование меток break и continue на языке ООП не является стилем программирования ООП. Можете ли вы подробно объяснить, почему и в чем проблема?

Уловка была с этим словом лейбла. Я имел в виду помеченный перерыв / продолжение.

class BreakWithLabelDemo {
    public static void main(String[] args) {

        int[][] arrayOfInts = {
            { 32, 87, 3, 589 },
            { 12, 1076, 2000, 8 },
            { 622, 127, 77, 955 }
        };
        int searchfor = 12;

        int i;
        int j = 0;
        boolean foundIt = false;

    search:
        for (i = 0; i < arrayOfInts.length; i++) {
            for (j = 0; j < arrayOfInts[i].length;
                 j++) {
                if (arrayOfInts[i][j] == searchfor) {
                    foundIt = true;
                    break search;
                }
            }
        }

        if (foundIt) {
            System.out.println("Found " + searchfor +
                               " at " + i + ", " + j);
        } else {
            System.out.println(searchfor +
                               " not in the array");
        }
    }
}

http://docs.oracle.com/javase/tutorial/java/nutsandbolts/branch.html

Было ли это в контексте какого-то конкретного блока кода или общего комментария?One who faced the same V4Vendetta
Не доверяй всему, что слышишь. crypted
@ Int3 & # x1F70 ;: Я подробно остановлюсь на вашем утверждении и скажу, что вы должны скептически относиться кeverything, Но будьте осторожны: это заставляет вас думать обо всем и обнаруживать огромное количество логических ошибок в человеке в целом. Быть скептиком - это красная пилюля жизни. Sebastian Mach
потому что велоцираптор придет и съест тебя Denis Tulskiy

Ваш Ответ

5   ответов
16

functional стиль программирования. В ООП нет ничего, что подсказывало быbreak, continue или дажеgoto в методе это плохая идея.

ИМХО использование break и continue не рекомендуется на языках ООП, поскольку они могут привести к сложности и путанице. Поскольку ярлыки используются редко, они могут запутать еще больше. Я бы сказал, что вы все равно должны их использовать, когда чувствуете, что это самое простое решение проблемы.

// confusing use of LABEL
http://www.google.com/
do {
    if (condition) continue http;
} while(condition2)

другое запутанное использование

GOTO: {
    // code
    if (condition)
         break GOTO; // without a loop
    // code
}

Хорошее использование этикетки

OUTER: 
for(outer loop) {
   for(inner loop)
      if (condition)
         continue or break OUTER;
}

Странное использование метки

FOUND: {
   for(loop)
      if(found)
          break FOUND;

   // not found
   handle not found
}
Хорошая точка зрения. Я думал об этом, должен был упомянуть это.
Я не согласен с goto, если goto позволяет переходить куда-либо в коде, это больше не ООП. Если goto ограничен текущим методом, тогда хорошо.
24

который сказал вам, что, вероятно, будет означать, что break и continue являются ветвящимися утверждениями типа goto, которые являются одним из механизмов императивного программирования.

Разрыв / продолжение позволяет вам только перейти к внешнему выражению, что означает, что вы не можете использовать код в любом месте. Таким образом, вы остаетесь в том же объекте метода, так что он не является несовместимым с ООП.

В любом случае, говорить, что перерыв и продолжение не являются ООП, - это бессмысленно. Мы можем обсудить их влияние на удобочитаемость, но это еще не все.

2

«Важно помнить, что единственная причина использовать метки в Java - это когда у вас есть вложенные циклы, и вы хотите разорвать или продолжить более одного вложенного уровня».

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

2

вероятно, не имеет никакого отношения к ООП. Он основан на том факте, что эти утверждения похожи на печально известный GOTO, который может сделать код полностью нечитаемым. Однако догмы - это плохие советы. Основной парадигмой должна быть читаемость кода. Выпрыгнуть из цикла в первой строке, используя break или continue, может быть намного понятнее, чем поместить все остальное в условие if.

Именно это моя точка зрения. Прямо сейчас мой цикл с оператором continue читается, но наш линтер жалуется. Вздох ..., сломайся, продолжай - это не что иное, как GOTO, и это необходимо во многих случаях.
-4

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

Но также могут быть некоторые проблемы с производительностью (не связанные с ООП): ЦП использует предикторы для загрузки инструкции в очередь перед обработкой этой инструкции. Предсказателю легко определить, какие инструкции следует загружать для условного перехода, а для безусловного будет сложнее.

Я думаю, что ОП перепутал его заявление с оптимизацией компилятора. Из завершенного кода: безусловный переход усложняет анализ потока и снижает способность компилятора оптимизировать код.
Вы говорите, что предикторы ветвей ЦП не могут обрабатывать безусловные переходы? Прошло довольно много лет с тех пор, как я имел дело с аппаратным обеспечением на этом уровне, но в то время безусловный скачок считалсяtrivial случай & # x2026;

Похожие вопросы