Cosa faresti se il tuo client ti richiedesse di non utilizzare la programmazione orientata agli oggetti?

Sto scrivendo un programma per simulare l' attività delle formiche in una griglia (PDF). La formica può muoversi, raccogliere oggetti e lasciarli cadere.

Il problema è che mentre l'azione delle formiche e le posizioni di ciascuna formica possono essere facilmente seguite dagli attributi di classe (e possiamo facilmente creare molte istanze di tali formiche) il mio cliente ha detto che dal momento che ha un background nella programmazione funzionale vorrebbe che il simulazione da effettuare utilizzando la programmazione funzionale.

Per essere chiari, le parole originali del client sono solo "nessuna classe", ma non "programmazione funzionale". Quindi presumo che non significhi programmazione funzionale e posso farlo in modo imperativo. Inoltre, non ho alcuna esperienza precedente nella programmazione funzionale.

Tuttavia, penso che sia utile concentrarsi su questa domanda in particolare su un requisito di programmazione funzionale piuttosto che semplicemente "farlo in modo imperativo".

Come gestiresti questa situazione? Proveresti a persuadere il tuo cliente che l'uso della programmazione orientata agli oggetti è molto più pulito, provi a seguire ciò di cui ha bisogno e a dargli un codice di scarsa qualità o fare qualcos'altro?

Il codice orientato agli oggetti non è per definizione più pulito, e al contrario il codice non OO non è per definizione scadente. Mentre sembra esserci una mappatura orientata agli oggetti piuttosto ovvia a questo particolare problema, suggerirei comunque di provare l'approccio di programmazione funzionale. Fai del tuo meglio, prova a risolvere il problema nel miglior stile di programmazione funzionale che puoi raccogliere e potresti semplicemente imparare qualcosa che non ti aspettavi.

Dici che il client era solito programmare in un linguaggio funzionale, forse ha una ragione per cui ti richiede di scrivere il codice in uno stile funzionale. Dovresti chiedergli perché .

Forse intende conservare il codice e mantenerlo lui stesso in seguito.

Inoltre, non penso che le due scelte siano o in stile OO o scrivere codice schifoso come hai menzionato. Sicuramente scrivere un codice funzionale in un esempio come questo potrebbe essere più difficile, specialmente se si ha esperienza solo in linguaggi orientati agli oggetti, ma se il cliente è disposto ad aspettare un po 'di più per mettersi al passo con lo stile funzionale, allora non lo farebbe' mi fa male chiederglielo.

Gli chiederei perché vuole il codice in stile funzionale e se il tempo non è un grosso problema, chiederei qualche giorno in più per essere al passo con la programmazione funzionale. (evviva per essere pagato per imparare!)

Se tutto il resto fallisce, spiega che ci vorrebbe molto meno tempo per farlo in uno stile OO.

Sei consapevole che la programmazione funzionale non significa semplicemente "programmazione senza classi"?

Vedi l'articolo di Wikipedia a riguardo per l'intero schtick, ma in breve ...

Nell'informatica, la programmazione funzionale è un paradigma di programmazione che considera il calcolo come la valutazione di funzioni matematiche ed evita dati di stato e mutabili. Sottolinea l'applicazione di funzioni, in contrasto con lo stile di programmazione imperativo, che enfatizza i cambiamenti di stato.

La programmazione funzionale è un paradigma di programmazione, proprio come OO è un paradigma di programmazione.

Se il tuo background è in OO, allora posso vedere come vorresti che tutte le tue formiche fossero oggetti. D'altra parte, se stai simulando una fattoria di formiche con milioni di formiche, OO e il passaggio di messaggi potrebbero diventare inefficienti.

Fortunatamente per te, Python ha strumenti eccellenti per la programmazione funzionale (il più importante è che le funzioni sono oggetti di prima classe).

HOWTO sulla programmazione funzionale di Python

Spiega al tuo cliente che se desidera una programmazione funzionale, dovrebbe assumere qualcuno specializzato in questo. La programmazione funzionale è molto diversa da OOP e ti sbaglierai se pensi di poterlo raccogliere facilmente e fornire una soluzione complessa di alta qualità.

C'è un malinteso comune sul fatto che "OO" sia completamente contrario a "funzionale". Queste cose possono andare di pari passo molto bene. Nel tuo esempio, immagino che una "formica" possa essere modellata bene come un tipo di dati astratto, che può essere implementato direttamente usando classi e oggetti. Le transizioni tra "stati di formica" possono essere modellate naturalmente usando le funzioni, che ti condurranno ad un approccio funzionale nella misura in cui la tua classe "formica" è un tipo immutabile.

