Sintomi e alternative a OOP abusato

Question

Ultimamente sto perdendo la fiducia in OOP. Ho già visto molte lamentele dello su abusi OOP comuni o semplicemente un semplice uso eccessivo. Io non sono significa la confusione comune tra la relazione is-a e has-a. Voglio dire roba come i problemi di ORM quando si tratta di database relazionali, l'uso eccessivo di ereditarietà da C# e anche diversi anni di ricerca a codice con la stessa falsa credenza di incapsulamento che Scott Meyers menziona nell'articolo 23 di Effective C++

Sono interessato a saperne di più su questo e sul software OOP schemi che possono risolvere alcuni problemi meglio delle loro controparti OOP . Sono convinto che là fuori ci siano molte persone che danno buoni consigli su come usare questo come un vantaggio con le lingue OOP non pure come C++.

Qualcuno conosce un buon riferimento (autore, libro, articolo) per ottenere avviato?

prega, si noti che sto cercando due cose affini ma diverse:

• comuni usi di concetti OOP (come punto 23)
• Patterns in cui OOP non è la soluzione migliore (con alternative)

Answer 1

Beh, posso consigliarti un libro Agile Principles, Patterns, and Practices in C#. Gli esempi sono in C#, naturalmente, ma l'idea del libro è universale. Non solo copre Agile ma si concentra anche su cattive pratiche e mostra negli esempi come convertire codice errato in un buon codice. Contiene anche descrizioni di molti schemi di progettazione e mostra come implementarli in un esempio semi-reale di applicazione Payroll.

Answer 2

Direi di guardare i motori di gioco. Per la maggior parte, l'OOP tende a causare una leggera diminuzione delle prestazioni e l'industria dei giochi sembra essere ossessionata dall'eliminazione di piccoli rallentamenti (e talvolta ignorando quelli di grandi dimensioni). In quanto tale, il loro codice, sebbene di solito scritto in un linguaggio che supporti OOP, finirà per utilizzare solo quegli elementi di OOP necessari per un codice pulito/facilità di manutenzione che bilancia anche le prestazioni.

EDIT:

Detto questo, non so se mi piacerebbe molto andare a vedere Unreal. Fanno alcune cose strane per rendere la pipeline dei contenuti più semplice per gli sviluppatori ... fa il loro codice ... beh, guarda se vuoi davvero saperlo.

Answer 3

Questo deve essere fatto ma se si vuole veramente allontanarsi da OOP o almeno dare un'occhiata a concetti che non sono OOP ma sono usati con grande efficacia: Learn you a Haskell. Prova un nuovo paradigma di programmazione e poi inizia a vedere dove è possibile applicare gran parte dei concetti ai linguaggi OOP. Questo indirizza il tuo secondo proiettile, non in modo diretto, ma credimi, ti aiuterà più di quanto tu possa pensare.

Answer 4

È un po 'strano che tu citi C#. Ha molto parole chiave potenti per tenere sotto controllo la solita eredità ereditaria. La prima dovrebbe essere la interna parola chiave. La nozione di restrizione della visibilità a un modulo . Questo concetto è completamente assente in C++, il modello di build non lo supporta. Altrimenti un concetto grandioso: "Mi fido solo dei membri del mio team per farlo bene". Certo che lo fai.

Quindi c'è lo slammer, sealed keyword. Straordinario potente, "il dollaro si ferma qui, non scherzare con me". Utilizzato con precisione chirurgica nel framework .NET, non ho mai trovato un caso in cui sigillato sia stato utilizzato in modo inappropriato. Manca anche in C++, ma con modi oscuri per farlo funzionare.

Ma sì, il modello di oggetto WPF è piuttosto pesante. Ereditare 6 livelli in profondità e usare backdoor come una proprietà di dipendenza è offensivo. L'ereditarietà è dura, andiamo a fare shopping.

Answer 5

Un uso eccessivo comune sta forzando OOP in programmi/script che richiedono un certo input, lo trasformano in output, quindi escono (e non ricevono input da nessun'altra parte durante il processo). La via procedurale è molto più pulita in questi casi.

Un tipico esempio di questo è la forzatura di OOP negli script PHP.