Quo vadis GOTO
Na ostatnim DevCrowd Sebastian Pietrowski poruszył kwestię związaną z być i nie być instrukcji GOTO.
Jak wiadomo w Javie zarezerwowano słowo goto, ale nie jest ono zaimplementowane. Kwestią sporną pozostaje czy ta instrukcja jest sensowna w języku obiektowym czy też nie. W zamian za nią pedrowaty wskazał, że nadal można używać instrukcji break i continue. Co więcej powiem wam, że można tych instrukcji używać w taki sam sposób jak używano słowa kluczowego goto.
Listing 1. użycie break jak goto
public class SimpleGoTo {
public static void main(String[] args) {
int i = 0;
int j = 0;
REPEAT: {
while (i 5) {
break REPEAT;
}
j++;
}
System.out.println(i + "///" + j);
}
}
}
Jak się pobawicie to dojdziecie do wniosku, że można używać namiastki goto w postaci break LABEL. To był przykład z pętlą teraz trochę bardziej mieszający w głowie, czyli break LABEL z ifem:
Listing 2. użycie break z if
public class SimpleGoTo {
public static void main(String[] args) {
int i = 0;
int j = 0;
REPEAT: {
MAGIC: {
while (i 5) {
break MAGIC;
}
j++;
}
}
if (i + j > 10){
break REPEAT;
}
System.out.println(i + "///" + j);
}
}
}
Zatem można stwierdzić, że dopóki pozostajemy w danym zakresie (bloku kodu ograniczonym { i }) to możemy używać namiastki goto. Do czego można tego użyć?
W swojej karierze spotkałem się tylko raz z użyciem takiej konstrukcji. Mianowicie w ten sposób można kontrolować przepływ sterowania w programie jeżeli migrujemy z kodu pre-strukturalnego. Dzięki temu można w miarę łatwo przenieść zasadę działania oryginalnego programu, a dopiero później zastosować refaktoryzacje mające na celu zmianę struktury kodu.
Tergo typu konstrukcji nie stosujemy w nowo utworzonym kodzie. Dlaczego? Ponieważ jak ostatni raz tego użyli to meteoryt walnął w Ziemię i powstała nauka zwana Paleontologią. A na serio… trudność utrzymania takiego kodu jest bardzo duża. Wprowadzanie zmian ciężkie, a awaryjność wysoka. Poza tym taki kod nie ma sensu w przypadku programowania obiektowego.
idę spać.