Autovalutazione: come faccio a sapere se effettivamente ho una "buona comprensione" di OOP? [duplicare]

Suppongo di conoscere un sistema sufficientemente bene, se ...

• So quali parti di quel sistema non conosco intimamente. Ad esempio, potrei sapere che esiste qualche caratteristica oscura X, ma non saprei da che parte si usa. Qui puoi sfogliare la documentazione tutti .

• So come quel sistema confronta sfavorevolmente con i sistemi concorrenti. Io conosco il sistema abbastanza vicino da conoscerne le verruche. Conoscere più sistemi sufficientemente diversi è utile qui. Nel caso di implementazioni OOP, sarebbe interessante confrontare Java con ECMAScript, dato che sono drasticamente differenti.

Se hai una buona conoscenza di OOP, dovresti essere in grado di dare una risposta interessante ad almeno la metà di queste domande:

• Che cos'è un oggetto?
• Che cos'è una classe?
• Abbiamo bisogno di lezioni per OOP? Quali altre possibilità ci sono?
• Che cos'è un metodo? In che modo i metodi sono diversi dalle normali funzioni / procedure / subroutine? Come viene risolta una chiamata al metodo?
• Perché esiste un parametro this o self / parola chiave nei metodi? Cos'è la ricorsione aperta?
• In che modo OOP è diverso da altri paradigmi come la programmazione funzionale, procedurale o modulare?
• In che modo l'OOP è correlato ai tipi di dati astratti?
• Quali strategie per il riutilizzo del codice offre OOP?
• Come funziona l'ereditarietà?
• Che cos'è l'ereditarietà multipla e quali sono i problemi associati a questo? Quali soluzioni possibili esistono?
• Che cosa sono le classi, le classi astratte, le interfacce, i mixin e i tratti? (Si noti che la maggior parte delle implementazioni OOP offre solo alcune di queste
• Puoi elencare alcuni schemi di progettazione OOP comuni? Quali problemi risolvono? Conosci i sistemi OOP che non richiedono l'implementazione esplicita di questi modelli?
• Quali sono gli anti-pattern OOP più comuni?
• Qual è la relazione tra lo schema di comando e la programmazione funzionale?
• Qual è la relazione tra un costruttore e un metodo di produzione?
• Cos'è l'incapsulamento?
• Che cosa significa l'acronimo SOLID?
• Qual è il principio di responsabilità unica?
• Qual è il principio di apertura / chiusura?
• Qual è il Principio di sostituzione di Liskov?
• Qual è il principio di inversione della dipendenza? Come può essere raggiunto?

How can I find out if I have a "good grasp" on OOP?

Normalmente, quando guardo i webinar (e leggo post di blog e simili), cerco di vedere con quanti concetti ho a che fare. Ultimamente (nell'ultimo anno o giù di lì) tendo a capire la maggior parte di ciò che leggo. A proposito, questa è una domanda molto soggettiva.

Right now I kind of think of classes as a collection of functions with some global-ish variables accessible by all those functions.

Questa è una visione limitata. Puoi anche guardare le classi come:

• unità di incapsulamento
• espressioni di concetto (vedi "is-a" vs. "has-a")
• attori all'interno di un protocollo
• elementi costitutivi all'interno di un design globale

Cose da esaminare:

• design pattern

• UML (modella le relazioni tra gli oggetti abbastanza bene)

• virtualizzazione dei metodi e "interfaccia come contratto"

Ce ne sono di più e alcuni sono rilevanti solo in alcuni contesti (ad esempio, in C ++ puoi parlare di tipi regolari e semi-regolari)

Quando sono entrato per la prima volta nel regno della vera comprensione di JavaScript, mi sono iscritto alle newsletter, ho letto il codice per nuove librerie e framework e ho letto libri e ogni post interessante sul blog in cui mi sono imbattuto. Il mio appetito era vorace. Ma nel tempo, mentre lavoravo a progetti JavaScript - l'esperienza effettiva è essenziale - e continuavo a leggere, alla fine ho notato meno idee nuove. La mia visione del mondo JavaScript ridotta. Molto è familiare.

La mia incursione più recente è stata la programmazione funzionale. Ho usato funzioni di alto livello, composizione, curriculum, trasparenza referenziale e gran parte dei fondamenti, ma continuo a calpestare territori sconosciuti quando trovo post relativi a Monade, Functional e parti di Haskell. Quando inizi a notare che il tuo appetito è stato saziato - vale a dire, è più difficile trovare qualcosa di fresco ed eccitante - è quando hai una "buona comprensione".