Refactoring before assignment 4

[buzzdead]

Ting som kanskje ikke er nødvendig å gjøre til presentasjonen, men som alikevel bør gjøres frem til innleveringen!

• [x] continueGameLoop() i Game til en Round Event, gjøre det mye mer oversiktlig og lesbart med metoder.
• [x] Refaktorere og fikse Menu #188 #211
• [x] Setters metoder bruker this. og getters metoder bruker ikke this.
• [x] statisk TiledTranslator #220 blir laget 50 ganger av spillet og alle instansene er helt like. (kan f.eks opprettes statisk i settingsutil)
• [x] GameView klassen Hovedsakelig render metoden, helst ha den til å være på 5-10 linjer.
• [x] JavaDoc #207 Kan skrive ut dette separat med generate JavaDoc under tools i intellij, kanskje vurdere å inkludere dette i innleveringen?

Refaktorere med hensyn på SRP

• [x] ProgramCardsView
• [x] UIElements #209 flere veier å gå, enkeltvis legge opp en klasse til å konstruere elementene, en klasse til å utføre funksjonene, eventuelt en klasse for hver "del" av uielements, f.eks en for helse og reboots, en for knappene..

Til vurdering

• [x] KeyboardInput #193 Når jobben er gjort, hva slags funksjoner er det fornuftig å etterlate programmet, og hvilken plass skal denne klassen ha i programmet?

• [x] AssetManagerUtil til et SRP (Hente ting fra -filer-), #94 Vurdere hva vi skal gjøre med robotene i denne klassen. (Brukes flere steder, men det er ikke et hinder).

[timharek]

Det blir nevnt

SRP

flere ganger, med dette mener du "Single responsibility principle"?

[buzzdead]

Ja, enhver klasse skal alltid forholde seg til en oppgave og forholde seg til et singulært prinsipp i forhold til funksjonalitet.

[thomashusebo]

Anngånde kontroll i spill vs debug: er gjort en del her:

193

[buzzdead]

Men tenker du å ha med alle de funksjonene, er nesten hele tastaturet man bruker for å debugge er det ikke, og mange av de fungerer ikke som de skal lenger i forhold til andre ting. Mange spill har muligheten til å "aktivere debug mode" on the fly.

[timharek]

Flyttet til nye issues som er nice to have.