OO辩论：假设包含对象的类型 [英] OO debate: assuming type of containing object
问题描述
我正在就我的工作进行激烈的辩论，因为这些对象假定知道
它们包含的对象类型。
本次辩论专门针对ASP.NET，但我已经决定在C＃论坛上发布
，因为这是大多数OO大师的用武之地，我认为这是一个根本问题。 OO设计。
在ASP.NET中，WebForm和UserControl类型的对象具有一个固有的Page
属性，该属性引用它们包含的页面。
因此，对于UserControl1< oUserControl1"的实例，位于WebForm1oWebForm1的
实例中。 ，oUserControl1.Page = oWebForm1。
嵌套也是可能的：对于位于oUserControl1内的UserControl2< oUserControl2"
的实例，oUserControl2.Page = oWebForm1 。
默认情况下，WebForms继承自基本的ASP.NET Page类：
System.Web.UI.Page。
一种常见的模式是在派生的
类中包含公共页面功能，然后从中派生所有WebForms。例如，CorePage：
System.Web.UI.Page。
因此，如果我们定义WebForm1：CorePage，那么编写
以下代码在UserControl1中：
（（CorePage）页面。）。自定义属性=" abcd";
（（CorePage）页面）.CustomMethod（textBox1.Text）;
但是如果你确实编写了这样的代码，那么这个UserControl的实例只能是位于WebForms中的
，它来源于CorePage。
我们也可以在UserControl2中编写上面的代码。但是如果我们这样做，那么UserControl2的所有
实例必须最终包含在WebForms中，其中
来自CorePage。
辩论如下：我认为还有其他方法可以触发包含对象提供的功能。
事件就是这样一种机制。我不认为对象的可移植性应该受到损害，有利于编码的便利性。
其他人认为，对于我们的项目，没有预料到需要使用
不是从CorePage派生的WebForms。他们进一步认为，做出这样的假设是非敏捷的（敏捷是这种导入的流行语。
当前的sw开发场景，那些反对的人;敏捷被标记为
女巫并在火刑柱上烧毁。
" John A Grandy < jo ********* @ gmail.comwrote：
其他人认为，对于我们的项目，没有预料到需要使用
不是从CorePage派生的WebForms。此外，他们认为制作这样的假设是非敏捷的[...]。
我大部分时间都在围栏上，但是我已经沿着这个确切的路径走了一段时间，我'我在这里得到了一些意见。
在我参与的许多项目中，无论是Winforms还是Web，我们都有过这场辩论。由于来自C ++背景，我们通常最终抱怨缺少多重继承，并且可怕的方式.Net强迫我们在这里决定
。接口显然不是答案，而强制继承树
显然不是答案。 （但这不会改变，而另一个关于这个话题的另一个是没有意义的......）
几乎在所有情况下，我们从SoapBoxUserControlBase开始或者
SoapBoxFormBase。几乎在所有情况下，我们最终都将这些代码翻录出来。
out。我想我们只是顽固，因为我们一直坚持这样做。我们
也经常需要将此功能放在非基于UI的类上，
会导致明显的问题。
我们通常最终创建一个接口（ISoapBoxSomething）然后
在需要它的部分上实现此接口。通常这个上面定义了很少的事件，而且很少有属性。这最终成为最优秀的b $ b敏捷方法，因为它允许最灵活和最大的变化。
这里明显的模式是装饰模式，但是由于某种原因，我们
通常不会最终使用它。我不太清楚为什么会这样......
http://www.google.com/search?q=Decorator+Pattern
-
Chris Mullins
我在关于物体假设知识的工作中进行了激烈的辩论
这类包含对象的类型。
这个辩论专门针对ASP.NET，但是我已经决定在C＃论坛上发布
，因为这是大多数OO大师的用武之地，而且我是
将此视为OO设计的基本问题。
在ASP.NET中，WebForm和UserControl类型的对象具有内在的Page
属性，指的是它们包含的页面。
因此，对于UserControl1的实例，oUserControl1位于WebForm1oWebForm1的
实例中。 ，oUserControl1.Page = oWebForm1。
嵌套也是可能的：对于位于oUserControl1内的UserControl2< oUserControl2"
的实例，oUserControl2.Page = oWebForm1 。
默认情况下，WebForms继承自基本的ASP.NET Page类：
System.Web.UI.Page。
一种常见的模式是在派生的
类中包含公共页面功能，然后从中派生所有WebForms。例如，CorePage：
System.Web.UI.Page。
因此，如果我们定义WebForm1：CorePage，那么
在UserControl1中编写以下代码：
（（CorePage）页面。）.CustomProperty =" abcd";
（（CorePage）页面）.CustomMethod（textBox1.Text）;
但是如果你确实编写了这样的代码，那么这个UserControl的实例只能是位于WebForms中的
，它来源于CorePage。
我们也可以在UserControl2中编写上面的代码。但是如果我们这样做，那么UserControl2的所有
实例必须最终包含在WebForms中，其中
来自CorePage。
辩论如下所示：我认为还有其他方法可以触发包含对象提供的功能。
事件就是这样一种机制。我不认为对象的可移植性应该受到损害，有利于编码的便利性。
< blockquote> On 2007-11-02 11:11:07 -0700，John A Grandy < jo ********* @ gmail.comsaid：
[...]
辩论如下如下：我认为还有其他方法可以触发包含对象提供的功能。
事件就是这样一种机制。我不认为对象的可移植性应该受到损害，有利于编码的便利性。
其他人认为，对于我们的项目，没有预料到需要使用
不是从CorePage派生的WebForms。他们进一步认为，做出这样的假设是非敏捷的（敏捷是这种导入的流行语。
当前的sw开发场景，那些反对的人;敏捷被称为
女巫并在火刑柱上烧毁）。
不要暗示使用最新的流行语是否有任何价值
证明一个人的立场（特别是当他们的位置）似乎被误用了......怎么
将自己锁定在一个应该是敏捷的特定设计中？
但至少从你所拥有的开始发布它并不清楚我的
位置是正确的。
您提供的示例没有任何内容表明基于事件的明显
界面，我也不觉得使用某个事件必然会避免关于一个类对另一个类做出假设的问题。特别是在
中，如果你可以定义一个满足
通用性需求的通用事件，你可以定义一个基类或接口
做同样的事情。
恕我直言，事件对于特定目的很有用，与支持特殊类型的回调机制有关。它们与类间依赖关系的问题是正交的。
现在，就问题而言（类间依赖性问题），
我完全是为了设计代码以便它可以重复使用，但我也不是为了支持混淆设计，以便你可以保留你的对象
分开。如果某个对象在某种程度上真正依赖于另一个对象的特定行为，那么我根本没有看到任何问题
代表类设计中的那个。
在您发布的示例中，尽可能告诉您的控件类
_does_实际上取决于CorePage类。假设它是有效的
依赖，我没有看到任何方法让你的控制类专门向CorePage类引用
。
这并不是说你不能创造一个可重复使用的设计。虽然你提供的关于设计的具体细节很少，但你肯定可以将你的班级层次分开
out，以便您并行相关组件。具体来说，有自定义基页和控件对象，而不仅仅是一个自定义的页面对象。在你的控件类中，把基本类中的
功能写入，只能依赖原始基础
Page类，并放入派生类中更具体
功能取决于你的自定义派生的CorePage类。
这样，如果你确实需要重用不是<的控制代码br />
依赖于自定义的CorePage类，这很容易完成。在
的同时，你有一个派生控件类，它可以对CorePage容器实例做出任何需要的假设。
如果上述情况在你的场景中没有意义，我会建议
你的问题太模糊了。如果你想要一个更明智的
回复，你应该发布一个更具体的例子。特别是，你试图比较的两个设计中每个设计的一个非常简单的例子，
说明了类层次结构和类间的一个例子。 >
依赖关系你。有了这样的例子，它就会更容易理解这个问题，也更容易理解
你建议基于事件的解决方案会更好，并且
最终更容易有用地评论，提供了特定的替代品，你提供的例子是
。
Pete
注意但是那个'非敏捷！参数是指参考
预测当前不存在的需求（例如，预计将来某个时候某个UserControl woulk需要驻留在某个地方的
$>
WebForm并非源自CorePage）。
就更具体的例子而言，有很多，但有一个
所有UserControl需要访问的功能：
这是MessageDisplay UserControl的配置和显示，
生成显示错误和其他信息的自定义脚本
给用户的消息。
虽然我们目前没有多个UserControl会出现的情况需要发出这样的消息一个回发，我们决定将MessageControl写成消息聚合器。
你提到的创建UserControl基类的设计，
CoreUserControl，并要求任何UserControl t帽子可能被包含
源自CorePage的WebForm必须派生自CoreUserControl，
被讨论但被丢弃，因为不必要的复杂且涉及太多
改造（底线不敏捷！）。
由于编码成本太高而且复杂性增加，事件被丢弃。一个
的投票机制，加倍。
推动这场辩论的另一方面是真正的编码
方便。 br />
我的论点是，大量复杂的高度测试的UI
功能逐渐被构建到各种UserControl中。我相信这些UserControls的巨额开发投资将在某些时候被用到
。我们是一家发展迅速的公司，由独立的开发团队开发的姐妹应用程序完全可以实现。即使没有计划好，但在某些时候我们可以将预先构建的功能转移到这些组中，这可能会成为业务的必要条件。
这就是我认为敏捷教条真正崩溃的地方。人们变得有能力反对坚实的OO基础设施，因为这样的额外努力是非敏捷的。
I''m in a vigorous debate at my work regarding objects assuming knowledge of
the type their containing object.
This debate pertains specifically to ASP.NET, but I have decided to post in
the C# forum because this is where most of the OO gurus hang out, and I view
this as a fundamental issue of OO design.
In ASP.NET, objects of type WebForm and UserControl have an intrinsic Page
property which refers to their containing Page.
So, for an instance of UserControl1 "oUserControl1" located inside an
instance of WebForm1 "oWebForm1" , oUserControl1.Page = oWebForm1.
Nesting is also possible: for an instance of UserControl2 "oUserControl2"
located inside oUserControl1, oUserControl2.Page = oWebForm1.
By default, WebForms inherit from the base ASP.NET Page class :
System.Web.UI.Page.
One common pattern is to include common page functionality in a derived
class, and then derive all WebForms from it. For example, CorePage :
System.Web.UI.Page.
So if we define WebForm1 : CorePage , it is possible and convenient to write
following code inside UserControl1 :
((CorePage)Page).CustomProperty = "abcd";
((CorePage)Page).CustomMethod( textBox1.Text );
But if you do write such code, instances of this UserControl can only be
located inside WebForms which derive from CorePage.
We can also write the above code inside UserControl2. But if we do, all
instances of UserControl2 must be ultimately contained in WebForms which
derive from CorePage.
The debate is as follows: I argue that there are other ways for
UserControls to trigger functionality provided by containing objects.
Events are one such mechanism. I do not think that portability of objects
should be compromised in favor of coding convenience.
Others argue that for our project there is no anticipated need to ever use
WebForms that do not derive from CorePage. Further they argue that making
such an assumption is non-agile ( "agile" being a buzzword of such import on
the current sw dev scene that those arguing against "agile" are branded as
witches and burned at the stake).
"John A Grandy" <jo*********@gmail.comwrote:
Others argue that for our project there is no anticipated need to ever use
WebForms that do not derive from CorePage. Further they argue that making
such an assumption is non-agile [...].I''m on the fence for most of this, but having been down this EXACT path a
number of time, I''ve got some input here.
In many projects I''ve worked on, both Winforms and Web, we''ve had this
debate. Being from a C++ background, we usually end up grumbling about the
lack of Multiple Inheritence, and the horrible way .Net forces us to decide
here. Interfaces are clearly not the answer, and a mandated inheritence tree
is clearly not the answer. (But this isn''t going to change, and yet another
rant of on this topic is pointless...)
In nearly every case, we''ve started with "SoapBoxUserControlBase" or
"SoapBoxFormBase". In nearly every case, we''ve ended up ripping this code
out. I guess we''re just stubborn in that we keep doing it the hard way. We
also often need to put this functionality on classes that are not UI based,
which causes obvious issues.
We typically end up creating an Interface ("ISoapBoxSomething") and then
implementing this interface on the pieces that need it. Usually this has a
few events defined on it, and few properties. This ends up being the most
agile approach, as it allows the most flexability and the most change.
The obvious pattern here is a Decorator pattern, but for some reason we
often don''t end up using it. I''m not quite sure why that is...
http://www.google.com/search?q=Decorator+Pattern
--
Chris Mullins
I''m in a vigorous debate at my work regarding objects assuming knowledge
of the type their containing object.
This debate pertains specifically to ASP.NET, but I have decided to post
in the C# forum because this is where most of the OO gurus hang out, and I
view this as a fundamental issue of OO design.
In ASP.NET, objects of type WebForm and UserControl have an intrinsic Page
property which refers to their containing Page.
So, for an instance of UserControl1 "oUserControl1" located inside an
instance of WebForm1 "oWebForm1" , oUserControl1.Page = oWebForm1.
Nesting is also possible: for an instance of UserControl2 "oUserControl2"
located inside oUserControl1, oUserControl2.Page = oWebForm1.
By default, WebForms inherit from the base ASP.NET Page class :
System.Web.UI.Page.
One common pattern is to include common page functionality in a derived
class, and then derive all WebForms from it. For example, CorePage :
System.Web.UI.Page.
So if we define WebForm1 : CorePage , it is possible and convenient to
write following code inside UserControl1 :
((CorePage)Page).CustomProperty = "abcd";
((CorePage)Page).CustomMethod( textBox1.Text );
But if you do write such code, instances of this UserControl can only be
located inside WebForms which derive from CorePage.
We can also write the above code inside UserControl2. But if we do, all
instances of UserControl2 must be ultimately contained in WebForms which
derive from CorePage.
The debate is as follows: I argue that there are other ways for
UserControls to trigger functionality provided by containing objects.
Events are one such mechanism. I do not think that portability of objects
should be compromised in favor of coding convenience.
On 2007-11-02 11:11:07 -0700, "John A Grandy" <jo*********@gmail.comsaid:
[...]
The debate is as follows: I argue that there are other ways for
UserControls to trigger functionality provided by containing objects.
Events are one such mechanism. I do not think that portability of objects
should be compromised in favor of coding convenience.
Others argue that for our project there is no anticipated need to ever use
WebForms that do not derive from CorePage. Further they argue that making
such an assumption is non-agile ( "agile" being a buzzword of such import on
the current sw dev scene that those arguing against "agile" are branded as
witches and burned at the stake).Not to suggest that there''s any value in using the latest buzzwords to
justify one''s position (especially when they seem to be misused...how
is locking yourself into a specific design supposed to be "agile"?),
but at least from what you''ve posted it''s not clear to me that your
position is the correct one.
Nothing about the example you provided suggests an obvious event-based
interface, nor do I feel that using an event necessarily avoids the
issues with respect to one class making assumptions about another. In
particular, if you could define a general-purpose event that satisfies
the need for generality, you could define a base class or interface
that does the same thing.
IMHO, events are useful for a specific purpose, related to supports a
particular kind of callback mechanism. They are orthogonal to the
question of inter-class dependency.
Now as far as that question goes (the one of inter-class dependency),
I''m all for designing code so that it can be reused, but I''m also not
in favor of obfuscating a design just so that you can keep your objects
separate. If an object truly depends on the specific behavior of
another object in some way, then I don''t see any problem at all
representing that in the class design.
In the example you posted, as near as I can tell your control class
_does_ in fact depend on the CorePage class. Assuming it''s a valid
dependency, I don''t see any way around having your control class refer
specifically to the CorePage class.
That''s not to say you can''t create a reusable design. While you''ve
provided very little in the way of specifics regarding the design
you''re dealing with, you certainly could separate your class hierarchy
out so that you parallel the dependent components. Specifically, have
both custom base page and control objects rather than just a custom
page object. In your control classes, put into the base class the
functionality that can be written dependent only on the original base
Page class, and put into a derived class the more specific
functionality that is dependent on your custom derived CorePage class.
In that way, if you do need to reuse the control code that isn''t
dependent on the custom CorePage class, that''s easily done. At the
same time, you have a derived control class that can make whatever
assumptions it needs to about the CorePage container instance.
If the above does not make sense in your scenario, I''ll suggest that
your question is just too ambiguous. If you want a more sensible
reply, you should post a more concrete example. In particular, a very
simple example of each of the two designs you are trying to compare,
illustrating the class hierarchy and an example of the inter-class
dependency that concerns you. With an example like that, it will be
much easier to understand the question, as well as easier to understant
your suggestion that an event-based solution would be better, and
finally easier to comment usefully, providing specific alternatives to
the example you provide.
Pete
Note that the "but that''s non agile !" argument is in reference to
anticipating a need which does not currently exist (e.g. anticipating that
at some point in the future a given UserControl woulk need to reside in a
WebForm that does not derive from CorePage).
As far as more concrete examples, there are many, but there is a single
piece of functionality which all UserControls need access to :
This is configuration and display of a MessageDisplay UserControl that
generates custom script that displays errors and other informational
messages to the user.
Although we currently have no scenarios in which multiple UserControls would
need to originate such messages for a single postback, we decided to write
the MessageControl as a message aggregator.
The design you mention of creating a UserControl base class,
CoreUserControl, and requiring that any UserControl that might be contained
in a WebForm that derives from CorePage must derive from CoreUserControl,
was discussed but discarded as unnecessarily complex and involving too much
retrofit (bottom line "not agile!").
Events were discarded as too much coding-cost and added complexity. A
polling mechanism, doubly so.
What is driving this debate on the opposing side is really coding
convenience.
My argument is that very large swaths of intricate highly-tested UI
functionality are gradually being built into various UserControls. I
believe that the huge dev investment in these UserControls will be leveraged
at some point. We are a rapidly growing company, and sister applications
developed by separate dev groups are entirely possible. Even if not
planned, it may become business-imperative at some point for us to transfer
pre-built pieces of functionality to those groups.
This is where I think the agile dogma really breaks down. People become
empowered to argue against solid OO infrastructures on the basis that such
additional effort is "non-agile".
这篇关于OO辩论：假设包含对象的类型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
