Resume
Samenvatting Objectgeoriënteerd programmeren II (4183) UHasselt
- Établissement
- Universiteit Hasselt (UHasselt)
- Book
- Thinking in Java
Beknopte maar voldoende samenvatting OGP2 UHasselt. Behaalde score 15/20 theoretisch examen.
[Montrer plus]
Livre connecté
Titre de l’ouvrage:
Auteur(s):
- Édition:
- ISBN:
- Édition:
Vendeur
S'abonner
Aperçu du contenu
Samenvatting OOP-2Les 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 avantages d'acheter des résumés chez Stuvia:
Qualité garantie par les avis des clients
Les clients de Stuvia ont évalués plus de 700 000 résumés. C'est comme ça que vous savez que vous achetez les meilleurs documents.
L’achat facile et rapide
Vous pouvez payer rapidement avec iDeal, carte de crédit ou Stuvia-crédit pour les résumés. Il n'y a pas d'adhésion nécessaire.
Focus sur l’essentiel
Vos camarades écrivent eux-mêmes les notes d’étude, c’est pourquoi les documents sont toujours fiables et à jour. Cela garantit que vous arrivez rapidement au coeur du matériel.
Foire aux questions
Qu'est-ce que j'obtiens en achetant ce document ?
Vous obtenez un PDF, disponible immédiatement après votre achat. Le document acheté est accessible à tout moment, n'importe où et indéfiniment via votre profil.
Garantie de remboursement : comment ça marche ?
Notre garantie de satisfaction garantit que vous trouverez toujours un document d'étude qui vous convient. Vous remplissez un formulaire et notre équipe du service client s'occupe du reste.
Auprès de qui est-ce que j'achète ce résumé ?
Stuvia est une place de marché. Alors, vous n'achetez donc pas ce document chez nous, mais auprès du vendeur NoahFran. Stuvia facilite les paiements au vendeur.
Est-ce que j'aurai un abonnement?
Non, vous n'achetez ce résumé que pour €4,99. Vous n'êtes lié à rien après votre achat.
Peut-on faire confiance à Stuvia ?
4.6 étoiles sur Google & Trustpilot (+1000 avis)
67866 résumés ont été vendus ces 30 derniers jours
Fondée en 2010, la référence pour acheter des résumés depuis déjà 14 ans