design-patterns - 有没有关于这种编程的文献？

Question

在大学里，我上了一门现代物理学课，我们在其中学习了狭义相对论。我完全被不同的参照系如何实际观察到一个物体的物理特性不同而既不正确而震惊。随着时间的推移，这个概念慢慢地改变了我的编程方式，以至于现在我倾向于将类分成两个主要类别，数据对象和观察(仅限函数)对象。

为了这个简单的问题不会成为一篇详尽而冗长的帖子，我将尝试通过两个示例来解释我的意思。

首先，以我过去经常编写的这种类型的代码为例:

class Deck
{
    private Card[] cards;

    public void Shuffle()
    {
        // shuffle algorithm
    }

    // other deck related functions like draw, cut, etc...
}

我现在通常编写与以下相同的场景:

class Deck
{
    // by intention, i just mean some kind of immutable collection of cards
    private ReadonlyCollection<Card> _Cards;

    public Card[] Cards { get { return this._Cards; } }
}

interface IDeckHandler
{
    Deck Shuffle(Deck deck);
    // other deck related functions like draw, cut, etc..
}

class Dealer : IDeckHandler
{
    // IDeckHandler implementation
}

Deck不再负责实现可以对其起作用的功能。或者为了符合术语，套牌只是一组值(value)观，观察它的方式是观察者的责任。自然地，可以有许多观察者以不同的方式执行操作。

对于第二个示例，我将使用一些我试图解释这一点的人以便更容易相处。以我们在彩色纸上用彩色字母拼出一个单词的情况为例。我们有一个代理人负责阅读纸上的文字。现在假设代理是某种类型的色盲。从纸上发出的图像是相同的，但感知可能不同。观察者对对象没有深入的了解，也无法修改它，只能对它做出解释。

正如我所说，这个概念插入了我的许多开发决策。回到问题，这是一种已发布的编程类型吗？如果是这样，您能否指出一些关于它的文献 ?我遇到了一些常见和不常见的场景，它们很难做出决定，当然还有一些我还没有想到或遇到过的事情，这些事情有望在文献中得到检验。

Answer 1

在我看来，您正在以 OOP 方式实现函数式编程。
不管物理学上关于“狭义相对论”的解释如何，OOP 的整个思想基本上都是封装——你想让对象知道自己应该如何做每一件事。基本上你在这里说的是“不，只有数据和对数据起作用的函数”。如果甲板发生变化怎么办？你有一个新的经销商？你怎么知道应该创建哪个经销商来处理新牌组？

如果您考虑过“switch”语句，那么您就是在将 OOP 概念锤击到函数式编程模板中。