Nic*_*sen 19 oop design-patterns functional-programming
在大学里,我参加了一个关于现代物理学的课程,在那里我们学习了狭义相对论.我完全被不同的参考框架如何实际观察到物体的物理属性变得不同而且都不正确.随着时间的推移,这个概念慢慢地改变了我编程的方式,现在我倾向于将类分为2个主要类别,数据对象和观察(仅函数)对象.
为了这个简单的问题,我不会成为一个精心设计和冗长的帖子,我会尝试通过两个例子来解释我的意思.
首先,以我曾经常写的这种类型的代码为例:
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不再负责实现可以对其起作用的功能.或者为了使其符合术语,甲板只是一组值,观察它的方式是观察者的责任.当然,可以有许多观察者以不同的方式执行这些行动.
对于第二个例子,我将使用我尝试解释过这个问题的人可以更轻松地使用.假设我们在彩色纸上拼写了彩色字母拼写出一个单词.我们有一个代理人,负责阅读报纸上的文字.现在假设代理是某种类型的色盲.从纸张发出的图像是相同的,但感知可能是不同的.观察者对对象没有深入的了解,也无法对其进行修改,只能对其进行解释.
正如我所说,这个概念推动了我的许多发展决策.回到这个问题,这是一种已发布的编程类型,如果是这样,你能指点我的一些文献吗？我遇到了一些常见且不常见的情况,这些情况很难做出决定,当然还有一些我还没有想过或遇到过的事情,希望这些事情可以在文献中加以研究.
Yos*_*ale 10
在我看来,你正在以OOP方式实现函数式编程.无论物理学对"狭义相对论"的解释如何,OOP的整个概念基本上都是封装 - 你想让对象知道自己应该怎么做.基本上你在这里说的是"不,只有数据和函数可用于数据".如果甲板改变怎么办？你有一个新的经销商？您如何知道应该创建哪个经销商来处理新套牌？
如果您考虑过"切换"语句,那么您就是将OOP概念变成功能性编程模板.
这种编程风格的某些方面包含在面向数据的编程(一种专注于数据布局和转换的开发风格)中.
我对这种风格的主要问题是,如果给定类型存在隐含的假设/约束(例如,说卡片组在洗牌后连续不得有2个连接器),则必须在整个过程中复制这些约束/检查.经理类型,因为你正在操作的数据类型是完全愚蠢的 - 它不能照顾自己,它只是一个数据包.您可以将重复的逻辑提取到单独的方法中,但使用此方法编写好的,干净的代码通常要困难一些.
将此与实施Deck.Shuffle采用IDeckShuffle策略的方法进行比较.在这种情况下,您可以执行随机播放,然后添加不变检查作为后续步骤,以确保无论使用什么shuffle策略,卡片组都不会进入无效状态; 强制完整性的代码在一个地方,易于验证和更新.
此外,由于对IDeckShuffler.Shuffle(...)的调用来自Deck内部,因此该套牌可以访问所有隐藏字段和封装状态.因此,您可以将最小细节暴露给甲板洗牌程序实现,而不是默认传递甲板.相反,您可以传递IEnumerable<Card>或更不具体的东西,而不是默认传递整个数据包.
无论如何,您正在询问的开发形式基本上是程序编程.因此,隐藏信息和封装事物更加困难.在性能关键系统中,这可以是可接受的权衡(按类型对所有数据进行分组,然后使用管理器'进程'函数=良好的高速缓存一致性来迭代它).
在一般的开发中,我远离这种编程风格,因为它严重阻碍了我管理复杂性的能力. 艾恩德有一段关于此事的好帖子.虽然他在谈论数据存储对象及其上的操作,但原理完全相同 - 数据与作用于数据的函数的分离及其中的问题.