OO设计辩论 [英] OO Design Debate
问题描述
场景：
在商务应用程序中，有一个Product类。除了产品
类之外，还有一个表单（输入
控件标签中的文本）用于输入和更新现有产品的现有实例
个对象。我们将第二个称为ProductForm。两者都是数据驱动的。
我认为这些是两个不同的类。产品和产品形式。产品
包含业务端，ProductForm包含演示文稿结束。
我的同事在这方面强烈反对我。他认为他们应该在同一个班级，因为他们处理一个对象，即产品。而且他好b / b
有很好的论据。
因此，我们认为听到来自外部专家的论证可能会减少一些
学科。我们正在考虑的事情是可读性，
可维护性，可访问性和可扩展性。
Scenario:
In a commerce application, there is a Product class. Along with the Product
class there is a form (the text that goes in the labels of the input
controls) for inputting and updating existing instances of existing Product
objects. We''ll call the second a ProductForm. Both would be data-driven.
I view these as 2 distinct classes. Product and ProductForm. Where Product
contains the business end and ProductForm contains the presentation end.
My coworker vehemently disagrees with me on this. He believes they should
be in the same class since they deal with one object, the Product. And he
has good arguments.
So, we figure perhaps hearing arguments from outside experts would shed some
light on the subject. Things that we are considering is readability,
maintainability, accessibility, and scalability.
推荐答案
Nate写道：
Nate wrote:
场景：
在商业应用程序中，有一个Product类。除了Product
类之外，还有一个表单（输入
控件标签中的文本）用于输入和更新现有Product
对象的现有实例。我们将第二个称为ProductForm。两者都是数据驱动的。
我认为这些是两个不同的类。产品和产品形式。产品
包含业务端，ProductForm包含演示文稿结束。
我的同事在这方面强烈反对我。他认为他们应该处于同一个班级，因为他们处理的是一个对象，即产品。而且他有很好的论据。
因此，我们认为，听取外部专家的意见可能会对这一主题有所了解。我们正在考虑的事情是可读性，可维护性，可访问性和可扩展性。
Scenario:
In a commerce application, there is a Product class. Along with the Product
class there is a form (the text that goes in the labels of the input
controls) for inputting and updating existing instances of existing Product
objects. We''ll call the second a ProductForm. Both would be data-driven.
I view these as 2 distinct classes. Product and ProductForm. Where Product
contains the business end and ProductForm contains the presentation end.
My coworker vehemently disagrees with me on this. He believes they should
be in the same class since they deal with one object, the Product. And he
has good arguments.
So, we figure perhaps hearing arguments from outside experts would shed some
light on the subject. Things that we are considering is readability,
maintainability, accessibility, and scalability.
我不想误解，这里：ProductForm是一个实例
表格？它是一个真正的WinForms（或ASP.NET）表单吗？
或者它是否为某些类提供信息，以便为维护产品的
提供信息？ />
我能提供的是我在（小）WinForms
系统中使用的架构：我有_three_类：
1.产品，纯粹包含产品的业务逻辑。特别是
，Product不允许其任何字段包含无效的
内容，也不允许无效的字段组合。因此，每个
产品都是您可以在业务中使用的有效产品。
2. ProductForm，它是实际的WinForms格式：
公共类ProductForm：表格{...}
3. ProductValidator，即大脑在ProductForm之后。
ProductValidator告诉ProductForm何时应该启用字段或
禁用，显示或隐藏。它允许Product
字段的无效值，并在用户输入无效内容时向ProductForm
返回措辞良好的错误消息。
当ProductValidator对用户输入竖起大拇指时，调用
应用程序可以要求它返回与用户输入相对应的Product实例
。
这里重要的一点是，你并不是真的想要各种各样的用户输入验证和所有产品一起使用
$ b你日常使用的$ b。您也不希望这些产品允许包含无效信息，并强制您的所有业务
逻辑来检查myProduct.IsValid。通过将用户
输入检查/验证分成一个单独的对象，我可以创建
简单的产品只关注业务规则和
永远不能包含无效信息，这简化了我的业务
层。
无论如何，我不确定这是否回答了你的问题。
您可能需要查看模型/视图/演示者。设计模式
对于这些要点的某些行业标准服务。
I don''t want to misunderstand, here: Is ProductForm an instance of
Form? Is it an actual WinForms (or ASP.NET) form?
Or is it some class providing information to a generic form for
maintaining products?
All I can offer is the architecture I have used in my (small) WinForms
system: I have _three_ classes:
1. Product, which contains purely the business logic for a product. In
particular, Product does not permit any of its fields to have invalid
contents, nor does it permit invalid combinations of fields. So, every
Product is a valid product that you could use in the business.
2. ProductForm, which is the actual WinForms form:
public class ProductForm : Form { ... }
3. ProductValidator, which is the "brains" behind ProductForm.
ProductValidator tells ProductForm when fields should be enabled or
disabled, shown or hidden. It allows invalid values for the Product
fields, and returns nicely worded error messages to the ProductForm
whenever the user enters something invalid.
When ProductValidator gives the thumbs up on user input, the calling
application can then ask it to return the Product instance
corresponding to the user inputs.
An important point here is that you don''t really want all sorts of
heavy user input validation floating around with all of your Products
that you use day-to-day. Neither do you want those Products to be
allowed to contain invalid information, and force all of your business
logic to check myProduct.IsValid at every turn. By splitting the user
input checking / validation out into a separate object I can create
simple Products that are only concerned with business rules and that
can never contain invalid information, which simplifies my business
layer.
Anyway, I''m not sure if that answered your question.
You may want to look into the "Model / View / Presenter" design pattern
for some industry standard avice on these points.
我会不同意他的意见（建议也推荐一下在MVP / MVC
设计模式）。
这里有一些原因。顺便说一句我不相信他在winform / webform的
上下文中讨论表格..
1）产品表格可以重复使用每次我都不需要新的实例
画一个屏幕
公共类ProductForm {
private static ProductForm engish;
public static ProductForm English {
get {return english; }
}
//所有产品形式行为..我也会将ProductForm设为
不可变对象。
}
产品p = ProductRepository.GetProduct（SomeCriteria）;
CreateViewFor（p，ProductForm.English）
这是一个简单的例子..更有可能你会得到一个方法，
需要文化来获得正确的对象（但你明白了）。
通过这样做，我们只为产品本身创建一个新对象（并且通过不再重新创建所有字符串来保存
大量内存
将保持不变。
2）产品表格没有描述产品..它描述了产品编辑界面的
元数据。这两个项目应该能够独立地区分（我应该能够拥有一个带有
不同编辑界面的产品）
3）如果其他业务逻辑允许说另一个类中的逻辑需要访问产品信息（即获取产品对象），该怎么办？有点愚蠢
通过收取产品表格信息的开销（
它永远不会使用）
4）我在许多情况下可能想要序列化一个产品（或者说b * b b描述产品形式的信息）将它们组合在一起迫使我
来序列化两者（即使我只需要一个或另一个）
5）正如我所提到的，我将使产品形式不变，产品将是
可变...
干杯，
Greg Young
MVP - C＃
http://geekswithblogs.net/gyoung
" Nate" <的Na ** @ discussions.microsoft.com>在消息中写道
新闻：AD ********************************** @ microsof t.com ...
I will disagree with him (and recommend also recommend a look at the MVP/MVC
design patterns).
here are some reasons. btw I do not believe he is talking about form in the
context of a winform/webform ..
1) The product form can be re-used I don''t need a new instance every time I
draw a screen
public class ProductForm {
private static ProductForm engish;
public static ProductForm English {
get { return english; }
}
//all product form behaviors .. I would also make ProductForm an
immutable object.
}
Product p = ProductRepository.GetProduct(SomeCriteria);
CreateViewFor(p, ProductForm.English)
This is a simple example .. more likely you would end up with a method that
takes culture to get the correct object (but you get the point).
By doing this we only create a new object for the product itself (and save a
good deal of memory by not continually re-creating all of the strings which
will remain the same).
2) The product form is not describing the product .. it is describing the
metadata for the editting interface for the product. These two items should
be able to differ independently (I should be able to have a product with a
different editting interface)
3) What if other business logic lets say logic in another class needs to
access product information (i.e. get a product object)? Kind of silly for it
to go through the overhead of also acquiring the the product form info (that
it will never use)
4) I under a number of circumstances might want to serialize a product (or
the information describing the product form) putting them together forces me
to serialize both (even if I only need one or the other)
5) as I mentioned I would make product form immutable, product would be
mutable ...
Cheers,
Greg Young
MVP - C#
http://geekswithblogs.net/gyoung
"Nate" <Na**@discussions.microsoft.com> wrote in message
news:AD**********************************@microsof t.com...
场景：
在商业应用程序中，有一个Product类。与
产品类一起，有一个表单（输入
控件标签中的文本），用于输入和更新现有产品的现有实例对象。我们将第二个称为ProductForm。两者都是数据驱动的。
我认为这些是两个不同的类。产品和产品形式。
产品
包含业务端，ProductForm包含演示文稿结束。
我的同事在这方面强烈反对我。他认为他们应该处于同一个班级，因为他们处理的是一个对象，即产品。而且他有很好的论据。
所以，我们认为，听取外部专家的意见可能会对这个问题有所了解。我们正在考虑的是可读性，可维护性，可访问性和可伸缩性。
Scenario:
In a commerce application, there is a Product class. Along with the
Product
class there is a form (the text that goes in the labels of the input
controls) for inputting and updating existing instances of existing
Product
objects. We''ll call the second a ProductForm. Both would be data-driven.
I view these as 2 distinct classes. Product and ProductForm. Where
Product
contains the business end and ProductForm contains the presentation end.
My coworker vehemently disagrees with me on this. He believes they should
be in the same class since they deal with one object, the Product. And he
has good arguments.
So, we figure perhaps hearing arguments from outside experts would shed
some
light on the subject. Things that we are considering is readability,
maintainability, accessibility, and scalability.
" Nate" <的Na ** @ discussions.microsoft.com> écritdansle message de news：
AD ********************************** @ microsoft.com ...
|在商务应用程序中，有一个Product类。随着
产品
| class有一个表单（输入标签中的文字
|控件）用于输入和更新现有的现有实例
产品
|对象。我们将第二个称为ProductForm。两者都是数据驱动的。
|
|我认为这些是两个不同的类。产品和产品形式。哪里
产品
|包含业务端，ProductForm包含演示文稿结束。
|
|我的同事在这方面强烈反对我。他认为他们应该是
|因为他们处理一个对象，产品，所以在同一个类中。而他
|有很好的论据。
|
|所以，我们或许可以从外部专家的听证会上得知
一些
|关于这个问题的光。我们正在考虑的是可读性，
|可维护性，可访问性和可扩展性。
从多年的经验中帮助 同事，我可以老实说，
这个肯定是错的！
虽然产品和表格处理的是同一类型事情，
他们正在处理那件事的不同方面。
正如Bruce和Greg都推荐的那样，MVP是一个理想的例子
UI应与业务层分开。
在MVP中，模型保存Value，在本例中为Product。它还可以保存
a命令集和一个选择，虽然这在使用对象列表处理
时更常见。
视图包含对UI元素的引用和适应元素。 UI控件
符合作为模型中值的Observer的要求，因此当值更改状态时，
会通知View并自行更新。
Presenter同时拥有Model和View，并负责
创建它们之间的Observer关系。演示者还持有一个或多个Interactors，它们负责翻译用户
手势。 （点击，鼠标移动等）在UI中调用
模型/值。
遵循MVP模式，至少在我实现它时，意味着除了设计师提供的代码外，表格上还有
绝对*无*代码。
使用此设计应用程序的好处;层叠"技术是
你可以用UI替换任何东西，而不需要
来触摸你经过考验的商业课程。
说完这一切之后，你最好不要告诉你的同事
创建Object Persistence Frameworks的想法，这样数据库代码完全是单独的b
来自商务舱。他可以适应中风！ :-)）
Joanna
-
Joanna Carter [TeamB]
顾问软件工程师
"Nate" <Na**@discussions.microsoft.com> a écrit dans le message de news:
AD**********************************@microsoft.com...
| In a commerce application, there is a Product class. Along with the
Product
| class there is a form (the text that goes in the labels of the input
| controls) for inputting and updating existing instances of existing
Product
| objects. We''ll call the second a ProductForm. Both would be data-driven.
|
| I view these as 2 distinct classes. Product and ProductForm. Where
Product
| contains the business end and ProductForm contains the presentation end.
|
| My coworker vehemently disagrees with me on this. He believes they should
| be in the same class since they deal with one object, the Product. And he
| has good arguments.
|
| So, we figure perhaps hearing arguments from outside experts would shed
some
| light on the subject. Things that we are considering is readability,
| maintainability, accessibility, and scalability.
From many years of experience "helping" "co-workers", I can honestly say,
this one is definitely wrong!
Although the Product and the form are dealing with the same type of thing,
they are dealing with different aspects of that thing.
As Bruce and Greg have both recommended, MVP is an ideal example of how the
UI should be separated from the business layer.
In MVP, the Model holds the Value, in this case a Product. It can also hold
a Command Set and a Selection, although this is more common when dealing
with lists of objects.
The View holds a reference to the UI element and "adapts" the UI control to
fit the requirements of being an Observer to the Value in the Model, so that
when the Value changes state, the View is notified and updates itself.
The Presenter hold both the Model and the View and is responsible for
creating the Observer relationship between them. The Presenter also holds
one or more Interactors, which are responsible for translating user
"gestures" (clicks, mouse moves, etc) in the UI into calls to the
Model/Value.
Following the MVP pattern, at least as I implement it, means that there is
absolutely *no* code on the form apart from that put there by the designer.
The benefits of designing applications using this "layering" technique is
that you would be able to replace anything to do with the UI without having
to touch your tried and tested business classes.
Having said all this, you''d better not tell your colleague about the idea of
creating Object Persistence Frameworks so that the database code is entirely
separate from the business class. He could have an apoplectic fit ! :-))
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
这篇关于OO设计辩论的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