E sii consapevole che gli "oggetti" possono essere scambiati dal concetto funzionale di chiusura, poiché gli oggetti sono le chiusure del povero sono gli oggetti del povero sono il ... ;-):

https://stackoverflow.com/questions/2497801/closures-are-poor-mans-objects-and-vice-versa-what-does-this-mean

https://stackoverflow.com/questions/501023/closures-and-objects

Dopo averne parlato con il cliente, se lo vuole ancora a modo suo, fai un lavoro professionale o, se non puoi, non prendi il contratto o non riesci a trovare un modo per uscirne.

Produrre "codice scadente" solo perché non sei d'accordo sarebbe altamente poco professionale.

1. Perché tutti presumiamo che il cliente conosca la differenza tra programmazione funzionale e imperativa? Molte persone non conoscono i nomi o i dettagli dei paradigmi di programmazione non OO e scambieranno prontamente termini come "procedurale" "imperativo" e "funzionale".

2. Non camminare come gli altri ti dicono di camminare se non credi che dovresti camminare in quel modo. Pertanto, se non ritieni che la programmazione funzionale sia adatta, non prepararti a fallire o ad affrontare un progetto con il cuore.

3. Se il client scrive la specifica, implementa la specifica, altrimenti scrivi la specifica e implementa la specifica.

4. La migliore strategia per influenzare le decisioni dei clienti è rendere l'opzione indesiderabile significativamente più costosa. Funziona sempre.

5. Se sei l'esperto (rispetto al cliente), dovresti essere in grado di convincerli.

6. Per sapere davvero se il cliente ha un punto valido, è necessario acquisire maggiore esperienza con la programmazione funzionale, in modo da poterlo abbattere con fiducia o rendersi conto che il tuo orientamento verso OO è dovuto alla tua inesperienza.

7. Perché non farlo in entrambi i modi, quindi lasciare che il client veda entrambe le implementazioni e decida quale è più facile da mantenere. Basta considerare tutto ciò nelle stime del progetto in modo da poter godere della curva di apprendimento mentre si viene pagati.

Prima di preoccuparmi ulteriormente, mi assicurerei che entrambi parliate della stessa cosa. Potresti chiedergli quando il software è "orientato agli oggetti" per lui. Sine ha detto che non è la sua competenza principale, può darsi che abbia qualche idea distorta.

Ad esempio, molte persone potrebbero prendere in considerazione

class C {
public:
  C();
  void f( int );
  void g();
};

essere un approccio classico orientato agli oggetti, ma

struct C;
void construct( C ** );
void f( C *obj, int arg);
void g( C *obj );

no (anche se entrambi sono ugualmente orientati agli oggetti per quanto riguarda la classica definizione "dati insieme alle funzioni che operano su di esso").

Proveresti a convincere il tuo cliente che l'uso della programmazione orientata agli oggetti è molto più pulito?

