Cosa faresti se il tuo cliente ti chiedesse di non usare la programmazione orientata agli oggetti?

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

Hai detto che il client usava programmare in un linguaggio funzionale, forse ha una ragione per cui ti chiede di scrivere il codice in uno stile funzionale. Dovresti chiedergli perché .

Forse intende mantenere il codice e mantenerlo da solo più tardi.

Inoltre, non penso che le due scelte siano o faccia OO-style o scrivi codice crappy come hai detto tu. Sicuramente scrivere codice funzionale in un esempio come questo potrebbe essere più difficile, specialmente se hai solo esperienza in linguaggi object oriented, ma se il client è disposto ad aspettare un po 'più a lungo per essere aggiornato con lo stile funzionale, allora non lo farebbe. t male a chiederglielo.

Gli chiederei perché vuole che il codice sia in uno stile funzionale e se il tempo non è tanto un problema, vorrei chiedere qualche giorno in più per essere aggiornato con la programmazione funzionale. (evviva per essere pagato per imparare!)

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

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

Vedi l'articolo di Wikipedia su di esso per lo schtick completo, ma in breve ...

In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. It emphasizes the application of functions, in contrast to the imperative programming style, which emphasizes changes in state.

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

Se lo sfondo è in OO, allora posso vedere come vuoi che tutte le tue formiche siano oggetti. D'altra parte, se stai simulando una formica con milioni di formiche, l'OO e il passaggio dei 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.)

Programma di programmazione funzionale Python

Spiega al tuo cliente che se vuole una programmazione funzionale, dovrebbe assumere qualcuno specializzato in questo. La programmazione funzionale è molto diversa da OOP e ti sbagli se pensi di poterla facilmente raccogliere 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. Nel tuo esempio, immagino che una "Ant" possa essere modellata bene come un tipo di dati astratto, che può essere implementato direttamente usando classi e oggetti. Le transizioni tra "stati di formiche" possono essere modellate in modo naturale utilizzando le funzioni, che ti porteranno ad un approccio funzionale fino a quando la tua classe "Ant" è di tipo immutabile.

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

link

link

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

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

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

2. Non camminare come gli altri ti dicono di camminare se non credi che dovresti camminare in quella direzione. Pertanto, se non credi che la programmazione funzionale sia idonea, non pensare di fallire o intraprendere un progetto senza entusiasmo.

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

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

5. Se sei un esperto (rispetto al cliente), dovresti riuscire a persuaderli.

6. Per sapere veramente se il cliente ha un punto valido, è necessario acquisire maggiore esperienza con la programmazione funzionale, in modo da poterlo abbattere con sicurezza o rendersi conto che la tua preferenza verso OO è dovuta 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 inserire tutto questo nelle stime del progetto in modo da poter godere della curva di apprendimento mentre vieni pagato.

Prima di preoccuparti ulteriormente, farei in modo che entrambi stiate parlando della stessa cosa. Potresti chiedergli quando il software è orientato agli oggetti per lui. Sine ha detto che non è la sua principale esperienza in sé, 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 di "dati con le funzioni che operano su di essa").

Would you try to persuade your client that using object-oriented programming is much cleaner?

Penso che tu debba istruirti 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 coder orientato agli oggetti sa come fare un buon lavoro usando un metodo 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 accettabile FP / dichiarativa.)

Quasi non puoi mai, ripeto, non puoi quasi avere una buona conoscenza di quando e come utilizzare l'Orientamento degli oggetti senza avere una buona comprensione della programmazione procedurale e modulare. OO è molto più di una semplice dichiarazione di classi e gerarchie di ereditarietà.

Or would you try to follow what he required and give him crappy code?

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

L'Orientamento degli oggetti è un'estensione della programmazione procedurale e modulare. Object-Orientation fornisce semplicemente strumenti che, se utilizzati 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). Questo è il tipo di problemi di complessità che, nella sua essenza, è indipendente dal paradigma. Se non riesci a gestirli senza la colla OO, è improbabile che tu possa gestirli con essa.

=========

