Inleiding

Robert L. Glass beweerde dat de praktijk voor de theorie komt. Vooral in softwareontwikkeling is de praktijk een gebied waar de praktijk voor de theorie uitkomt, en ontwikkelaars leren het meest door hun handen vuil te maken met concrete code. Daarom gaan we theorie en concepten even aan de kant schuiven en kijken we naar een eenvoudig programma.

Een ticketverkooptoepassing implementeren

• We willen een klein evenement organiseren om het kleine theater te promoten.
  • Evenementinhoud: We loten een aantal bezoekers uit die een gratis toegangskaart ontvangen voor de show.
• We moeten de bezoekers die gewonnen hebben scheiden van de bezoekers die niet gewonnen hebben.
  • Bezoekers die gewonnen hebben: wissel de uitnodiging in voor een ticket.
  • Bezoekers die niet gewonnen hebben: koop een ticket met geld.

Oefencode:https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step01

Wat is het probleem?

Robert Martin beschrijft drie functies die een softwaremodule (ongeacht de grootte, een willekeurige component die een programma vormt, zoals een klasse, pakket of bibliotheek) moet hebben.

• Het werkt correct tijdens de uitvoering.
• Het is bedoeld om te veranderen.
  • Veranderingen moeten met minimale inspanning mogelijk zijn.
• Het communiceert met mensen die de code lezen.
  • Ontwikkelaars moeten het gemakkelijk kunnen lezen en begrijpen.

De eerder genoemde ticketverkooptoepassing voldoet aan de eerste beperking dat het correct draait, maar voldoet niet aan het doel van veranderbaarheid en communicatie.

Code die niet aan de verwachtingen voldoet

Laten we kijken waarom het niet aan het doel van communicatie voldoet.

• Wat de enter() methode van de Theater klasse doet:
  • Het theater controleert de tas van de bezoeker om te zien of er een uitnodiging in zit.
  • Als er een uitnodiging in de tas zit, vertelt het de kaartverkoper om het ticket dat in het ticketkantoor ligt in de tas van de bezoeker te stoppen.
  • Als er geen uitnodiging in de tas zit, haalt het het bedrag van het ticket uit de tas van de bezoeker, koopt het een ticket en stopt het in de tas van de bezoeker.
• Vanuit het perspectief van de bezoeker moet hij toekijken hoe het theater, een derde partij, ongevraagd zijn tas doorzoekt, geld meeneemt en een ticket erin stopt.
• Vanuit het perspectief van de kaartverkoper moet hij toekijken hoe het theater, een derde partij, zonder toestemming de waarde van tickets en contant geld in het ticketkantoor manipuleert.
• Begrijpelijke code is code waarvan de werking niet sterk afwijkt van onze verwachtingen, maar het bovenstaande theater wijkt af van onze verwachtingen.
  • De bezoeker moet zelf geld uit zijn tas halen en aan de kaartverkoper betalen om een ticket te ontvangen.
  • De kaartverkoper moet zelf een ticket uit het ticketkantoor halen, dit aan de bezoeker geven en het geld van de bezoeker in het ticketkantoor bewaren.
• Om de enter() methode te begrijpen, moet je ook veel details onthouden.
  • Audience heeft een Bag.
  • Bag bevat cash en tickets.
  • TiketSellet verkoopt tickets in TicketOffice, en TicketOffice bevat cash en tickets.

Code die gevoelig is voor veranderingen

De enter() methode gaat uit van twee voorwaarden.

• De bezoeker draagt altijd een tas bij zich om cash en een uitnodiging in te bewaren.
• De kaartverkoper verkoopt tickets alleen vanuit het ticketkantoor.

Hoe zit het dan met de onderstaande situatie?

• De bezoeker heeft mogelijk geen tas.
• De bezoeker kan in plaats van cash een creditcard gebruiken.
• De kaartverkoper kan tickets buiten het ticketkantoor verkopen.

Om bijvoorbeeld aan de eerste eis te voldoen, moeten we het Bag object van Audience verwijderen en de enter() methode van de Theater klasse aanpassen. Dit komt omdat de Theater klasse te veel details afhankelijk is van de veronderstelling dat bezoekers een tas dragen en kaartverkopers alleen tickets vanuit het ticketkantoor verkopen. Als een van deze details verandert, moeten we zowel de klasse zelf als de afhankelijke klassen (bijvoorbeeld Theater) aanpassen.