Penso che devi educare te stesso di più sui paradigmi di programmazione. Il codice programmato orientato agli oggetti non è necessariamente più pulito e, di fatto, non è universalmente applicabile. Inoltre, un buon programmatore orientato agli oggetti sa come fare un buon lavoro usando un procedurale / modulare (con paradigmi funzionali e dichiarativi, è un po 'più difficile, ma non dovrebbe essere eccessivamente difficile per un buon programmatore arrivare - tramite lettura e deduzione - a una soluzione FP / dichiarativa accettabile.)

Quasi mai, lo ripeto, non puoi quasi capire bene quando e come usare l'Orientamento agli oggetti senza avere una buona conoscenza della programmazione procedurale e modulare. OO è molto più di una semplice dichiarazione di classi e gerarchie ereditarie.

O proveresti a seguire ciò che gli ha richiesto e dargli un codice scadente?

Se non riesci a scrivere un buon codice in modo procedurale, dubito che tu possa scrivere un buon codice in modo orientato agli oggetti. Periodo. Non sto cercando di giudicare qui, ma questo deve essere affermato.

L'orientamento agli oggetti è un'estensione della programmazione procedurale e modulare. L'orientamento agli oggetti offre semplicemente strumenti che, se usati in modo appropriato, offrono meccanismi migliori con cui affrontare i problemi di incapsulamento, accoppiamento, coesione e riutilizzo / estensibilità del codice.

Ma tutti questi problemi non sono inerenti e unici a OO. Esistono nel codice procedurale / modulare (e in altri paradigmi per quella materia). Questo è il tipo di problemi di complessità che, al suo centro, è indipendente dal paradigma. Se non puoi gestirli senza colla OO, è improbabile che tu possa gestirli con esso.

=========

Tornando alla tua domanda originale, se provare a persuadere il tuo cliente. Dipende. Come ha detto il poster Sean McMillan, se il cliente sta semplicemente cercando di gestire in modo microscopico lo sforzo di sviluppo di alcuni programmi (leggi, politica dell'ufficio), vai via. Le persone che fanno questo sabotaggio progettano di incolpare qualcun altro o di promuovere un'agenda particolare. Non vuoi essere coinvolto in questo.

OTH, potrebbero esserci altri motivi per tale requisito. Molti negozi incorporati, nel bene o nel male, scelgono di porre molti vincoli su ciò che si può fare con il C ++ (nessun metodo virtuale, nessuna eccezione, per esempio.) Alcune volte viene fatto in modo strabiliante. Altre volte, ci sono validi motivi tecnici per farlo.

Quindi devi capire perché il client vuole evitare il codice OO. E se puoi supporre che non esiste un'agenda politica (senza bandiere rosse), allora dovresti fare la cosa professionale da fare, che è semplicemente fare il codice proceduralmente / modulare e fare un buon lavoro.

Non ci sono davvero scuse per fornire codice scadente, indipendentemente dal paradigma di programmazione. Se non puoi produrre un codice accettabile con un solo paradigma, sicuramente non puoi produrre un codice accettabile in generale.

Stai mescolando strutture di dati e programmazione orientata agli oggetti (una confusione comune in questo mondo infestato da OO)

Se tutto ciò che devi fare è "tracciare gli attributi dei dati" in una struttura di dati e modificarli, quasi ogni lingua creata dopo gli anni '70 avrà un buon supporto, OO o no.

Le cose che sono più facili da fare in OO sono all'incirca

• Eredità basata sulla classe (è facile creare una nuova classe che finge di essere una vecchia)
• Polimorfismo di classe (in seguito è facile aggiungere nuovi tipi di formica alla simulazione)

Se non hai un bisogno urgente di uno di questi, in pratica qualsiasi paradigma di programmazione dovrebbe risolverlo senza troppi problemi.

il mio cliente ha detto che, poiché ha una preparazione nella programmazione funzionale, vorrebbe che la simulazione fosse effettuata usando la programmazione funzionale.

(Questo è un altro esempio di un problema sociale che viene scambiato per un problema tecnico / di progettazione.)

Ci sono due possibilità qui:

1. Il tuo cliente si aspetta di essere in grado di prendere il codice che hai scritto e di accettarlo o di mantenerlo da solo dopo aver finito di scriverlo. Se è così, dovresti sapere molto di più sullo "stile della casa" - funzionale vs OO è solo la punta dell'iceberg. Dovrai limitarti a uno stile di programmazione comprensibile per il tuo cliente, oppure dovrai educare il tuo cliente negli stili che preferisci. (Una volta, mi è stato chiesto di creare un'app Web con CGI, senza utilizzare il modello o le librerie perché il client potrebbe voler apportare modifiche.)

2. Il tuo cliente sta cercando di controllare lo sviluppo a causa di alcuni programmi. Questa è una borsa piena di pazzi con cui non vuoi avere niente a che fare. Se stai davvero fornendo un software "chiavi in ​​mano", al cliente non dovrebbe importare se è fatto di criceti che girano su ruote, purché faccia il lavoro in modo affidabile. Permettersi di essere micromanaged in questo modo è solo chiedere dolore.

Sta a te decidere in quale situazione ti trovi e agire di conseguenza.

Umm ... sono l'unico qui a pensare "questo è ovviamente un lavoro di prova / incarico"? .

In primo luogo, l'incarico stesso è di tipo "accademico" in natura (simula un aspetto del comportamento delle formiche).

In secondo luogo, una richiesta per implementare requisiti usando (o evitando) un paradigma di programmazione molto specifico ha un odore del "cliente" che può leggere il codice e fare tali affermazioni.

Se questo è il caso, farai meglio a fare ciò che è richiesto da te: sarà un'esperienza di apprendimento piuttosto piacevole e se puoi farlo, imparerai molto nel processo ...

In caso contrario, dovresti effettivamente chiedere a te stesso e / o al cliente il ragionamento sull'incarico. Se il ragionamento è solido, allora fallo - imparerai e sarai migliore come programmatore per l'esperienza. Chissà, potresti persino imparare ad apprezzare lo stile funzionale su OO.

Se la spiegazione è carente, tutte le scommesse sono disattivate. Non posso consigliarti cosa fare.

Potresti voler provare indipendentemente dall'implementazione dei requisiti nel linguaggio / stile funzionale o potresti rifiutare educatamente l'offerta se ritieni che qualcosa di sospetto.

La cosa principale è che, una volta comprese le motivazioni alla base dei requisiti, diventa evidente il giusto modo di agire.

EDIT: Dopo aver dato uno sguardo diagonale al PDF di riferimento, gli algoritmi descritti lì sembrano sicuramente adattarsi allo stile funzionale piuttosto che a OO

Esistono diversi aspetti positivi nella richiesta di utilizzare la programmazione funzionale:

1. Hai un cliente, è sempre un buon segno
2. Il cliente si aspetta che tu sia molto bravo in quello che stai facendo. Ecco perché chiedono la programmazione funzionale. Quindi la tua organizzazione di vendita sta facendo un buon lavoro o stai chiedendo un prezzo molto alto per i tuoi servizi.
3. L'organizzazione del cliente ha alcune persone che sanno che la programmazione funzionale è una buona cosa e sarà grande in futuro

Ma ci sono anche alcuni segni allarmanti:

1. Non sembra che tu sia disposto a implementarlo nella programmazione funzionale. Sei già leggermente obsoleto nelle tue capacità e non riesci a tenere il passo con i cambiamenti.
2. Oppure il cliente si aspetta che tu sia un programmatore migliore di quello che realmente sei. Ciò significa che potresti dover eseguire il downgrade dei loro requisiti fino a quando non puoi farlo correttamente.

Distaccare le risposte di cui sopra che forse OO non è la soluzione migliore, nel qual caso il cliente potrebbe avere un punto.

Dai un'occhiata alla sfida AI che modella alcuni dei comportamenti dettagliati nella domanda qui http://aichallenge.org e poi dai un'occhiata alla varietà di pacchetti di partenza - http://aichallenge.org/starter_packages.php/ most sono lingue che non inserirò nel paradigma OO.

Non hai scritto nulla sul linguaggio di programmazione, che è probabilmente la cosa più importante lì. La differenza tra OOP e programmazione funzionale non è solo il modo in cui è organizzato il codice, ma il linguaggio stesso. In questo caso, il linguaggio funzionale Erlang è in uso e presenta un vantaggio molto elevato rispetto ad esempio a Java (viene utilizzato ad esempio dalla chat di Facebook). La soluzione OOP potrebbe semplicemente fallire a causa di problemi di prestazioni.

Il cliente qui è l'università, quindi il linguaggio non è solo un problema di prestazioni / configurazione, ma il codice può essere utilizzato anche per il lavoro didattico con gli studenti o per la propria ricerca. Quindi, secondo me, il cliente "persuasivo" di scegliere un altro paradigma non è applicabile qui. Questo è o puoi occuparti dell'attività o no (e quindi, non dovresti prendere quel progetto).

Il cliente dice "salta", la tua risposta è: __ _ ?

Per quanto mi riguarda, farei un tentativo di persuadere se avesse senso (nuovo progetto), ma ho anche un client con un'app VB6 di 10 anni per la quale faccio aggiornamenti di tanto in tanto ... non li convincerò a

'Cross Examine' un po 'il tuo cliente (in modo non conflittuale):

Il cliente conosce davvero la differenza tra OOP e programmazione funzionale? Le preoccupazioni / richieste del cliente sono legittime?

Se "Sì": se sei qualificato, fai quello che vuole e prendi i tuoi soldi. Se non sei qualificato, diglielo e lascia che decidano cosa fare.

Altrimenti: salutalo fuori di lì!

double dist(Point p1, Point p2) 
{
  //return distance
}

Questa funzione è funzionale fintanto che non legge / scrive nulla al di fuori della funzione. Se la funzione toccasse una variabile di classe non sarebbe più "funzionale". Il vantaggio dello stile funzionale è che non ci sono più bug che cambiano o non sono validi. Molte funzioni sono solo formule matematiche. Questa è la programmazione funzionale in breve.

A proposito, puoi combinare uno stile funzionale all'interno di un design basato su oggetti o orientato. Ad esempio le due variabili "Punto" sono oggetti con stato. E la funzione è ancora funzionale! Sìì!!