对于表单对象应该处理什么样的代码而不是让对象自己处理它，是否有人有任何硬性规定？例如，如果有一场比赛，那么正在比赛的对象是否应该说马，将比赛作为马的一部分来处理，还是将其放在表单对象中更好？我想我要问的是如何决定什么进入像马这样的对象作为方法，以及进入表单对象而不是马。在这种情况下，您是否使用任何规则来确定最适合抽象代码的位置？
【问题讨论】：
标签： c# abstraction rules
这称为“关注点分离”。让表单处理显示和用户交互。让Racer 处理赛车。
【讨论】：
我尝试开发我的软件，以便将不依赖于 UI 的核心功能抽象为负责其任务的类。
试着思考：
我怎样才能写这个，这样我就可以在不复制任何代码的情况下同时拥有 GUI 界面和控制台界面。
UI 应该只处理视觉效果和用户交互。其他一切都应根据其角色进行组织。
【讨论】：
不确定这里是否有绝对正确的答案。但同意约翰桑德斯的意见。 “表单”的工作主要负责向用户显示数据并接受数据输入。你越接近那个，而且只有那个。想想什么时候有其他地方可以使用这种类型的数据，如果代码在其他地方，它可以被重用。
让“业务对象”或“外观”处理比赛的逻辑，以及显示它的表单。
【讨论】：
尝试以事物在现实世界中的方式表示事物。任何描述马的属性或动作的东西都属于马对象。任何描述比赛的属性或动作（可能包括马对象的集合）的东西都属于比赛对象。表单不是真实世界的对象，而只是用于显示来自马/比赛/任何信息的小工具。所以不要在表单中存储任何东西，除非需要在屏幕上显示真实数据。
【讨论】：
由于表单是 UI 的一部分，我将应用我的 UI 硬性规定： UI = 格式化、排序和显示数据以及接受和验证输入
【讨论】：