Java: Conway ' s Game of Life (Norsk)

package first; public abstract class CellularAutomaton{ public abstract String lifeCycle(); public abstract boolean rules(int num); } 

 package first; import java.util.Stack; import java.util.HashMap; import java.util.Iterator; import java.util.Map; public class GameOfLife extends CellularAutomaton { int board[][]; int dim; Stack<Integer> stackCells; HashMap<Integer, Integer> hmapCells; public gameOfLife(int d, Stack<Integer> s){ board = new int[d][d]; dim = d; stackCells = s; hmapCells = new HashMap<>(); } public boolean rules(int num){ return num == 3 || num == 12 || num == 13; } private void birth() { Iterator<Map.Entry<Integer,Integer>> it=hmapCells.entrySet().iterator(); while(it.hasNext()) { Map.Entry<Integer,Integer> pair = it.next(); int key = pair.getKey(); if(rules(pair.getValue())){ stackCells.add(key); } board[key/dim][key%dim] = 0; it.remove(); } } private void insertAlive() { while(!stackCells.isEmpty()) { int cell = stackCells.pop(); int x = cell / dim; int y = cell % dim; int startX = (x <= 0) ? 0 : x - 1; int startY = (y <= 0) ? 0 : y - 1; int endX = (x >= dim - 1) ? x + 1 : x + 2; int endY = (y >= dim - 1) ? y + 1 : y + 2; for(int i = startX; i < endX; ++i) { for(int j = startY; j < endY; ++j) { hmapCells.put(i * dim + j, ++board[i][j]); } } hmapCells.put(cell, board[x][y] += 9); } } private String printBoard() { StringBuilder s = new StringBuilder(); for(int elements[] : board) { for(int element : elements) { if(element >= 10){ s.append("* "); } else { s.append(" "); } } s.append("\n"); } return s.toString(); } public String lifeCycle() { birth(); insertAlive(); return printBoard(); } }  

