La decomposizione funzionale è davvero antipattern?

9

Mentre leggevo I peggiori anti-pattern che hai trovato , ho cliccato sul link in < a href="https://softwareengineering.stackexchange.com/questions/43807/the-worst-anti-patterns-you-have-came-across/43816#43816"> questo post per sbarcare sul web sito su anti-pattern.

E la pagina link mi ha fatto riflettere.

Quanto è pessimo questo anti-modello, ed è un anti-modello? Perché, sebbene io stia facendo la programmazione OOP al giorno d'oggi, provo ancora una certa riluttanza nei confronti del puro OOP - tutti i linguaggi come Java, e anche le pratiche di progettazione che portano. E immagino, ho ancora alcuni tratti della programmazione funzionale mentre scrivo il codice.

E questo ha sollevato una domanda, sto sbagliando attenendomi allo stile OOP + funzionale, oppure è comune nell'industria e non è poi così male.

Quello che so per esperienza, è che lo stile OOP + non è completamente compatibile con gli sviluppatori OOP puri. Ma allo stesso tempo, mentre gli sviluppatori OOP hanno problemi con OOP + Sviluppo funzionale, la controargomentazione è che le soluzioni OOP sono spesso troppo ingegnerizzate e troppo difficili da usare, e dalla mia esperienza, non erano nemmeno un po 'più facili, e in realtà introdotto alcuni punti ciechi per nascondere bug MOLTO gravi.

Quindi, anche se ho avuto una discussione con il mio collega su questi argomenti, sono giunto alla conclusione che nessuno dei modi è in realtà perfetto. E ho ancora la domanda senza risposta.

Il problema OOP è stato anche rinforzato da un link da un altro post nella stessa discussione. Il link esamina il OOP in stile Java link

Quindi qual è l'atteggiamento generale verso la combinazione di programmazione funzionale con OOP? E qual è l'equilibrio che uno sviluppatore dovrebbe sforzarsi di ottenere?

    
posta Coder 26.08.2011 - 00:50
fonte

1 risposta

8

Prima di tutto, la programmazione funzionale è attualmente ciò che stanno facendo tutti i ragazzi fantastici. L'Anti-Pattern parlava davvero di programmazione procedurale (sarebbe più chiaro se la tecnica fosse chiamata "decomposizione procedurale" ma non lo fosse), e penso che lo fosse anche tu.

L'anti-pattern parlava di cattivi modi di scrivere codice procedurale in un linguaggio orientato agli oggetti, l'altra pagina parlava male era di scrivere Java - in verità non c'è un linguaggio così fantastico che tu possa fare tutto ciò che vuoi, ma impossibile scrivere codice errato.

In pratica, ho visto un po 'più di ingegneria nel codice orientato agli oggetti che procedurale, un po' meno in ingegneria e un po 'più di ingegneria.

Nel tuo caso, dipenderebbe dalle specifiche e non sono sicuro di ciò che effettivamente fai in uno stile procedurale. È corretto, chiaro, verificabile, facile da modificare, ecc.? I criteri per giudicare il codice dovrebbero essere basati su tali preoccupazioni pratiche e non sulla purezza di uno stile particolare. Sembra che nel tuo caso le persone ragionevoli e competenti possano non essere d'accordo (e farlo!) Su tali preoccupazioni e, in tal caso, probabilmente non esiste un modo oggettivo per determinare la verità della questione.

    
risposta data 26.08.2011 - 01:28
fonte