Due classi che si comportano in modo identico sono semanticamente differenti

Il mio C # è arrugginito, spero di non aver ignorato i limiti linguistici.

implementerei UpScript e DownScript come interfacce con gli stessi membri:

public interface IUpScript {
    public long Version { get; private set; }
    public string Name { get; private set; }
    public string Content { get; private set; }
}
// ...
public interface IDownScript {
    public long Version { get; private set; }
    public string Name { get; private set; }
    public string Content { get; private set; }
}

Questo approccio tenta di fornire il codice minimo necessario per creare una distinzione tra su e giù, niente di più. Pensieri:

• Le classi che implementano un'interfaccia avranno le proprietà comuni che hai definito come negli altri tuoi approcci, ma non ereditano dettagli di implementazione come un costruttore.
• Le tue classi di implementazione sarebbero libere di estendere altre classi se necessario.
• Sembra che non sia necessario supportare più implementazioni di script su e giù, ma non avresti problemi a farlo.

Penso che la tua soluzione con la classe base astratta stia bene. È una programmazione OO comune: si dispone di un tipo astratto con due diverse implementazioni. Non dovresti preoccuparti della duplicazione della creazione di due classi. In un linguaggio come Scala che fornisce alcune funzioni sintattiche, è possibile definire tali casi in un modo più conciso, ma per C # e Java non penso che si possa fare molto meglio. In Scala puoi usare case classes per esempio:

trait Script(long version, string name, content)
case class UpScript(long version, string name, content) extends Script
case class DownScript(long version, string name, content) extends Script

Per quanto riguarda l'istanziazione, nel tuo caso attuale va bene dato che al momento hai solo due sottoclassi. Puoi pensare di avere fabbriche e poi quando leggi i file up, usa UpFactory, ad esempio, e viceversa. In questo modo il codice cliente non sarà vincolato all'attuazione effettiva.

La soluzione con la classe base astratta è la strada da percorrere.

Per ridurre la duplicazione nel codice che determina quali script elaborare, puoi introdurre una classe factory / metodo che crea un'istanza UpScript o DownScript in base a un parametro (lo stesso parametro che determina se gli script con il suffisso "_up" o "_down" dovrebbe essere usato).

Se l'ordine di esecuzione degli script dipende dalla direzione, è possibile aggiungere un metodo di confronto a Script (con implementazioni in UpScript e DownScript ) per ordinare correttamente le istanze Script .
L'esecuzione degli script diventa quindi facile come scorrere su una raccolta ordinata senza dover sapere se si sta eseguendo l'aggiornamento o il downgrade.

How do I reduce the duplication without losing the expressiveness of having different classes?

Considerando gli scenari in cui il tuo programma interagisce con gli script, come indicato nella tua descrizione di primo livello:

1. Get a list of scripts off the filesystem
2. Execute the appropriate migrations on the database

La prima decisione riguarda gli script o da applicare durante la migrazione:

public interface IScriptSource
{
    IEnumerable<IScript> ReadUpScripts();

    IEnumerable<IScript> ReadDownScripts();
}

La seconda decisione è quella di eseguire ogni script, che sposterà il database in avanti o all'indietro nel tempo:

public interface IScript
{
    void Execute();
}

Questo ci offre una buona base per affrontare la tua preoccupazione principale:

The problem that I have here is a few parts of code that are dealing with both either UpScript or DownScript instances look almost identical.

Con queste astrazioni di alto livello, possiamo modellare le implementazioni attorno ai dettagli condivisi:

public abstract class Script : IScript
{
    protected Script(long version, string name, string content)
    {
        Version = version;
        Name = name;
        Content = content;
    }

    protected long Version { get; private set; }
    protected string Name { get; private set; }
    protected string Content { get; private set; }

    public virtual void Execute()
    {
        SomethingShared();

        MoveInDirection();

        SomethingElseShared();
    }

    protected abstract void MoveInDirection();
}

Quindi differenzia le specifiche di ogni tipo:

public sealed class UpScript : Script
{
    public UpScript(long version, string name, string content)
        : base(version, name, content)
    {}

    protected override void MoveInDirection()
    {
        // Up-specific
    }
}

public sealed class DownScript : Script
{
    public DownScript(long version, string name, string content)
        : base(version, name, content)
    {}

    protected override void MoveInDirection()
    {
        // Down-specific
    }

    protected override SomethingElseShared()
    {
        base.SomethingElseShared();

        // Down-specific
    }
}

Ciò consentirà di consolidare il codice di diffusione accoppiandolo direttamente ai dati.

Riceve anche il timbro di approvazione Liskov a causa del IScriptSource che nasconde i tipi di calcestruzzo.