Programmazione per intenzione, profondità prima o larghezza per prima?

3

Dire che ho il seguente grafico delle dipendenze tra procedure / funzioni / metodi:

      o
    /   \
  v       e
 / \     / \
r   f   l   w

Cioè, la funzione o prima chiama la funzione v, e quindi la funzione e. La funzione v stessa prima chiama la funzione r, e quindi la funzione f. La funzione e stessa prima chiama la funzione l, quindi la funzione w.

Con Programmazione per intenzione , in quale ordine dovrebbero essere definite queste funzioni?

Primo livello: o, v, r, f, e, l, w

Prima di tutto: o, v, e, r, f, l, w

    
posta fredoverflow 25.04.2013 - 20:37
fonte

3 risposte

4

Everything old is new again. The folks who brought us the eXtreme Programming books were, among other things, promoting a set of best practices in software development. One of them, which they termed “Programming by Intention”, was not actually new, but was something that had been a very common coding technique in languages like COBOL and Smalltalk (usually called “top down” programming) years before.

(dall'introduzione di Programmazione per intenzione )

La programmazione per intenzione sembra essere una riscoperta di top down programming dove si inizia con strato superiore e scende da lì.

Questo è il modo in cui il codice è stato scritto ai tempi di Pascal e dei suoi contemporanei. Hai iniziato a scrivere la procedura principale (che si trovava alla fine del file, per necessità della definizione del linguaggio e del compilatore) e poi scrivi una procedura o una funzione, che era quindi collocata prima del codice che la chiamava.

Questo è in contrasto con il modello "bottom up design" che OO enfatizza: costruisci prima i blocchi predefiniti e poi li costruisci da lì.

Sarebbe un equivoco e un'applicazione errata della Programmazione per Intenzione usarla per porre una struttura strutturale al codice. A meno che la lingua lo definisca (a la pascal), non importa quale ordine i metodi siano dichiarati. La leggibilità (e la coerenza tra i programmatori) è la chiave.

Con gli IDE moderni, è possibile visualizzare rapidamente e facilmente il profilo del codice. Premendo F3 in eclissi si aprirà la definizione di una chiamata al metodo, indipendentemente da dove si trovi nel codice. In questa misura, l'organizzazione dei metodi non è importante. Se c'è un ordine usa la seguente linea guida:

  1. Programma all'interno dei vincoli di lingua.
  2. Programma all'interno delle convenzioni linguistiche.
  3. Programma all'interno dei vincoli di stile del team.
  4. Programma in modo coerente.

Se ordini prima dall'alto o dal basso verso l'alto o la profondità o prima il respiro o in ordine alfabetico, fallo. E rimani fedele.

    
risposta data 25.04.2013 - 22:56
fonte
2

Non so se questo è effettivamente specificato nella programmazione per intenzione, ma forse possiamo analizzare pro e contro.

In prolog, un linguaggio di programmazione di quinta generazione, puoi usare entrambe le forme di esecuzione, quindi da un punto di vista pseudocodice entrambi potrebbero essere validi.

Larghezza-Primo ha il vantaggio che può essere letto in modo top-down, se le tue funzioni variano ampiamente in astrazione con ogni livello, allora potrebbe essere possibile saltare un livello. La larghezza sarebbe la strada da percorrere.

Tuttavia, se qualcuno che legge questo deve leggere tutto o evitare di fare supposizioni su questo, allora la profondità prima sarebbe meglio. Permette di leggere il codice nello stesso modo in cui viene eseguito e rende la lettura più semplice e naturale, pensa all'esempio di uova di alligatore ; )

L'opzione migliore è avere uno strumento che permetta di ordinare tutto in modo approfondito e comprimere gli elementi interni. L'ho visto in molti editor di codice e nel codice HTML generato da FreeMind. Ciò consente al lettore di scegliere la direzione da seguire, sia in ampiezza che collassando e scrollando o prima in profondità espandendo e scorrendo.

In generale, depth-first è un'opzione molto più sicura.

    
risposta data 25.04.2013 - 21:25
fonte
1

Seguo la Regola step-down di Robert C. Martin. Nel suo libro Pulisci codice , scrive:

We want the code to read like a top-down narrative. We want every function to be followed by those at the next level of abstraction so that we can read the program, descending one level of abstraction at a time as we read down the list of functions. I call this The Step-down Rule.

Leggere il codice significa che si scende un livello di astrazione alla volta. Per il tuo esempio, la narrativa durante la lettura del codice sarebbe

  1. Per fare O, facciamo V ed E
  2. Per fare V, facciamo R e F
  3. Per fare E, facciamo L e W
  4. Ecco i dettagli di basso livello su come R è fatto
  5. Ecco i dettagli di basso livello su come F è fatto
  6. Ecco i dettagli di basso livello su come viene eseguita L
  7. Ecco i dettagli di basso livello su come W è fatto

Se il lettore vuole capire O, potrebbe essere in grado di interrompere la lettura dopo l'articolo 1, 2 o 3 sopra, a seconda del numero di dettagli di implementazione che desidera conoscere.

    
risposta data 18.10.2017 - 02:14
fonte