Buon design per la classe con costruttori simili

Una cosa che puoi fare è sottoclasse Entity e definire costruttori specifici per ciascuno. Scommetterei che c'è un altro codice che potrebbe essere spostato nelle sottoclassi da quello principale. Se non ora, probabilmente in futuro. In entrambi i casi, hai ancora tutte le funzionalità comuni in Entity.

public class SerialEntity extends Entity{
    public SerialEntity(String serialNumber){
        this.serialNumber = serialNumber;
    }
}

public class PKEntity extends Entity{
    public PKEntity(String primaryKey){
        this.primaryKey= primaryKey;
    }
}

Forse allo stesso tempo rendere Entity astratto? Ma è leggermente fuori portata qui.

Tuttavia, se la cosa solo diversa su Entity è l'identificatore, quindi crea un'interfaccia EntityIdentifier con le implementazioni per ciascun tipo di identificatore. In questo modo Entity richiede solo un costruttore con un singolo argomento.

public class SerialIdentifier implements EntityIdentifier{
    private final String serialNumber;

    public SerialIdentifier(String serialNumber){
        this.serialNumber = serialNumber;
    }

    @Override
    public String getKey(){
        return serialNumber;
    }
}

public class Entity{
    public Entity(EntityIdentifier id){
        this.id = id;
    }
}

(Questo presuppone che tu abbia sempre bisogno solo di serialNumber xor primaryKey , però.)

Penso che l'approccio identificativo sia complementare alla creazione di tipi specifici per i valori stessi. Cioè, se la tua applicazione ha davvero bisogno di un tipo SeraialNumber , ma non ha bisogno di un tipo "chiave pimaria", allora puoi facilmente refactificare il SerialIdentifier sopra per lavorare con il nuovo tipo. Questo disaccoppia anche SerialNumber dall'essere un tipo di identificatore, se tale disaccoppiamento è necessario. La bellezza di questo è che non dovresti preoccuparti del resto della classe Entity perché funziona già contro l'interfaccia EntityIdentifier ed è indipendente da ciò che è effettivamente "id".

Personalmente, la mia soluzione a questo sarebbe di considerare il costruttore non prendere parametri e usare l'iniezione setter. Dopo tutto, se il numero di serie della metà del tempo può essere non inizializzato e metà della volta che la chiave primaria può essere non inizializzata, è ovvio che nessuno è essenziale per il funzionamento della classe. Poiché questo è il caso, dimentica la goffa ginnastica primitiva e lascia ai clienti la possibilità di specificare quali dati hanno.

Questo potrebbe rivelare il requisito che uno o l'altro sia impostato, ma ciò sembrerebbe portare a considerare due classi fuori dalla classe target piuttosto che rappresentare una sorta di struttura sindacale in stile C.

Mi piace la seconda opzione che hai dato. È sicuro e per me è più intuitivo.

Non sono sicuro che il codice qui sia C # o Java, ma se è C #, puoi prendere la seconda opzione e aggiungere un conversione implicita a string per aiutare con gli altri posti in cui serialNumber potrebbe essere usato come stringa.

public class SerialNumber
{
    private string serialNumber = null;

    public SerialNumber(string serialNumber)
    {
        this.serialNumber = serialNumber;
    }

    public static implicit operator string(SerialNumber sn)
    {
        return sn.serialNumber;
    }
}

Ovviamente, in passato gli operatori impliciti sono stati disapprovati, quindi dovresti valutare i pro e i contro.

Il numero 2 è facilmente la soluzione migliore. Ti consente di eseguire la convalida e fornisce una distinzione effettiva nel sistema di tipi per tipi distinti.