Approcci per condizioni non complesse

Sarò onesto, non vedo molto male con l'esempio di codice che hai elencato, supponendo che sia solo una manciata di casi del genere. Ci sono alcuni modi in cui puoi cambiare il codice che può rendere o meno il codice risultante più leggibile o l'intento più chiaro.

Un esempio è quello di separare la clausola comune nella dichiarazione if dal resto del codice in questo modo:

if (wasCheckedBefore(entity.name)) {
    if (entity.isSomething) showSomeMessageToUser(entity.name) 
    if (entity.isSomethingElse) showSomeMessageToUser(entity.name) 
    if (entity.isSomethingSomethinElse) showSomeMessageToUser(entity.name) 
}

Un'altra opzione è di avere un parametro di tipo enum per eseguire un'istruzione switch:

if (not wasCheckedBefore(entity.name)) return

switch(entity.type) {
    case type.something:
        showSomeMessageToUser(entity.name)
    case type.somethingElse:
        showSomeMessageToUser(entity.name)
    case type.somethingSomethingElse:
        showSomeMessageToUser(entity.name)
}

O estendendo questo concetto puoi semplicemente passare il tipo nel metodo in modo che diventi veramente più corto e la complessità spostata nella funzione showSomeMessageToUser :

if (wasCheckedBefore(entity.name)) {
    showSomeMessageToUser(entity.type, entity.name)
}

La linea di fondo è che niente di tutto ciò è funzionalmente meglio dell'altro. Sta solo mescolando la logica intorno. La domanda è se uno di questi approcci rende più prevalente l'intenzione del codice. Se no, lascia dormire i cani.

Se esiste un buon termine di dominio per ciò che viene controllato, puoi convertire ogni espressione booleana in un metodo:

// This method name should explain what the boolean expression 
// means in terms of domain logic, i.e. why it is important
// to check both of these values.
private boolean someDomainConcept(entity) {
   return entity.isSomething && wasCheckedBefore(entity.name)
}

if (someDomainConcept(entity.name)) showSomeMessageToUser(entity.name);

Questo può aggiungere un po 'di valore alla documentazione nel codice, rendendo più breve l'uso delle espressioni booleane e il riutilizzo di quelle espressioni. Non direi che questo è sempre un modello valido; dipende dal tuo caso d'uso reale. A volte non esiste un nome migliore per l'espressione booleana rispetto alla somma delle sue parti.

Perché non consolidi i tuoi messaggi all'interno delle entità?

class SomethingEntity
{
    string name;
    bool isChecked;

    public string Message()
    {
        if (isChecked)
            return someMessage;
        else
            return someOtherMessage;
    }
}

Puoi quindi

showMessageToUser(anyEntity.Message());

Ci sono molti modi per scuoiare questo gatto. Probabilmente non hai bisogno di un modello software ben noto.