OPTIONALES (?) Refactoring zum Codeverständnis und Eindeutigkeit

This commit is contained in:
Susanne 2025-02-16 16:50:18 +01:00
parent 25b5a74454
commit 092fb1dc01
2 changed files with 10 additions and 6 deletions

View File

@ -52,13 +52,17 @@ public class Life implements ILife {
for (int y = 0; y < grid.length; y++) {
for (int x = 0; x < grid[y].length; x++) {
// Refactoring: vermeide zwei fast identische Codeblöcke (if-Abfragen)
if (countAliveNeighbours(x, y) == 3 || countAliveNeighbours(x, y) == 2) {
// Dieser Schritt wäre nun noch ein mögliches Refactoring, um die Fallunterscheidungen zwischen keepAlive und
// setAlive nochmal deutlicher zu machen, ändert aber eigentlich (soweit ich es sehe) nichts am Codeverhalten.
// mMn Ansichtssache, ob das nun redundanter Code ist oder tatsächlich das Verständnis bedeutend verbessert.
if (isAlive(x, y) && (countAliveNeighbours(x, y) == 3 || countAliveNeighbours(x, y) == 2)) {
next.setAlive(x, y);
}
// Refactoring: zuvor gesetzte Bedingungen machen weitere Überprüfungen redundant
else {
next.setDead(x, y);
} else if (!isAlive(x, y) && countAliveNeighbours(x, y) == 3) {
next.setAlive(x, y);
} else {
next.setDead(x, y); // das hier ist mMn im Grunde ja auch redundant, da eben die Zellen standardmäßig tot initialisiert werden
}
}
}