package first; import java.util.Stack; public class Simulation { public static void main(String args[]) throws InterruptedException{ int dim = 70; Stack<Integer> init = new Stack<>(); //all vals pushed to init is of the form: xPos * dim + yPos init.push(351); init.push(352); init.push(421); init.push(422); init.push(245); init.push(246); init.push(315); init.push(316); init.push(361); init.push(431); init.push(501); init.push(292); init.push(572); init.push(223); init.push(643); init.push(224); init.push(644); init.push(435); init.push(296); init.push(576); init.push(367); init.push(437); init.push(507); init.push(438); init.push(231); init.push(301); init.push(371); init.push(232); init.push(302); init.push(372); init.push(163); init.push(443); init.push(165); init.push(445); init.push(95); init.push(515); GameOfLife gOL = new GameOfLife(dim, init); while(true) { System.out.print(gOL.lifeCycle()); Thread.sleep(100); System.out.print("\033[H\033[2J"); } } } 

Først av alt, jeg tror algoritmen er ganske smart, noe som for min ydmyke erfaring ikke er så vanlig for en student. Så gratulerer hvis du fant på det selv! Hvis du leter etter smarte implementeringer, vil jeg anbefale funksjonelle, for eksempel i Haskell ; se også Korteste spill of life .

Vær oppmerksom på smartness. En god kode skal være lett å lese , lett å forstå . Dette er selvfølgelig ikke alltid mulig når det gjelder kompleks algoritme, men jeg mener at det burde være et mål.

jjjjjjjjjjjj sa:
Merk: de fleste kommentarer er tatt ut fordi de ikke legger til mye for lesbarheten til koden

Poenget med kommentarer er å hjelpe folk til å forstå koden din (generelt sett fokusere på » hvorfor » i stedet for på » hva «). Her, for å hjelpe folk å forstå, måtte du legge til mye tekst i innlegget ditt. Ideelt sett er dette ikke nødvendig fordi koden er:

• selvdokumentert,
• kommentert for å fjerne komplekse / implisitte ting.

For eksempel, her er en rask omskriving av koden din i et forsøk på å gjøre koden mer uttrykksfull:

GameOfLife.java

 /** * Computes the next state of the automaton by using Conway"s original rules. */ public class GameOfLife extends CellularAutomaton { /** * Stores all cells in a two-dimensional matrix. The value stored is * the number of live neighbors of the cell, +10 if the cell is alive. */ private int board[][]; private int dim; /* * index(cell) = cellX * dim + cellY */ private Stack<Integer> indexesOfCellsAliveAtNextGeneration; private HashMap<Integer, Integer> cellsMaybeAliveAtNextGeneration; public GameOfLife(int d, Stack<Integer> s){ board = new int[d][d]; dim = d; indexesOfCellsAliveAtNextGeneration = s; cellsMaybeAliveAtNextGeneration = new HashMap<>(); } public String newGeneration() { populateWorldWithAliveCellsFromPreviousGeneration(); computeCellsMaybeAliveAtNextGeneration(); return boardAsString(); } private void populateWorldWithAliveCellsFromPreviousGeneration() { for (Map.Entry<Integer, Integer> cell : cellsMaybeAliveAtNextGeneration.entrySet()) { int cellIndex = cell.getKey(); int cellValue = cell.getValue(); if(willBeAlive(cellValue)){ indexesOfCellsAliveAtNextGeneration.add(cellIndex); } board[cellIndex/dim][cellIndex%dim] = 0; } } private static boolean willBeAlive(int cell){ return (!isAlive(cell) && nbOfNeighbors(cell) == 3) || (isAlive(cell) && (nbOfNeighbors(cell) == 2 || nbOfNeighbors(cell) == 3)); } private static boolean isAlive(int cell) { return cell >= 10; } private static int nbOfNeighbors(int cell) { return cell % 10; } private void computeCellsMaybeAliveAtNextGeneration() { cellsMaybeAliveAtNextGeneration.clear(); while(!indexesOfCellsAliveAtNextGeneration.isEmpty()) { int cellIndex = indexesOfCellsAliveAtNextGeneration.pop(); int cellX = cellIndex / dim; int cellY = cellIndex % dim; int topLeftNeighbourX = (cellX <= 0) ? 0 : cellX - 1; int topLeftNeighbourY = (cellY <= 0) ? 0 : cellY - 1; int bottomRightNeighbourX = (cellX >= dim - 1) ? cellX + 1 : cellX + 2; int bottomRightNeighbourY = (cellY >= dim - 1) ? cellY + 1 : cellY + 2; // Iterate through every cell"s neighbor to increate their neighbor number for(int i = topLeftNeighbourX; i < bottomRightNeighbourX; ++i) { for(int j = topLeftNeighbourY; j < bottomRightNeighbourY; ++j) { boolean isNeighbor = i != cellX || j != cellY; if (isNeighbor) { int neighborIndex = i * dim + j; cellsMaybeAliveAtNextGeneration.put(neighborIndex, incrementedNumberOfNeighbors(i, j)); } } } cellsMaybeAliveAtNextGeneration.put(cellIndex, makeAlive(cellX, cellY)); } } private int incrementedNumberOfNeighbors(int x, int y) { return ++board[x][y]; } private int makeAlive(int x, int y) { return board[x][y] += 10; } private String boardAsString() { StringBuilder s = new StringBuilder(); for(int[] cells : board) { for(int cell : cells) { if(isAlive(cell)){ s.append("* "); } else { s.append(" "); } } s.append("\n"); } return s.toString().trim(); } }  

Jeg omdøpte for det meste noen variabler / metoder og introduserte noen verktøymetoder. Koden er litt lengre og føles mer verbose men er IMHO også lettere å forstå. Det er fremdeles veldig prosessuelt (som ikke er dårlig i seg selv, spesielt for et så enkelt program), men det kan være lurt å prøve å legge til mer ekspressivitet ved å introdusere nye klasser som Board eller Cell. Du vil finne slike OO-implementeringer på GitHub .

Koden din kan også komme i minneproblemer med store tavler. Faktisk lagrer board[][] variabelen alle cellene, til og med døde. Med et 10000 x 10000-kort som bare inneholder ~ 5/6 celler, vil du kaste bort mye minne. En løsning er å bruke et sparsomt utvalg (i utgangspunktet en sett som bare inneholder levende celler).

Som en sidemerknad prøvde jeg også for noen år siden å modellere en svært konfigurerbar GoL i en » ren » OO måte; koden min er på GitHub hvis du vil sjekke den ut. Metoden som beregner neste generasjon av verden er ImmutableGeneration :: nextGeneration ; gitt et sett med levende celler, beregner det i utgangspunktet: 1) alle naboceller, deretter 2) beholder bare de som vil være i live. Regler som indikerer om en celle vil være i live eller død, er implementert i Rule.java .

---

REDIGER : personlig mening om kortfattethet kontra ordlyd når det gjelder n aming å svare på en kommentar

Først og fremst tror jeg at det ikke er noen riktige svar: det handler om avveininger og personlige preferanser. Navngivning er vanskelig, og du vil finne mange artikler om emnet.

Det er bare to vanskelige ting i datavitenskap: cache-ugyldiggjøring og navngivning av ting
– Phil Karlton

Min oppfatning er at konsesjon er hyggelig, men kan føre til uklarheter. Og uklarhet, spesielt skjult, er en trussel.Det første eksemplet som kommer til meg er feilaktig å blande enheter:

 // Everything looks good... double pathLength = distanceFromGoal + distanceToTarget; // ... but adding units makes easy to spot bugs double pathLengthInKilometers = distanceFromGoalInMeters + distanceToTargetInMillimeters;  

At Når det er sagt, gjør lange navn koden vanskeligere å lese. De kan reduseres ved å ta to ting i betraktning:

• konteksten (f.eks. Navnet på den vedlagte metoden / klassen / pakken),
• omfanget (en lokal variabel i en 3-linjers metode kan være bra med et kort navn, mens en funksjon som brukes flere ganger på tvers av hele kodebasen kan trenge en lengre).

Det er også det som anbefales av Googles navnekonvensjoner .

Som en siste merknad, som du foreslo, kan veldig lange navn bli sett på som kodelukt. Vanligvis er problemet mangel på samhold (klassen / metoden gjør for mye forskjellige ting – nok en gang, ingen klare beregninger på dette, det er opp til utviklerens følelse). For eksempel, i koden jeg foreslo, kan vi tenke på populateWorldWithAliveCellsFromPreviousGeneration som en metode som holder ansvarsområder: 1) beregne cellene som vil være i live ved neste generasjon og 2) befolke verden. Vi kunne dermed dele den i to: populateWorldWith(aliveCellsFromPreviousGeneration()).

På samme måte kunne vi samle attributtene som navnet ender med » atNextGeneration » under en ny Generation klasse:

 public class GameOfLife extends CellularAutomaton { private Generation lastGeneration; public String newGeneration() { this.lastGeneration = lastGeneration.nextGeneration(); return this.lastGeneration.toString(); } } public class Generation { public Generation nextGeneration() { return new Generation(aliveAtNextGeneration(this.aliveCells)); } ... }  

Men å dele logikken i for mange klasser vil også øke arkitekturkompleksiteten og gjøre det vanskeligere å forstå flyten.

Som en konklusjon Jeg vil råde deg til å huske på at alle kodestykker kan modifiseres av utviklere som ikke har noen forkunnskaper om prosjektet, og som må forstå hva koden gjør, og hvorfor det gjør det slik at de kan vedlikeholde det eller gjenbruke deler uten å innføre regresjoner. Det er ingen silverbullet: bare kompromisser, og det som betyr noe når du tar et valg er at:

• du kan identifisere kompromisset,
• du forstår fordeler og ulemper med hvert alternativ og velg ett av dem bevisst.

(men ikke skyv for mye press på deg: KISS og husk at koden kan ombygges deretter)

Kommentarer

• Tusen takk for kommentaren din. Jeg er så glad du kommenterte fordi jeg aldri hadde tenkt på å bare lagre de levende cellene (dette endrer mye av koden min, og etter min mening gjør den mye bedre). Jeg ønsket å spørre litt om din mening om balansen mellom å være tydelig med variable navn og å være kortfattet. Med andre ord, hvordan kan du bestemme når programmet er for ordentlig? Betyr det at du må bruke usedvanlig lang tid på å lage de riktige variabelnavnene, eller at det er noe feil med logikken og utformingen av koden? Takk igjen.
• Jeg redigerte svaret mitt for å dele mitt syn på det. Det ‘ er mye tekst som i utgangspunktet sier at » det ikke er noen riktige svar, det ‘ handler om kompromisser, så tenk på fordeler og ulemper når du tar et valg «.

Jeg har bare en liten anbefaling angående lesbarhet. Når du har en metode som heter printBoard, forventer du normalt at den skriver ut tavlen . Et bedre navn for den metoden ville være boardToString.