Share
Så langt i denne serien har vi diskutert objektorientert programmering generelt, og OOP-prinsippet om kohesjon. I denne artikkelen ser vi på prinsippet om kopling og hvordan det hjelper i spillutvikling.
Merk: Selv om denne opplæringen er skrevet ved hjelp av Java, bør du kunne bruke de samme teknikkene og konseptene i nesten hvilket som helst spillutviklingsmiljø.
Kobling er prinsippet om "separasjon av bekymringer". Dette betyr at ett objekt ikke direkte endrer eller endrer tilstanden eller oppførelsen til en annen gjenstand.
Kobling ser på forholdet mellom objekter og hvor nært de er. Et relasjonsdiagram er en fin måte å visualisere sammenhengen mellom objekter på. I et slikt diagram representerer bokser objekter og piler representerer en forbindelse mellom to objekter der ett objekt kan påvirke en annen gjenstand direkte.
Et godt eksempel på kobling er HTML og CSS. Før CSS ble HTML brukt til både oppføring og presentasjon. Dette skapte oppblåst kode som var vanskelig å endre og vanskelig å vedlikeholde. Med fremkomsten av CSS ble HTML brukt bare for oppslag, og CSS overtok for presentasjon. Dette gjorde koden ganske ren og lett forandret. Bekymringene med presentasjon og markering ble separert.
Objekter som er uavhengige fra hverandre og ikke direkte endrer tilstanden til andre objekter, sies å være løst koblet. Løs kobling gjør at koden blir mer fleksibel, mer foranderlig og lettere å jobbe med.
Objekter som stole på andre objekter, og som kan endre tilstandene til andre objekter, sies å være sammensveiset. Stram kobling skaper situasjoner der endring av koden til en gjenstand også krever endring av koden til andre objekter (også kjent som en krusningseffekt). Tettkoblet kode er også vanskeligere å gjenbruke fordi den ikke kan skilles fra.
En vanlig setning du vil høre er "streve for lav kobling og høy kohesjon". Denne setningen er en nyttig påminnelse om at vi skal streve etter kode som skiller oppgaver og ikke stoler sterkt på hverandre. Således er lav (eller løs) kopling generelt god, mens høy (eller tett) kopling er generelt dårlig.
Først kan vi se på Asteroids gjenstander og hvordan de er koblet sammen. Husk at objektene er et skip, en asteroide, en flygende tallerken og en kule. Hvordan er disse objektene relatert eller knyttet til hverandre?
I asteroider kan et skip brenne en kule, en kule kan treffe en asteroide og en flygende tallerken, og en asteroide og en flygende tallerken kan slå skipet. Vårt relasjonsdiagram ser da ut som følger:
Som du kan se gjenstandene er alle ganske godt sammenhengende. På grunn av dette må vi være forsiktige med hvordan vi skriver koden, ellers vil vi ende opp med et tett koblet system. La oss ta for eksempel skipet skyte en kule. Hvis skipet skulle skape et punktobjekt, holde oversikt over sin posisjon, og deretter endre asteroiden når kulen treffer, ville vårt system være veldig tett koblet.
I stedet skal skipet skape et punktobjekt, men ikke bekymre deg for det etter det punktet. En annen klasse vil være ansvarlig for å holde styr på kulenes posisjon, så vel som hva som skjer når en kulde rammer en asteroide. Med en mellomklasse mellom våre relasjoner, ser diagrammet ut som følger:
Dette relasjonsdiagrammet ser mye bedre ut og skaper et veldig løst koblet system. I dette systemet, hvis vi skulle legge til et objekt, som en meteor, kunne vi lett gjøre det uten å måtte endre hvordan skips- eller kuleobjektene fungerer - vi ville bare la vår formidlingsklasse ta vare på alt.
Siden det er bare ett objekt i Tetris, er Tetrimino-koblingen egentlig ikke et problem, da det ikke kan være noen relasjoner med andre objekter.
For Pac-Man, kan stram kobling oppstå når Pac-Man spiser en kraftpellet. Når en kraftpille blir spist, kan Pac-Man da spise spøkelser og spøkelsens tilstand endres til spiselig. Hvis Pac-Man-objektet skulle spore når det spiste en kraftpelleter og deretter starte forandringstilstanden til hvert spøkelse, ville systemet være tett koblet.
Igjen, en annen klasse er nødvendig for å holde oversikt over denne informasjonen og behandle den slik at våre objekter kan løses løst. Nedenfor er et eksempel på hvordan en mellommennesklasse kunne spore Pac-Man å spise en kraftpellet.
/ ** * Intermediate Class som holder styr på spill hendelser * / offentlig klasse Spill ... hvis (Pac-Man.eats (Power_Pellet)) Ghosts.changeState (); ...
Kobling er prinsippet om å redusere hvordan objekter direkte påvirker tilstandene og atferdene til andre objekter. Kobling bidrar til å lage kode som er lettere å lese, så vel som lettere å endre.
I neste Quick Tip, diskuterer vi prinsippet om innkapsling og hvorfor det hjelper med å skape vedlikeholdsbar kode. Følg oss på Twitter, Facebook eller Google+ for å holde deg oppdatert med de siste innleggene.
Accentsconagua