Dit is een probleem met betrekking tot afhankelijkheden tussen objecten, en afhankelijkheden impliceren invloed op veranderingen. Maar het doel van objectgeoriënteerd ontwerp is om een gemeenschap van samenwerkende objecten te creëren die van elkaar afhankelijk zijn, dus we moeten niet zomaar afhankelijkheden wegnemen, maar we moetenalleen de minimale afhankelijkheden behoudendie nodig zijn om de functionaliteit van de applicatie te implementeren, en onnodige afhankelijkheden moeten worden verwijderd.

Als de afhankelijkheid tussen objecten te hoog is, wordt ditkoppeling genoemd, en hoe hoger de koppeling tussen twee objecten, hoe groter de kans dat ze samen moeten worden gewijzigd. Het doel van ontwerp is daarom om de koppeling tussen objecten te verminderen om een ontwerp te creëren dat gemakkelijk kan worden gewijzigd.

Het ontwerp verbeteren

Theater hoeft niet te weten dat de bezoeker een tas heeft en dat de kaartverkoper tickets vanuit het ticketkantoor verkoopt. Theater wil alleen dat de bezoeker het theater binnenkomt. We moeten er dus voor zorgen dat de bezoeker zelf het contante geld en de uitnodiging in zijn tas verwerkt en dat de kaartverkoper zelf de tickets en de verkoopkosten in het ticketkantoor verwerkt.

Verhoog de autonomie

Een object dat alleen nauw verwante taken uitvoert en niet-gerelateerde taken aan andere objecten delegeert, wordt aangeduid als een object met een hoge samenhang. Door autonome objecten te creëren die hun eigen gegevens verwerken, kunnen we de koppeling verminderen en de samenhang verhogen.

Procedureel versus objectgeoriënteerd

• Procedureel
  • De enter() methode van Theater is een proces, en Audience, TicketSeller, Bag en TicketOffice zijn gegevens.
  • Procedurele programmering wordt genoemd wanneer processen en gegevens in afzonderlijke modules worden geplaatst.
  • Er is veel code die in strijd is met onze intuïtie. (bijv. de bezoeker beheert zijn eigen geld en uitnodiging)
  • Het is moeilijk om de impact van gegevensveranderingen te beperken.
  • Verantwoordelijkheden worden centraal beheerd. (Theater beheert alles)
• Objectgeoriënteerd
  • Objectgeoriënteerde programmering wordt genoemd wanneer gegevens en processen zich in dezelfde module bevinden.
  • We kunnen code schrijven die overeenkomt met onze intuïtie.
  • De impact van gegevensveranderingen kan effectief worden beperkt door inkapseling.
  • Elk object is verantwoordelijk voor zichzelf.
  • 
    

Oefencode:https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step02

We kunnen het nog beter doen

• De Bag klasse van de Audience klasse is nog steeds een passief object dat door de Audience klasse wordt bestuurd, dus we moeten de Bag klasse een autonoom object maken.
• TicketOffice van de TicketSeller klasse wordt ook willekeurig beheerd door TicketSeller. We moeten TicketOffice een autonoom object maken.
  • Maar na de wijziging ontstaat er extra koppeling tussen TicketOffice en Audience.
  • Ontwerp vereist dus een goede afweging. In dit geval kunnen we besluiten om TicketOffice een bepaald niveau van passief object te maken om de koppeling met Audience te verminderen.

Oefencode:https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step03

Ja, het is een leugen!

• Hoewel iets in de realiteit passief is, wordt alles in de wereld van objectgeoriënteerd ontwerp een actief en autonoom object.
• Het is een goed idee om personificatie te gebruiken om passieve objecten te beschouwen als objecten die lachen, praten en boos worden.

Objectgeoriënteerd ontwerp

Waarom is ontwerp nodig?

• Ontwerp is het rangschikken van code.
• Goed ontwerp betekent dat het de huidige functionaliteit volledig vervult en tegelijkertijd toekomstige wijzigingen soepel kan opnemen.

Objectgeoriënteerd ontwerp

• Veranderbare code is gemakkelijk te begrijpen code.
• Het objectgeoriënteerde paradigma helpt ons om code te schrijven zoals we de wereld zien.
• Een object is een autonoom object dat verantwoordelijk is voor zijn eigen gegevens.
• Uitstekend objectgeoriënteerd ontwerp betekent het goed beheren van afhankelijkheden tussen samenwerkende objecten.

Bronnen

• Objecten