È sempre possibile separare più condizioni in un'istruzione IF in singole dichiarazioni?

3

Sto cercando di trovare il modo più semplice per modellare le istruzioni condizionali definite dall'utente senza ricorrere all'analisi del testo. Questo è abbastanza facile quando c'è una sola condizione nell'istruzione perché è possibile suddividerla in un operando, un operatore di confronto e un valore con cui confrontarlo. Basta memorizzare questi tre e puoi lasciare che l'utente usi le caselle a discesa per selezionare i valori e un operatore da un elenco predefinito.

In questo esempio, immagina che il testo code snippet sia una casella a discesa e il testo grassetto non sia modificabile:

IF (select value) è (select comparison operator) (enter value) quindi ...

Chiarificazione - in modo che il bit tra IF e IS sia una casella a discesa con il membro di un oggetto o il campo del database, l'operatore di confronto è una casella a discesa con opzioni come "uguale a" o "maggiore" di ", e la casella finale è una casella di testo tipizzabile in cui l'utente può immettere il valore manualmente.

Ma a volte devono testare più condizioni prima di eseguire qualsiasi azione che definiscono. Microsoft Dynamics CRM fa abbastanza bene con le loro regole di business (che è simile a quello che sto cercando di ottenere) come si può vedere here .

In semplici esempi, puoi riorganizzarlo in istruzioni nidificate if, sebbene tu possa finire per ripeterti se usi molti OR s. Non è la soluzione più bella del mondo ma alla fine della giornata funziona e non corri il rischio di permettere all'utente di digitare input mal formati. Prevedo che la complessa logica condizionale multipla sia un caso limite per questo progetto, quindi il disordine è (per lo più) giustificato.

La domanda da un milione di dollari ci sono casi in cui la logica condizionale non può essere rappresentata in questo modo?

EDIT per spiegare in che modo questa domanda non è un duplicato di questa , quella domanda non è (per quanto posso dire) chiedere la stessa cosa. Sebbene entrambe le domande riguardino la valutazione di varianti sconosciute delle espressioni booleane, sto chiedendo se la mia soluzione mi consentirà di rappresentare tutte le espressioni possibili con un metodo particolare, mentre quella domanda riguarda il test dell'unità per le espressioni booleane con molti input.

    
posta leylandski 28.10.2015 - 16:57
fonte

1 risposta

5

Le condizioni nidificate lungo le linee di ((foo or bar) and baz) sono difficili da comprendere e capisco che vuoi evitarle. In effetti, puoi evitare gli operatori logici and , or e not se permetti ai condizionali di essere annidati:

  • if (foo and bar) then action è equivalente a

    if (foo) then
      if (bar) then
        action
    
  • if (foo or bar) then action è equivalente a

    if (foo) then
      action
    otherwise
      if (bar) then
        action
    
  • if (not foo) then action è equivalente a

    if (foo) then
      nothing
    otherwise
      action
    
  • if ((foo or bar) and baz) then action è equivalente a

    if (foo) then
      if (baz) then
        action
    otherwise
      if (bar) then
        if (baz) then
          action
    

    o

    if (baz) then
      if (foo) then
        action
      otherwise
        if (bar) then
          action
    

Questo non è esattamente facile da capire, e richiede molte ripetizioni.

Potrebbe essere molto più semplice consentire a un if … then … di avere più condizioni che possono essere combinate tramite any of , all of e none of quantificatori (questi corrispondono ai quantificatori matematici ∃ esiste, ∀ per tutti, e ∄ non esiste). È facile da introdurre in un'interfaccia basata su moduli e aumenta drasticamente la potenza e l'usabilità delle regole. Tuttavia, non sono altrettanto potenti delle condizioni nidificate arbitrariamente. Questo può essere risolto introducendo variabili definite dall'utente o campi virtuali. Con le variabili, le sotto-condizioni possono essere combinate, nominate e riutilizzate.

Utilizzando questi due miglioramenti, un% condizionale% di co_de potrebbe diventare

yes/no field foo-or-bar
  is any of foo
         or bar

if all of foo-or-bar
      and baz
then
  action

dove foo, bar, baz sono condizioni atomiche arbitrarie. Ciò raggiunge la stessa espressività delle espressioni di condizione nidificate, senza richiedere agli utenti di ripetere le loro condizioni e azioni.

    
risposta data 28.10.2015 - 18:01
fonte

Leggi altre domande sui tag