C# Design Principles¶
Inleiding¶
Deze documentatie dient als leidraad om theoretische concepten in onder meer object georiënteerd programmeren, databases en infrastructuur te begrijpen en toe te passen. Het benadrukt de relevantie van theoretische kennis voor praktische toepassingen in je project en biedt een gestructureerde aanpak voor het documenteren van je voortgang.
Samenvatting van de cursus in ongeveer 300 woorden¶
Deze cursus ging over verschillende programmeer principes die handig zijn om je code mooier en beter onderhoudbaar te maken, maar niet per se vaste regels.
Het ging over voornamelijk de SOLID principes, maar ook een paar principes daarnaast.
| Principe | Uitleg |
|---|---|
| Encapsulate what varies | In het kort, een stukje code dat vaak veranderd moet niet samen staan bij code dat dat niet doet. Deze moet dan in een losse functie. |
| Favour composition over inheritance | Eigenlijk is dit alleen een herinnering om te kijken of een relatie tussen objecten wel echt IS-A is in plaats van HAS-A. |
| Loose coupling | Ervoor zorgen dat code alleen informatie dat echt nodig is over een variabel zeker weet, zodat je er meer verschillende soorten types kan gebruiken. |
| Program to interfaces | In een notendop, zoveel mogelijk interfaces gebruiken voor stukken logica, want veel blokken logica worden herhaald buiten de inheritance om en kunnen in interfaces gezet worden. |
| Single responsibility principle | Het is slecht als veel verschillende dingen op één plek worden gedaan, want dit is niet overzichtelijk. |
| Open-closed principle | Alles moet zoveel mogelijk uitgebreid kunnen worden, zonder dat het aangepast kan worden zodat geen oude code kapot kan gaan. |
| Liskov’s substitution principle | Deze is best logisch, maar ik had er zelf zo nog niet over gedacht. Een sub-klas moet gebruikt kunnen worden in de plaats van de base klas, anders zou het inheriten beter met interfaces kunnen. |
| Interface segregation principle | Niet te veel in één interface zetten, juist de kracht van interfaces is dat je er meerdere kan hebben. En anders ga je tegen single responsibility principle in. |
| Dependency inversion principle | De dependencies moeten in één richting stromen, van boven naar beneden, anders ga je waarschijnlijk tegen de single responsibility principle in. |
Relevantie tot je project en praktische toepassing¶
De meeste punten hiervan kende ik al en paste ik ook al toe, dus op dat vlak zal niet veel veranderen. Behalve dat met deze expliciete uitleg ik er wel achter kom dat hoe ik over bepaalde dingen dacht wel een klein beetje anders is.
En deze principes zijn natuurlijk handig om in het algemeen betere code te schrijven, ook al zullen wij niet lang genoeg aan dit project werken om de volledige kracht van deze principes te getuigen.
Resultaten LinkedIn Learning cursus¶
Resultaten quiz op DLO¶
Vragen voor expert review¶
[Stel drie concrete vragen op die je tijdens de expert review wil behandelen. Deze vragen zijn gericht op het verkrijgen van feedback en inzichten van de beoordelaar.] 1. 1. 1.
Gecreëerd: May 20, 2024