这是反模式吗？

Question

目前，我经常遇到遵循以下代码所示模式的代码。这是一种策略模式。

我不喜欢这个，感觉有点臭。它打破了实际的策略模式，并且额外的间接性令人困惑。此外，它通常会导致与示例中类似的方法，因为派生类中方法的目的与基类中的方法非常相似。另一方面，我无法用手指指向问题核心。

我是唯一一个发现这个问题的人吗？如果不是，这段代码会导致什么问题，尤其是在 SOLID 原则方面？

namespace MyTest
{
    abstract class Base
    {
        public void DoSomething()
        {
            var param = Prepare();
            DoItReally(param);
        }

        private string Prepare()
        {
            return "Hallo Welt";
        }

        protected abstract void DoItReally(string param);
    }

    class DerivedOne : Base
    {
        protected override void DoItReally(string param)
        {
            Console.WriteLine(param);
        }
    }

    class DerivedTwo : Base
    {
        protected override void DoItReally(string param)
        {
            Console.WriteLine(param.ToUpper());
        }
    }
    
    static class Program
    {
        public static void Main(string[] args)
        {
            Base strategy = new DerivedOne();
            strategy.DoSomething();
            
            strategy = new DerivedTwo();
            strategy.DoSomething();
        }
    }
}

Answer 1

如果您将代码分成两个组成部分，您应该会发现它们都非常好。

1.将一些逻辑抽象到私有方法中

public void DoSomething()
{
    var param = Prepare();
    DoItReally(param);
}

private string Prepare()
{
    return "Hallo Welt";
}

鉴于这两种方法的方法体都是固定的，并且在这种情况下非常短，我们可以争论私有方法在这里不是必需的。但这只是一个示例，如果您的初始化逻辑变得更加复杂（例如复杂的数据查询和计算），则需要将其抽象为私有方法。

2。实现抽象基方法的子类

这正是abstract 作为关键字存在的原因。

您的基类知道如何获取数据，但由于处理这些数据的方法有多种，因此存在子类，每个子类都定义了其中一个选项。您已经最大限度地提高了基类的可重用性，唯一不可重用的是每个子类的自定义处理逻辑。

---

我认为您对标记模式和反模式的关注远远超过了实际生产力。

干净的代码并非来自于寻找反模式的追求。干净的代码来自于了解您的需求，意识到代码不适合您的目的或具有不需要的副作用，然后重构代码以保持其优势，同时减少或减少其缺点。

到目前为止，您还没有发现代码本身有任何问题，也没有发现它可能会导致不良副作用的原因。您的问题本质上是疑病症，您过于急切地寻找问题，而不是简单地尝试解决具体影响您的问题。