Samenvatting OOP-2
Les 1
Belangrijkste klassen voor programmeren:
- Imperatief (Pascal, Ada, ISO C)
- Functioneel (Scheme, Haskell, …)
- Object-Oriented (Java, C#, PHP, …)
- Logisch(Prolog)
Logisch programmeren
Programmeren op basis van logica.
Prolog:
Predicatenlogica
Declaratief(wat niet hoe)
Facts(feiten) en clauses (regels)
Gebruikt in expertensystemen, gegevens analyse
Functioneel
, - Gebruikt functies (lambda based)
- Programma behoudt geen state
- Geen variabele updates “destructive updates”
- Bijzonder handig bij verwerken en bewerken van lijsten
Multi-Paradigm Programmeertalen:
Talen die meerdere paradigmas ondersteunen
Combinaties procedureel+OO en logisch+functioneel komen veel voor
Python is de bekenste en beste voorbeeld van zo’n taal.
Les 2
OO Mantra
Afspraken, regelets en vuistregels
Vuistregels
1) Geef voorkeur aan de maximale privacy die werkt voor je applicatie
a. Private > protected > public;
2) Alle methods die public zijn hebben eenzelfde niveau van abstractie > high cohesion
a. We want to design components that are self-contained: independent, and with a single, well-
defined purpose;
b. Cohesion often refers to how the elements of a module belong together. Related code should be
close to each other to make it highly cohesive;
3) Data members zijn altijd verborgen en wanneer er toegang nodig is tot deze, dan maak je
gebruik van getters en setters!;
4) Waar mogelijk, verwijder implementatiedetails uit de interface (bouw een klasse er rond)
a. Scherm af of je gebruik maakt van Lists, arrays etc…;
5) Friend classes zijn helemaal NIET zo vriendelijk;
6) Een method hoort niet persé in een publieke interface omdat deze zelf public methods gebruikt;
7) De leesbaarheid van je code is belangrijker dan snelheid van coderen;
8) De klasse moet bruikbaar zijn met enkel kennis van zijn publieke interface (en dus NIET door
kennis over de implementatie details!!);
9) Wees voorzichtig met een klasse die ster verbonden is met een of meerdere klassen (low-
coupling)
a. How much do your different modules depend on each other?
b. Modules should be as independent as possible from other modules, so that changes to module
don’t heavily impact other modules.
,c. High coupling would mean that your module knows the way too much about the inner workings of
other modules. Modules that know too much about other modules make changes hard to
coordinate and make modules brittle. If Module A knows too much about Module B, changes to
the internals of Module B may break functionality in Module A.
, Het OOP Mantra
De gefluoreerde lijnen zijn nieuwe regels boven op de vuistregels!
1) Verkies associaties boven overerving;
2) Een method bevat niet meer dan 15 regels code;
3) Een method is ofwel een inspector, ofwel een mutator, maar NOOIT beide;
4) Elke method van enige betekenis heeft een contract;
5) Geef voorkeur aan maximale privacy (private > protected > public);
6) Streef naar high cohesion;
7) Data members zijn altijd verborgen;
8) Verwijder implementatie-details uit de interface;
9) Friend classes zijn niet zo vriendelijk;
10) Een method hoort niet in de publieke interface omdat deze zelf publieke methods gebruikt;
11) Leesbaarheid is belangrijker dan snelheid;
12) De klasse moet bruikbaar zijn met enkel kennis van zijn publieke interface;
13) Streef naar low coupling;
Defensief programmeren
Design by contract
De interface van een klasse is een contract tussen de ontwikkelaar-aanbieder en ontwikkelaar-
gebruiker.
Design van een klassen kan gezien worden als het opstellen van een contract met je collega software
ontwikkelaar:
a) Wat bied je aan (public methods)
b) Wat garandeer je (assertions)
c) Welke exceptions moet je melden (exceptions)
Een contract, dat wil zeggen dat je voor elke method:
1) Beschrijft in elke omstandigheden die mag opgeroepen worden: pre-condities;
2) Indien aan de pre-condities voldaan is, beschrijft wat de method zal afleveren of verwezenlijken:
post-condities;
3) Beschrijft welke uitzonderlijke omstandigheden er kunnen voordoen: exceptions ;
Het contract moet zo opgesteld zijn dat alles wat in het contract staat zodat de methode begrijpbaar is
zonder kennis van de implementatie van de methode.
Les 1
Belangrijkste klassen voor programmeren:
- Imperatief (Pascal, Ada, ISO C)
- Functioneel (Scheme, Haskell, …)
- Object-Oriented (Java, C#, PHP, …)
- Logisch(Prolog)
Logisch programmeren
Programmeren op basis van logica.
Prolog:
Predicatenlogica
Declaratief(wat niet hoe)
Facts(feiten) en clauses (regels)
Gebruikt in expertensystemen, gegevens analyse
Functioneel
, - Gebruikt functies (lambda based)
- Programma behoudt geen state
- Geen variabele updates “destructive updates”
- Bijzonder handig bij verwerken en bewerken van lijsten
Multi-Paradigm Programmeertalen:
Talen die meerdere paradigmas ondersteunen
Combinaties procedureel+OO en logisch+functioneel komen veel voor
Python is de bekenste en beste voorbeeld van zo’n taal.
Les 2
OO Mantra
Afspraken, regelets en vuistregels
Vuistregels
1) Geef voorkeur aan de maximale privacy die werkt voor je applicatie
a. Private > protected > public;
2) Alle methods die public zijn hebben eenzelfde niveau van abstractie > high cohesion
a. We want to design components that are self-contained: independent, and with a single, well-
defined purpose;
b. Cohesion often refers to how the elements of a module belong together. Related code should be
close to each other to make it highly cohesive;
3) Data members zijn altijd verborgen en wanneer er toegang nodig is tot deze, dan maak je
gebruik van getters en setters!;
4) Waar mogelijk, verwijder implementatiedetails uit de interface (bouw een klasse er rond)
a. Scherm af of je gebruik maakt van Lists, arrays etc…;
5) Friend classes zijn helemaal NIET zo vriendelijk;
6) Een method hoort niet persé in een publieke interface omdat deze zelf public methods gebruikt;
7) De leesbaarheid van je code is belangrijker dan snelheid van coderen;
8) De klasse moet bruikbaar zijn met enkel kennis van zijn publieke interface (en dus NIET door
kennis over de implementatie details!!);
9) Wees voorzichtig met een klasse die ster verbonden is met een of meerdere klassen (low-
coupling)
a. How much do your different modules depend on each other?
b. Modules should be as independent as possible from other modules, so that changes to module
don’t heavily impact other modules.
,c. High coupling would mean that your module knows the way too much about the inner workings of
other modules. Modules that know too much about other modules make changes hard to
coordinate and make modules brittle. If Module A knows too much about Module B, changes to
the internals of Module B may break functionality in Module A.
, Het OOP Mantra
De gefluoreerde lijnen zijn nieuwe regels boven op de vuistregels!
1) Verkies associaties boven overerving;
2) Een method bevat niet meer dan 15 regels code;
3) Een method is ofwel een inspector, ofwel een mutator, maar NOOIT beide;
4) Elke method van enige betekenis heeft een contract;
5) Geef voorkeur aan maximale privacy (private > protected > public);
6) Streef naar high cohesion;
7) Data members zijn altijd verborgen;
8) Verwijder implementatie-details uit de interface;
9) Friend classes zijn niet zo vriendelijk;
10) Een method hoort niet in de publieke interface omdat deze zelf publieke methods gebruikt;
11) Leesbaarheid is belangrijker dan snelheid;
12) De klasse moet bruikbaar zijn met enkel kennis van zijn publieke interface;
13) Streef naar low coupling;
Defensief programmeren
Design by contract
De interface van een klasse is een contract tussen de ontwikkelaar-aanbieder en ontwikkelaar-
gebruiker.
Design van een klassen kan gezien worden als het opstellen van een contract met je collega software
ontwikkelaar:
a) Wat bied je aan (public methods)
b) Wat garandeer je (assertions)
c) Welke exceptions moet je melden (exceptions)
Een contract, dat wil zeggen dat je voor elke method:
1) Beschrijft in elke omstandigheden die mag opgeroepen worden: pre-condities;
2) Indien aan de pre-condities voldaan is, beschrijft wat de method zal afleveren of verwezenlijken:
post-condities;
3) Beschrijft welke uitzonderlijke omstandigheden er kunnen voordoen: exceptions ;
Het contract moet zo opgesteld zijn dat alles wat in het contract staat zodat de methode begrijpbaar is
zonder kennis van de implementatie van de methode.
