mahlersu91740/GameOfLifeAssigment
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

nextGeneration() Überprüfung Einsamkeit + setDead() Implementierung

Browse Source
This commit is contained in:
Susanne 2025-02-16 16:01:01 +01:00
parent c4e026a04b
commit 903c86b099
4 changed files with 3 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
out/production/GameOfLifeAssignment/Life.class
View File

Binary file not shown.

BIN
out/test/GameOfLifeAssignment/LifeTest.class
View File

Binary file not shown.

5
src/Life.java
View File

@ -38,8 +38,7 @@ public class Life implements ILife {
@Override
public void setDead(int x, int y) {
// TODO Auto-generated method stub
grid[x][y] = false;
}
@Override
@ -55,6 +54,8 @@ public class Life implements ILife {
for (int x = 0; x < grid[y].length; x++) {
if (countAliveNeighbours(x, y) == 3) {
next.setAlive(x, y);
} else if (countAliveNeighbours(x, y) < 2) {
next.setDead(x, y);
}
}
}

31
test/LifeTest.java
View File

@ -24,29 +24,6 @@ public class LifeTest {
public void destroyLonelyCell() {
// Zellen, die weniger als zwei Nachbarn haben, müssen sterben (Einsamkeit).
// ----- ANMERKUNG -----
// Nach dem Schreiben und Ausführen dieses Tests, habe ich den bisher bestehenden Code so verstanden,
// dass die Zellen ja mit jeder neuen Generation standardmäßig als 'tot' initialisiert werden,
// solange man nicht ausdrücklich zuvor sagte, die Zelle soll leben.
// Sprich lebende Zellen aus der alten Generation werden zunächst nicht in die Folgegeneration vererbt und
// dort dann geschaut, ob diese noch sterben müssen.
//
// Demnach bin ich an diesem Punkt nun etwas verwirrt um die generelle Notwendigkeit einer setDead()-Methode,
// werde sie sowie die übrigen Tests und Funktionen aber dennoch implementieren. Jedoch ist es möglich,
// dass ich nun die TDD-Methodik weniger gezielt anwenden werde. Grund hierfür ist, dass ich es auch als
// sinnfrei empfinde, den Code gezielt entsprechend zu manipulieren, nur damit der Test erzwungenermaßen failed.
//
// Zudem ist nach der Ausarbeitung, also dem Refactoring des Codes (jedenfalls war das meine Intention dabei)
// anhand des ersten Testfalls ja nun bereits sämtliche nötige Logik implementiert.
//
// Also ist mein Ziel nun wie gesagt, dass ich nach bestem Wissen und Gewissen alles weiterhin schrittweise
// implementieren werde, aber es möglich ist, dass mMn redundante Zwischenschritte fehlen könnten.
// Arrange: lebende Zelle (1,1) hat weniger als zwei Nachbarn und sollte sterben.
Life l = new Life();
l.setAlive(1, 1);
@ -57,14 +34,6 @@ public class LifeTest {
// Assert: Zelle (1,1) sollte tot sein
assertFalse(nextGen.isAlive(1, 1));
// Was für destroyCell eigentlich, wozu setDead generell??? Die Zelle wird doch sowieso in der nextGen mit
// false initalisiert, solange sie nicht explizit als true (mittels setAlive) initialisiert werden soll.
// Deshalb wird der Test ja sogar jetzt ohne setDead-Implementierung grün.
//
// Ich muss doch nie eine Zelle aktiv mit setDead destroyen, wenn sie in der Folgegeneration sowieso immer
// zu Anfang tot ist, solange ich sie nicht aktiv belebe?
}