正在派生类中分配受保护的属性

本文关键字：受保护 属性 分配 派生 | 更新日期: 2023-09-27 18:29:17

我已经有一段时间没有这样做了，我需要弄清楚这是否是最好的OO方法。在derived类中的base类中分配（设置）受保护的属性时遇到问题。我有一个解决方案，但我想知道这是最好的design pattern，还是有更好的方法？

我的基本类

public abstract class EmailBase
{
   protected string Subject { get; set; }
   protected string To { get; set; }
   protected string From { get; set; }
   protected virtual void Send()
   {
       using (MailMessage mail = new MailMessage())
       { 
            // Ok send message here...
       }
   }

}

我有两个不同的电子邮件模板需要发送，所以我认为有两个派生类是个好主意，但我会为手头的问题发布一个派生类的代码。

public class DerivedOne: EmailBase
{
    private const string emailTemplate = "some static text for the body...";
    public DerivedOne()
    {
    }
    // This is how I want to set the base class properties, 
    // but it feels I am just duplicating properties... 
    public string To
    {
        set
        {
            base.To = value;
        }
    }

在控制器中。。。

  // A send email button was pressed by the user
  private bool SendEmail(Model)
  {
        DerivedOne eMail = new DerivedOne()
        {
            To = Model.To;
        };
  }

我倾向于不通过派生构造函数发送属性，因为我认为设置属性往往更干净。然而，我知道在派生构造函数中，您可以设置基本属性: base()

这就是为什么我问，在派生类中创建相同的属性以便控制器可以看到它，我错了吗？（因为受保护的属性当然不能在继承之外看到）

正在派生类中分配受保护的属性

是的，我认为你的疑虑是对的。我们应该尽可能避免重复，并充分利用OOP的力量。

此外，通过使类不可变并通过构造函数提供依赖关系，可以避免很多问题。如果类需要依赖项保持一致，则应通过构造函数提供此依赖项。这样做可以保证您自己（和其他程序员）在不提供这种依赖关系的情况下无法创建类的实例。例如，在您的情况下，我认为如果不提供To信息，您就无法发送电子邮件，因此最好通过构造函数提供To。同样的推理也可以应用于其他依赖关系。

此外，在派生类中分配受保护的属性本身可能是一个问题，并可能导致违反Liskov替换、打开-关闭和其他SOLID原则。但是，当然，有时它可能是有用的，而且没有不这样做的一般规则。

相关文章：