c# - 非只读类已经存在时的只读类设计

Question

我有一个类，在构建时，从数据库中加载它的信息。该信息都是可修改的，然后开发人员可以调用SaveE（）来将其保存回数据库。
我也正在创建一个类，它将从数据库中加载，但不允许对其进行任何更新。（只读版本）我的问题是，我应该创建一个单独的类并继承，还是应该更新现有的对象以在构造函数中获取一个只读参数，还是应该完全创建一个单独的类？
现有类已经在代码中的许多地方使用。
谢谢。
更新：
首先，这里有很多很好的答案。只接受一个是很难的。谢谢大家。
看起来主要的问题是：
满足基于类名和继承结构的期望。
防止不必要的重复代码
可读和只读之间似乎有很大的区别。只读类可能不应被继承。但是一个可读的类表明它在某个时候也可能获得可写性。
经过深思熟虑，我现在想的是：

public class PersonTestClass
{
    public static void Test()
    {

        ModifiablePerson mp = new ModifiablePerson();
        mp.SetName("value");
        ReadOnlyPerson rop = new ReadOnlyPerson();
        rop.GetName();
        //ReadOnlyPerson ropFmp = (ReadOnlyPerson)mp;  // not allowed.
        ReadOnlyPerson ropFmp = (ReadOnlyPerson)(ReadablePerson)mp; 
          // above is allowed at compile time (bad), not at runtime (good).
        ReadablePerson rp = mp;
    }
}

public class ReadablePerson
{
    protected string name;
    public string GetName()
    {
        return name;
    }        
}
public sealed class ReadOnlyPerson : ReadablePerson
{
}
public class ModifiablePerson : ReadablePerson
{
    public void SetName(string value)
    {
        name = value;
    }
}

不幸的是，我还不知道如何处理属性（请参阅StriplingWarrior对属性的回答），但我感觉它将涉及受保护的关键字和 asymmetric property access modifiers。
另外，幸运的是，从数据库加载的数据不必转换为引用对象，而是简单的类型。这意味着我不必担心人们修改 ReadOnlyPerson对象的成员。
更新2：
注意，正如StriplingWarrior所建议的，向下播撒会导致问题，但这通常是真实的，因为把猴子扔到动物身上，动物回到狗身上是不好的。然而，尽管在编译时允许强制转换，但实际上在运行时是不允许的。
包装类也可以做到这一点，但我更喜欢这样做，因为它避免了必须深入复制传入对象/允许修改传入对象从而修改包装类的问题。

Answer 1

Liskov Substitution Principle说你不应该让你的只读类从你的读写类继承，因为消费类必须知道他们不能调用它的保存方法而不会得到异常。
使可写类扩展可读类将对我更有意义，只要在可读类上没有任何东西表明它的对象永远不会被持久化。例如，我不会调用基类aReadOnly[Whatever]，因为如果有一个方法将aReadOnlyPerson作为参数，那么该方法就有理由假定它们对该对象所做的任何操作都不可能对数据库产生任何影响，如果实际实例是aWriteablePerson，则不一定是这样。
更新
我最初假设在你的只读类中，你只想阻止人们调用Save方法。根据我在你对你的问题的回答中看到的情况（顺便说一句，这实际上应该是你问题的最新情况），下面是你可能想要遵循的模式：

public abstract class ReadablePerson
{

    public ReadablePerson(string name)
    {
        Name = name;
    }

    public string Name { get; protected set; }

}

public sealed class ReadOnlyPerson : ReadablePerson
{
    public ReadOnlyPerson(string name) : base(name)
    {
    }
}

public sealed class ModifiablePerson : ReadablePerson
{
    public ModifiablePerson(string name) : base(name)
    {
    }
    public new string Name { 
        get {return base.Name;}
        set {base.Name = value; }
    }
}

这确保了真正的 ReadOnlyPerson不能简单地转换为modifiableperson和modified。不过，如果你愿意相信开发人员不会以这种方式贬低论点，我更喜欢史蒂夫和奥利维尔的答案中基于接口的方法。
另一个选择是将 ReadOnlyPerson设置为 Person对象的包装类。这将需要更多的样板代码，但是当你不能改变基类时，它会派上用场。
最后一点，由于您喜欢学习liskov替换原则：通过让person类负责将自己从数据库中加载出来，您打破了单一责任原则。理想情况下，person类将具有表示包含“person”的数据的属性，并且将有一个不同的类（可能是 PersonRepository）负责从数据库中生成person或将person保存到数据库中。
更新2
回复您的评论：
虽然技术上可以回答自己的问题，但StAcExcel主要是从其他人那里得到答案。这就是为什么它不会让你接受你自己的答案，直到某个宽限期已经过去。我们鼓励你完善你的问题，并回应评论和答案，直到有人对你最初的问题提出了一个适当的解决方案。
我创建了 ReadablePerson类 abstract，因为看起来你只想创建一个只读或可写的人。尽管这两个子类都可以被认为是可读的，但是当您可以同样轻松地创建一个 new ReadablePerson()时，创建一个 new ReadOnlyPerson()又有什么意义呢？使类抽象需要用户在实例化它们时从两个子类中选择一个子类。
person repository有点像一个工厂，但“repository”一词表示您实际上是从某个数据源中提取此人的信息，而不是凭空创建此人。
在我看来，person类只是一个poco，没有逻辑：只是属性。存储库将负责构建person对象。而不是说：

// This is what I think you had in mind originally
var p = new Person(personId);

…允许person对象进入数据库来填充它的各种属性，您会说：

// This is a better separation of concerns
var p = _personRepository.GetById(personId);

然后personrepository将从数据库中获取适当的信息，并使用该数据构造人员。
如果您想调用一个没有理由更改person的方法，可以通过将其转换为只读包装器（遵循.NET库使用 ReadonlyCollection<T>类遵循的模式）来保护该person不受更改。另一方面，需要可写对象的方法可以直接被赋予 Person：

var person = _personRepository.GetById(personId);
// Prevent GetVoteCount from changing any of the person's information
int currentVoteCount = GetVoteCount(person.AsReadOnly()); 
// This is allowed to modify the person. If it does, save the changes.
if(UpdatePersonDataFromLdap(person))
{
     _personRepository.Save(person);
}

使用接口的好处是，您不会强制使用特定的类层次结构。这将给你更好的灵活性在未来。例如，假设您目前编写的方法如下：

GetVoteCount(ReadablePerson p);
UpdatePersonDataFromLdap(ReadWritePerson p);

…但在两年后，您决定改为包装器实现。突然 ReadOnlyPerson不再是 ReadablePerson，因为它是包装类，而不是基类的扩展。您是否在所有方法签名中将 ReadablePerson更改为 ReadOnlyPerson？
或者说你决定简化一些事情，把所有的类合并成一个单独的类：现在你必须改变所有的方法，只接受person对象。另一方面，如果您已经编程到接口：

GetVoteCount(IReadablePerson p);
UpdatePersonDataFromLdap(IReadWritePerson p);

…然后这些方法不关心对象层次结构的外观，只要给它们的对象实现了它们所要求的接口。您可以在任何时候更改实现层次结构，而不必更改这些方法。