Small refactoring

* Moved `ConnectionGetter` to its own file
* Added method `mapAndRemove` to Server/Client.scala
* Replaced usages of `removeNonSatisfying` with the above
* Added some documentation

1 files changed, 157 insertions, 0 deletions

diff --git a/tyylimaare.txt b/tyylimaare.txt
new file mode 100644
index 0000000..2de2c18
--- /dev/null
+++ b/tyylimaare.txt
@@ -0,0 +1,157 @@
+
+Scala-tyylimääre tekstipeliin
+=============================
+
+
+Seuraa kurssin tyyliopasta ja tätä ohjetta. Noudata tätä ohjetta, jos ohjeiden
+välillä on ristiriita. Kirjoita mieluummin vähemmän koodia paremmin kuin
+enemmän koodia laiskasti. Näin vähennetään tulevaisuuden työtä, joka syntyy
+kun koodi on lähtenyt lapasesta eikä kenelläkään ole enää mitään käsitystä
+ohjelman struktuurista. Tee näin etenkin, kun kirjoittamamme koodin laatua ja
+yhtenäisyyttä arvioidaan palautuksessa.
+
+=> https://docs.scala-lang.org/scala3/book/ca-multiversal-equality.html
+Kannattaiskohan käyttää? ^^
+
+
+This-sanan käyttö
+-----------------
+
+This-sanaa tulee käyttää aina, kun se on mahdollista. Se selventää sitä, kenen
+muuttuja on kyseessä ja missä se on määritelty.
+
+
+Merkkijonojen muodostaminen
+---------------------------
+
+Käytä s"Arvo: $a, toinen arvo: ${this.b}" jos se ei ole aivan tajuttoman
+kömpelö ratkaisu tilanteeseen. Se on lähes aina parempi ilmaisu kuin merkki-
+jonojen summaaminen.
+
+
+Tyyppien kirjaaminen
+--------------------
+
+Nimellisiin funktioihin kirjoitetaan aina paluutyyppi, vaikka se olisi Unit tai
+funktio ei olisi julkinen. Paluutyypin kirjoittaminen pakottaa miettimään vielä
+kerran funktion todellista tarkoitusta. Kun sen on kirjoittanut, Scalan tyyppi-
+järjestelmä huomaa virheet aikaisemmin ja ne saadaan korjattua. Julkisilla
+funktioilla tyyppimääre toimii hieman kuin dokumentaatio.
+
+Julkisille muuttujille (etenkin ohjelman laajuisille vakioille) tulee kirjata
+tyypit.
+
+
+Rivien pituudet
+---------------
+
+Rivin maksimipituus on 80 merkkiä. Tässä sisennykset lasketaan kahdeksaksi
+merkiksi. Tämä rajoitus on ikiaikaista perua siitä, kun terminaalien standardi-
+koko leveyssuunnassa oli 80 merkkiä. Tämä rajoitus on kuitenkin nykyäänkin
+kätevä, koska kahta 80-merkkistä riviä on helppo pitää vierekkäin melkein näy-
+töllä kuin näytöllä. Lisäksi ylipitkä rivi voi olla oire epäselkeästä koodista,
+joka muutenkin kuuluisi jakaa osiin.
+
+Alla on esimerkkejä, miten ylipitkiä rivejä saa (ja kuuluu) jakaa.
+
+Esim 1
+```
+def jokuNimi(parametri1: tyyppi1, parametri2: tyyppi2, parametri3: tyyppi3): paluutyyppi =
+	???
+
+def jokuNimi(
+	parametri1: tyyppi1,
+	parametri2: tyyppi2,
+	parametri3: tyyppi3
+): paluutyyppi =
+	???
+```
+
+Esim 2
+```
+kokoelma.filter(_ % 2 ==0).flatten.map(_.muutaHauskallaTavalla).contains(condition)
+
+kokoelma
+	.filter(_ % 2 ==0)
+	.flatten
+	.map(_.muutaHauskallaTavalla)
+	.contains(condition)
+```
+
+Esim 3
+```
+val pitkäMuttaHyväMuuttujanNimi = PitkäOlionNimiJotaEiTahdotaMuuttaa(jokuParametri)
+
+val pitkäMuttaHyväMuuttujanNimi =
+	PitkäOlionNimiJotaEiTahdotaMuuttaa(jokuParametri)
+```
+
+Esim 4
+```
+val olio = MoniparametrisenOlionLuoja(parametri1, parametri2, parametri3, parametri4, parametri5)
+
+val olio = MoniparametrisenOlionLuoja(
+	parametri1,
+	parametri2,
+	parametri3,
+	parametri4,
+	parametri5
+)
+```
+
+Esim 5: Huomaa myös tyhjän tilan käyttö ja kommentin alku- ja loppumerkkien
+        paikat. Tuollainen muotoilu on nättiä ja suotavaa.
+```
+/* Pitkä dokumentaatiokommentti funktiolle, jonka kuuluu olla useammalla rivillä, koska muuten koodin dokumentaatiosta ei saa selvää ja on näin ollen turhaa*/
+
+/* Pitkä dokumentaatiokommentti funktiolle, jonka kuuluu olla useammalla
+   rivillä, koska muuten koodin dokumentaatiosta ei saa selvää ja on näin ollen
+   turhaa. */
+```
+
+
+Sisennykset
+-----------
+
+Sisentämiseen käytetään sisennyksiä eikä välilyöntejä. Näin jokainen ohjelmoija
+saa katsoa koodiansa sillä sisennyspituudella josta pitää ja säästetään muisti-
+tilaa.
+
+IntelliJ IDEAn tapauksessa tulee siis muuttaa asetus
+File
+ > Settings
+  > Editor
+   > Code Style
+    > Java
+     > Tabs and Indents
+      > Use tab character
+
+Kuten Linus Torvalds on sanonut, jos tiedostossa on enemmän kuin kolme
+sisennettyä tasoa ([tab][tab][tab]), olet todennäköisesti eksyksissä koodissasi
+ja ohjelmasi sisäinen logiikka ja rakenne kaipaa parantamista.
+
+Kolmen sisennyksen sääntö ei ole kiveen hakattu, koska me ei olla yhtä hyviä
+ohjelmoijia kuin Torvalds. Jos kuitenkin huomaat olevasi sisennysten
+viidakossa, josta ei saa selvää, niin voi olla hyvä miettiä, voisiko ohjelman
+rakennetta muokata vaikkapa lisäämällä apufunktioita yms.
+
+
+If, match, for, while jne...
+----------------------------
+
+Jos saatavilla on ohjelman toimintaa ja datan virtausta kuvaavia korkeamman
+asteen funktioita, ja et tiedä niiden suorituskyvyn olevan heikkoa verrattnua
+itse tekemääsi toteutukseen, käytä korkeamman asteen funktioita. Jos et heti
+keksi sopivaa korkeamman asteen funktiota, ei se tarkoita ettei sellaista ole.
+Lue läpi korkeamman asteen funktiot Scalan dokumentaatiosta, esim.
+
+Vector-luokan dokumentaatio:
+=> https://scala-lang.org/api/3.x/scala/collection/immutable/Vector.html#
+
+Buffer-luokan dokumentaatio:
+=> https://scala-lang.org/api/3.x/scala/collection/mutable/Buffer$.html#
+
+Option-luokan dokumentaatio:
+=> https://scala-lang.org/api/3.x/scala/Option.html#
+
+