Tornando alla tua domanda iniziale, se provare a convincere il tuo cliente. Dipende. Come ha detto Sean McMillan, se il cliente sta semplicemente tentando di gestire in modo microscopico lo sforzo di sviluppo per qualche ordine del giorno (leggi, politica dell'ufficio), si allontana. Persone che fanno progetti di sabotaggio per incolpare qualcun altro o per spingere un particolare ordine del giorno. Non vuoi essere coinvolto in questo.

OTH, potrebbero esserci altre ragioni per questo requisito. Molti negozi integrati, per il bene o il male, scelgono di mettere molti vincoli su ciò che si può fare con C ++ (senza metodi virtuali, senza eccezioni, per esempio). Alcune volte si fa in modo scottante. Altre volte, ci sono validi motivi tecnici per farlo.

Quindi devi capire perché il cliente vuole evitare il codice OO. E se puoi supporre che non ci sia un'agenda politica (nessuna bandiera rossa), allora dovresti fare la cosa professionale da fare, che è semplicemente fare il codice procedural / modular, e fare un buon lavoro.

Non c'è davvero alcuna scusa per fornire codice scadente, indipendentemente dal paradigma di programmazione. Se non puoi produrre un codice accettabile con un paradigma, non puoi certamente produrre codice accettabile in generale.

Stai mescolando le strutture dei dati e la programmazione orientata agli oggetti (una confusione comune in questo mondo infestato dall'OO)

Se tutto ciò che devi fare è "tracciare gli attributi dei dati" in una struttura dati e modificarli, quasi tutte le lingue fatte dopo gli anni 70 avranno un buon supporto per questo, OO o no.

Le cose che sono più facili da fare in OO sono in poche parole

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

Se non hai bisogno urgente di uno di questi, in pratica qualsiasi paradigma di programmazione dovrebbe risolvere questo problema senza troppi problemi.

my client said that since he has a background in functional programming he would like the simulation to be made using functional programming.

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

Qui ci sono due possibilità:

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

2. Il tuo cliente sta cercando di controllare lo sviluppo a causa di alcuni ordini del giorno. Questa è una borsa piena di pazzi con cui non vuoi avere niente a che fare. Se si sta veramente fornendo un software "chiavi in mano", il cliente non dovrebbe preoccuparsi se è fatto di criceti che corrono su ruote, a patto che svolga il lavoro in modo affidabile. Permettervi di essere microgestiti in questo modo è solo chiedere dolore.

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

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

In primo luogo - il compito stesso è di natura "accademica" (simula un aspetto del comportamento delle formiche).

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

Se è così, è meglio fare ciò che ti è richiesto: sarà un'esperienza di apprendimento piuttosto piacevole e se riuscirai a farlo, imparerai molto nel processo ...

Se questo non è il caso, dovresti davvero chiedere a te stesso e / o al cliente il ragionamento sull'assegnazione. Se il ragionamento è solido, fallo - imparerai e sarai migliore come programmatore per l'esperienza. Chissà, potresti persino imparare a gradire lo stile funzionale su OO.

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

Potresti provare a implementare i requisiti in linguaggio / stile funzionale o potresti rifiutare cortesemente l'offerta se senti qualcosa di strano.

La cosa principale è che, una volta compresa la motivazione alla base dei requisiti, la giusta linea d'azione diventa evidente.

EDIT: Dopo aver preso uno sguardo diagonale al PDF di riferimento, gli algoritmi descritti in questo articolo sembrano sicuramente adatti per lo stile funzionale piuttosto che per OO

Ci sono molti aspetti positivi nella loro 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. Questo è il motivo per cui chiedono la programmazione funzionale. Quindi la tua organizzazione commerciale 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 segnali allarmanti:

1. Non sembra che tu sia preparato a implementarlo nella programmazione funzionale. Sei già un po 'obsoleto nelle tue capacità e non puoi tenere il passo con le modifiche.
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 finché non puoi farlo correttamente.

In secondo luogo 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 AI Challenge che modella alcuni dei comportamenti descritti nella domanda qui link e poi dai un'occhiata alla varietà di antipasti pacchetti - link la maggior parte 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 il codice è organizzato, ma il linguaggio stesso. Quando è alta la concorrenza, il linguaggio funzionale Erlang è in uso e ha un vantaggio molto elevato, ad es. Java (viene utilizzato ad esempio dalla chat di Facebook). La soluzione OOP potrebbe semplicemente fallire a causa di problemi di prestazioni.

Il cliente qui è un'università, quindi il linguaggio non è solo un problema di prestazioni / configurazione, il codice potrebbe essere utilizzato anche per il lavoro didattico con gli studenti o per la propria ricerca. Quindi il cliente 'persuasivo' di scegliere un altro paradigma è a mio avviso non applicabile qui. Questo o puoi affrontare il compito o non puoi (e quindi non dovresti prendere quel progetto).

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

Per me, farei un tentativo di persuadere se avesse senso (nuovo progetto), ma ho anche un client con una VB6 app vecchia di 10 anni che eseguo gli aggiornamenti occasionalmente ... per non convincerli a

"Esamina Cross" il tuo cliente un po '(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 ciò che vogliono e prendi i tuoi soldi. Se non sei qualificato, diglielo e lascia che decidano cosa fare.

Else:     ciao-coda fuori là!

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

Questa funzione è funzionale purché non legga / scriva nulla al di fuori della funzione. Se la funzione avesse toccato una variabile di classe, non sarebbe più "funzionale". Il vantaggio dello stile funzionale è che non ci sono più bug dallo stato di modifica o invalido. Una grande quantità di funzioni sono solo formule matematiche. Questa è la programmazione funzionale in poche parole.

BTW 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! Yay !!