Znajomość i "znajomość" OOP to dwie różne rzeczy. Do tego dochodzą różnice w implementacji między językami, czego sam niedawno byłem ofiarą w jednym z tematów tutaj. Tak więc jak sam widzisz, nawet osoby doświadczone potrafią na czymś się "wywalić"

Nie znajomość regułek jest bowiem wyznacznikiem wiedzy o OOP, ale umiejętność jej praktycznego zastosowania w projekcie. Jak tu już wspomniano, poznanie nazewnictwa to nie jest trudne zadanie. Zrozumienie tego, który mechanizm gdzie zastosować i w jaki sposób - to jest istota OOP, którą będziesz nabywał z doświadczeniem w pisaniu projektów. Pewnych rzeczy nie przyspieszysz. Przykładowo ja na studiach miałem obiektówkę i ją klepałem oraz dość dobrze rozumiałem, czego efektem były oceny na egzaminach i kolokwiach. Problem jednak w tym, że naprawdę wszystkie zależności i sens stosowania poznałem samodzielnie pisząc kod. Tylko tak poznasz praktyczne zastosowanie tego o czym się uczysz. Podczas nauki dostajesz bowiem jasno sprecyzowane: TO jest TUTAJ, ale nikt Ci nie wyjaśni DLACZEGO. Dopiero analiza przykładu oraz kodu innych osób zapali Ci lampkę "a więc takie buty!", by po chwili znaleźć inny kod, który zaprzeczy Twoim wnioskom

Tutaj właśnie wychodzi zdolność do nauki i oddzielania ziarna od plew. Nie zawsze patrz na jedno źródło. Dopiero porównanie wielu ze specyfikacją, wzorcami, szablonami, daje Ci pogląd na to jak faktycznie to działa i że nie zawsze to co Ci ktoś proponuje jest w określonych przypadkach dobrym rozwiązaniem. Tutaj już wchodzi w grę właśnie obycie z kodem, otrzaskanie, czyli innymi słowy własne doświadczenie. A te zdobywasz sam, książki i wiedza społeczności mogą Cię jedynie na pewne rzeczy nakierować, ale nie zmuszą do wykucia.