byt*_*uff 9 oop class data-structures
将数据操作函数移动到包含该数据的类时,在哪里绘制线？例如,假设您有一个简单的类,它存储天气的描述,包括温度,湿度,风速和风向的变量,以及测量的时间.现在假设你有一个这个类的对象,你想把它传送给别人 - 另一个进程,另一台机器,等等.您是否将代码传输到对象本身 - 例如,通过向简单数据类添加Send(目标类型)方法？或者你是否将这种功能保存在可以通过介质发送和接收任何内容的单独类中 - 无论是网络,文件i/o,进程间通信还是类似的东西？
我的直觉是保持我的数据类简单并在我想传输它们时将它们包装起来 - 在序列化它们的类中,并使用他们理解的简单接口呈现发送器和接收器类.另一种方法似乎是将包括厨房水槽在内的所有东西都放入简单的数据类中 - 每个函数都可以对这些数据进行操作,但是间接的.简而言之,网络错误处理代码在我看来并不属于简单的数据类.
这对我来说很明显,但我一直看到开发人员在他们的类上放置Send()方法.他们甚至将消息类告诉Send(),这对我来说似乎非常违反直觉; 如果我在一张纸上写一封信,我不会告诉该报纸.我把信封在一个信封里然后交给邮递员,因为他有一辆面包车和一张地图.人们怎么想？
有效载荷项本身就有逻辑:现在的风速是多少？
解释这些数据有逻辑:我们现在可以停靠这艘船了吗？
决定在某个地方发送有效载荷是有道理的:哦,这是一个新的天气价值,有人在那里关心.
然后是实际的网络东西.
有效负载可能需要能够序列化和反序列化.我没有看到其余任何一个是有效载荷的问题.Send()必须有一个更好的地方.尤其是因为您可能会选择一次发送多个有效负载对象,并且它们不能全部相互发送.
这不是一个简单的问题.我已经使用这两种方法完成了项目,总的来说,我更乐意使用"智能模型"方法,模型知道如何使用自己的数据做事情.
导致良好封装的原则之一是"告诉,不要问" - 如果你告诉班级要对自己做点什么,那么除了班级本身之外没有人需要知道班级内部的细节表示.这绝对是件好事.此外,我发现将逻辑放入类本身通常可以简化代码重用 - 当其他人去使用该类时,他们会很快发现它已经知道如何执行给定的操作.
但是,我不希望这导致我的应用程序层之间的界限突破.我不希望业务对象知道如何将自己表示为HTML - 这是一个表示问题.所以在这种情况下,我会说该类应该知道如何以某种规范的方式表示自己,但它不应该知道网络的东西.实际的发送功能应属于某项服务.
I've gone back and forth on this sort of design question several times in my career. Right now, I'm where you seem to be, mostly because I do a whole lot of SOA in my current life, and I end up writing a LOT of clases that exist only to be serialized into and out of various over-the-wire formats, mostly involving XML and JSON.
当您进入"服务"世界时,类通常只是来回发送的数据的表示.因此,我将我的类分成两个逻辑桶,"保存数据的类"和"做东西的类".我不知道我是否是唯一一个做这种事情的人,但那就是我所处的位置.