MVP：接口中的静态方法。 [英] MVP's: static methods in interfaces.
问题描述
大家好，
我刚刚提出这个问题，我觉得现在再次检查
...（也许是某事已经改变了或者有些东西会改变。
我读过这本关于面向组件设计的书（owreilly - Juval Lowy），
，它实际上非常好。
这本书继续介绍我们应该如何使用Interfaces而不是
课程（这是我的术语，英语不是我的语言所以我希望你
明白我在说些什么......）。
然而......
我想给我的课静态创建实例的能力，简单地说是因为我认为调用''MyClass.FromSomething（Something something）''
比构造函数''公共更直观MyClass（东西）''
这只是我...
无论如何，据我所知，接口无法定义静态成员。这个
把我推到了一些我更喜欢的东西 - 一个班级工厂（即使它在某些情况下是一个很好的做法）。
MVP''...
1.我有更多......''优雅'的方式来实现这个目标吗？
2.我们想从C＃中获取这些东西（
接口中的静态成员decleration）？
3. am我只是挑剔（我应该只使用构造函数而忘记我的
直觉？）
4.我完全错了吗？
5.以上所有
Thanx，
Picho
挂在......我们今天甚至可以在接口中定义构造函数吗？...
上帝我甚至迷惑自己...
Picho写道：
我想给我的课静态创建实例的能力，简单地因为我认为调用''MyClass.FromSomething（Something something）''
更直观na constructor''public MyClass（Something something）''
对于课程，你可以这样做：
public class MyClass {
protected MyClass（...）{...}
public FromSomething（...）{return new MyClass（...）; }
}
所以，实际上你的问题并不是因为试图重新定义
contruction。它起源于试图（通常称之为）虚拟
构造。
这只是我......
请注意，其他人可能不同意。有时它会更容易接受他们提供的问题的常见习语，而不是教你所有与新人一起工作的b $ b（有时候，新的那个有b $ b它自己的问题:)
无论如何，据我所知，接口无法定义静态成员。这促使我进入了一些我更喜欢的东西 - 一个班级工厂（即使它在某些情况下是一个很好的做法）。
所有多态行为都在C＃中的实例上，你要求
虚拟构造（使用多态）。所以，你需要一个
实例，通常称为工厂。
1.我有更多......''优雅'的方式实现这一目标吗？
不是真的，特别是不要陷入原型
contruction的陷阱。如果你实际上不需要*克隆。
你可以使用委托进行虚拟建设（委托给
FromSomething）但是否更优雅是值得商榷的。
2.我们想从C＃中获取这些东西（
接口中的静态成员decleration）？
或许，但我不会这么认为你要求的。
因为C＃不允许免费功能，能够在界面声明中完全实现接口声明的界面实现纯粹的静态功能将是很好的。这并不能解决为类对称操作而丢失
自由函数的问题。
3. am我只是挑剔（我应该只使用构造函数和忘了我的直觉？）
你不能仅仅使用构造函数进行虚拟构建。
关于FromSomething（...）成语，你可能想要思考
是否它足以让你突破新（...）成语，
被广泛使用。
FromSomething *给你买的一件事就是你可以做
代表对于构造，你不能用新的东西。
注意，你也想要在课堂上写一个构造函数
如果你做了FromSomthing ，你只需要决定是否将b $ b公开或保护。
就个人而言，我会考虑只将FromSomething作为一个补充
选项，所以我不会让构造函数受到保护。如果有一些* SomeThings *，或者我需要由代表进行建设，我可能只会做FromSomething。
我完全错了吗？
嗯，....你混淆了两个不同的问题，...
挂起...我们甚至可以定义构造函数接口今天？...上帝我甚至迷惑自己...
不，你不能。
你不能实例化一个接口，因为一个接口正好是一个实例*可以*的* b $ b *声明*。不是*如何*的接收，其中
是在一个类中完成的（也可能偶然也包含状态）。
-
Helge
Thanx回复Helge。
总结一下，你说的是没有接口的方式可以强制执行或指示一个类实现自己的方式。
我不是在和你说的话争论，我甚至接受这样的事实
接口与行为有关。
但是又一次，我们可以整天谈论哲学上的建设
不是一种行为.. 。
我还是想说明我真的想要一个接口来声明静态
方法，甚至不用于构造......
Picho
" Helge Jensen" <他********** @ slog.dk>在消息中写道
新闻：41 ************** @ slog.dk ...Picho写道：
我想让我的类能够静态创建实例，
只是因为我认为调用''MyClass.FromSomething（Something
某些东西）''更具直观性比起构造函数''public
MyClass（Something something）''
对于课程，你可以这样做：
public class MyClass {
protected MyClass（...）{...}
public FromSomething（...）{return new MyClass（...）; }
所以，实际上你的问题不是因为试图重新定义构造而产生的。它源于尝试（通常称之为）虚拟构建。
这只是我...
请注意，其他人可能不同意。有时候，接受他们所提供的问题的常见习语，比教你们所有与新人一起工作更容易（有时候，新人有了它）自己的问题:)
无论如何，据我所知，接口无法定义静态成员。这促使我进入一些我更喜欢的东西 - 一个班级工厂（尽管在某些情况下这是一个很好的做法）。
所有的多态行为都是对于C＃中的实例，您要求进行虚拟构造（使用多态）。所以，你需要一个实例，通常称为工厂。
1.我有更多......''优雅'的方式来实现这个目标吗？ / blockquote>
不是真的，特别是不要掉进原型建筑的坑里，如果你真的不需要*克隆的话。
<你可以使用委托进行虚拟构建（委托给FromSomething），但这是否更优雅是值得商榷的。
2.这是我们想要的C＃（
接口中的静态成员声明？
或许，但我不是这么认为你要求的。
C＃不允许自由函数，能够坚持纯粹根据
接口声明中的接口实现的静态函数是很好的。这并不能解决类对称操作中缺少自由函数的问题。
3.我只是挑剔（我应该只使用构造函数和忘记我的直觉了？）
你不能只使用构造函数进行虚拟构建。
关于FromSomething （...）"成语，你可能想要思考
它是否足以让你突破新（...）。这个广泛使用的成语。
FromSomething *给你买的一件事就是你可以代表建筑工作，这是你不能做的事。
要注意，你也想在课堂上写一个构造函数
如果你做FromSomthing，你只需要决定是将它公开还是保护。
我个人认为只有一个FromSomething作为一个添加的
选项，所以我不会让构造函数受到保护。如果SomeThings有很多*，或者我需要由代表进行建设，我可能只会做FromSomething。
4. am I完全错了？
嗯，....你混淆了两个不同的问题，...
挂在..我们今天甚至可以在界面中定义构造函数吗？...上帝我甚至迷惑自己......
不，你不能。
您无法实例化接口，因为接口完全是实例*可以*的声明*。不是*如何*的接受，这是在一个类中完成的（它可以顺便包含状态）。
-
Helge
我仍然想说明我真的想要一个接口来声明静态方法，甚至不用于构造...
据我所知，你不能。接口假定.NET中的多态性行为，而静态方法不能是多态的。
一些一般性评论：
接口不用于构造，因为在99％的情况下构造不需要多态的
。因此，如果您需要多态构造，请声明
类工厂的接口，并实现几个工厂，每个工厂封装一种不同的构造实例的方式。
至于静态方法，例如Graphics.FromHandle（），从我的角度来看，它们与接口无关。
。它们只是构建对象的便捷方式，但它们同时保证了如果实现派生类，则不会覆盖
构造行为。
-
此致，
Dmitriy Lapshin [C＃/ .NET MVP]
带来的力量今天对VS .NET IDE进行单元测试！
http：// www.x-unity.net/teststudio.aspx
" Picho" < SP ******** @ telhai.ac.il>在消息中写道
news：uv ************** @ TK2MSFTNGP12.phx.gbl ... Thanx for reply Helge。
总而言之，你所说的是，界面无法强制执行或决定一个班级实现自己的方式。
我不是在和你说的话争论，我甚至接受事实上
接口与行为有关。
然而，我们可以整天谈论哲学上的建构
不是一种行为......
我还是想说我真的想要一个接口来声明静态方法，甚至不用于构造...
Picho
" Helge Jensen <他********** @ slog.dk>在消息中写道
新闻：41 ************** @ slog.dk ...Picho写道：
我想让我的类能够静态创建实例，
只是因为我认为调用''MyClass.FromSomething（Something
某些东西）''比构造函数更直观' 'public
MyClass（Something something）''
对于课程，你可以这样做：
公共课MyClass {
protected MyClass（...）{...}
public FromSomething（...）{return new MyClass（...）; }
所以，实际上你的问题不是因为试图重新定义构造而产生的。它源于尝试（通常称之为）虚拟构建。
这只是我...
请注意，其他人可能不同意。有时候，接受他们所提供的问题的常见习语，比教你们所有与新人一起工作更容易（有时候，新人有了它）自己的问题:)
无论如何，据我所知，接口无法定义静态成员。这促使我进入一些我更喜欢的东西 - 一个班级工厂（尽管在某些情况下这是一个很好的做法）。
所有的多态行为都是对于C＃中的实例，您要求进行虚拟构造（使用多态）。所以，你需要一个实例，通常称为工厂。
1.我有更多......''优雅'的方式来实现这个目标吗？ / blockquote>
不是真的，特别是不要陷入原型构建的陷阱。如果你实际上不需要*克隆。
你可以使用委托进行虚拟构建（委托给FromSomething），但是否更优雅是值得商榷的。
< blockquote class =post_quotes> 2.我们想从C＃中获取这些东西（
接口中的静态成员decleration）？
也许，但我不这么认为在你要求的意义上。
由于C＃不允许自由功能，所以能够坚持纯粹按照<中的接口实现的静态功能将是很好的。 br />接口声明。这并不能解决类对称操作中缺少自由函数的问题。
3.我只是挑剔（我应该只使用构造函数和忘记我的直觉了？）
你不能只使用构造函数进行虚拟构建。
关于FromSomething （...）"成语，你可能想要思考
它是否足以让你突破新（...）。这个广泛使用的成语。
FromSomething *给你买的一件事就是你可以代表建筑工作，这是你不能做的事。<请注意，你也想在课堂上写一个构造函数
如果你做FromSomthing，你只需要决定是否公开或保护它。
我个人认为只有一个FromSomething作为一个添加的
选项，所以我不会让构造函数受到保护。如果SomeThings有很多*，或者我需要由代表进行建设，我可能只会做FromSomething。
4. am I完全错了？
嗯，....你混淆了两个不同的问题，...
挂在..我们今天甚至可以在界面中定义构造函数吗？...上帝我甚至迷惑自己......
不，你不能。
您无法实例化接口，因为接口完全是实例*可以*的声明*。不是*如何*的接受，它是在一个类中完成的（它可以偶然也包含状态）。
-
Helge
Hi all,
I popped up this question a while ago, and I thought it was worth checking
again now... (maybe something has changed or something will change).
I read this book about component oriented design (owreilly - Juval Lowy),
and it was actually very nice.
The book goes on about how we should use Interfaces exposure instead of
classes (this is my terminology and english is not my language so I hope you
understand what I''m on about...).
however...
I want to give my classes the ability to staticly create instances, simply
because I think that calling a ''MyClass.FromSomething(Something something)''
is more intuative than a constructor ''public MyClass(Something something)''
this is just me...
anyway, as far as I know interfaces cannot define static members. this
pushed me into something I even like less - a class factory (even though it
is in some scenarios a good practice).
MVP''s...
1. Is there a more... ''elegant'' way for me to achieve this?
2. is this somehing we want from C# (static member decleration in
interfaces)?
3. am I just being picky (should I just use constructors and forget my
intuition?)
4. am I totaly wrong?
5. all the above
Thanx,
Picho
hang on... can we even define constructors in interfaces today?...
god I even confused myself...解决方案Picho wrote:
I want to give my classes the ability to staticly create instances, simply
because I think that calling a ''MyClass.FromSomething(Something something)''
is more intuative than a constructor ''public MyClass(Something something)''
For classes, you can just do that:
public class MyClass {
protected MyClass(...) {...}
public FromSomething(...) { return new MyClass(...); }
}
So, actually your problem doesn''t arise from trying to redefine
contruction. It arises from trying to do (what is often called) virtual
construction.
this is just me...
Beware, that other people might not agree. Sometimes it''s just easier to
accept the common idioms, with the problems they offer, than to teach
all you work together with a new one (and sometimes, the new one has
it''s own problems :)
anyway, as far as I know interfaces cannot define static members. this
pushed me into something I even like less - a class factory (even though it
is in some scenarios a good practice).
All polymorphic behaviour is on instances in C#, and you are asking for
virtual construction (which uses polymorphism). So, you need an
instance, commonly called a factory.
1. Is there a more... ''elegant'' way for me to achieve this?
Not really, especially don''t fall into the pit of "prototyped
contruction" if you don''t actually *need* cloning.
You can do virtual construction using delegation (delegating to
FromSomething) but whether that is more elegant is debatable.
2. is this somehing we want from C# (static member decleration in
interfaces)?
Perhaps, but I don''t think so in the sense that you ask for.
Since C# doesn''t allow free functions, it would be nice to be able to
stick static functions implemented purely in terms of the interface in
the interface declaration. This wouldn''t solve the problem of missing
free-functions for class-symmetric operations though.
3. am I just being picky (should I just use constructors and forget my
intuition?)
You couldn''t get by just using constructors for virtual construction.
With regard to the "FromSomething(...)" idiom, you might want to ponder
whether it buys you enough to break out of the "new(...)" idiom, which
is widely used.
One thing which FromSomething *does* buy you is that you can do
delegates to the construction, something you cannot do with new.
Beware, also that you would want to write a contructor in the class even
if you do FromSomthing, you just would just need to decide whether to
make it public or protected.
Personally I would consider having a FromSomething only as an added
option, so I would not make the constructor protected. And I would
probably only do FromSomething if there were a *lot* of SomeThings, or I
needed to do construction by delegate.
4. am I totaly wrong?
Well,.... you''re mixing up two separate issues,...
hang on... can we even define constructors in interfaces today?...
god I even confused myself...
No, you can not.
You cannot instantiate an interface, since an interface is exactly a
*declaration* of what an instance *can*. Not a recepie for *how*, which
is done in a class (which can incidentally also contain state).
--
Helge
Thanx for the reply Helge.
To sum things up, what you say is that there is no way that an interface can
enforce or dictate the way a class instanciate itself.
I am not arguing with what you said and I even accept the fact that
interfaces has to do with behavior.
but then again, we can talk all day long philosophicly wether construction
is not a behavior...
I would still like to state that I realy want an interface to declare static
methods, even not for construction...
Picho
"Helge Jensen" <he**********@slog.dk> wrote in message
news:41**************@slog.dk...Picho wrote:I want to give my classes the ability to staticly create instances,
simply because I think that calling a ''MyClass.FromSomething(Something
something)'' is more intuative than a constructor ''public
MyClass(Something something)''
For classes, you can just do that:
public class MyClass {
protected MyClass(...) {...}
public FromSomething(...) { return new MyClass(...); }
}
So, actually your problem doesn''t arise from trying to redefine
contruction. It arises from trying to do (what is often called) virtual
construction.this is just me...
Beware, that other people might not agree. Sometimes it''s just easier to
accept the common idioms, with the problems they offer, than to teach all
you work together with a new one (and sometimes, the new one has it''s own
problems :)anyway, as far as I know interfaces cannot define static members. this
pushed me into something I even like less - a class factory (even though
it is in some scenarios a good practice).
All polymorphic behaviour is on instances in C#, and you are asking for
virtual construction (which uses polymorphism). So, you need an instance,
commonly called a factory.1. Is there a more... ''elegant'' way for me to achieve this?
Not really, especially don''t fall into the pit of "prototyped contruction"
if you don''t actually *need* cloning.
You can do virtual construction using delegation (delegating to
FromSomething) but whether that is more elegant is debatable.2. is this somehing we want from C# (static member decleration in
interfaces)?
Perhaps, but I don''t think so in the sense that you ask for.
Since C# doesn''t allow free functions, it would be nice to be able to
stick static functions implemented purely in terms of the interface in the
interface declaration. This wouldn''t solve the problem of missing
free-functions for class-symmetric operations though.3. am I just being picky (should I just use constructors and forget my
intuition?)
You couldn''t get by just using constructors for virtual construction.
With regard to the "FromSomething(...)" idiom, you might want to ponder
whether it buys you enough to break out of the "new(...)" idiom, which is
widely used.
One thing which FromSomething *does* buy you is that you can do delegates
to the construction, something you cannot do with new.
Beware, also that you would want to write a contructor in the class even
if you do FromSomthing, you just would just need to decide whether to make
it public or protected.
Personally I would consider having a FromSomething only as an added
option, so I would not make the constructor protected. And I would
probably only do FromSomething if there were a *lot* of SomeThings, or I
needed to do construction by delegate.4. am I totaly wrong?
Well,.... you''re mixing up two separate issues,...hang on... can we even define constructors in interfaces today?...
god I even confused myself...
No, you can not.
You cannot instantiate an interface, since an interface is exactly a
*declaration* of what an instance *can*. Not a recepie for *how*, which is
done in a class (which can incidentally also contain state).
--
Helge
Hi,
I would still like to state that I realy want an interface to declare
static methods, even not for construction...
To the best of my knowledge, you cannot. Interfaces assume polymorphic
behavior in .NET, and static methods cannot be polymorphic.
Some general comments:
Interfaces are not used for construction as construction in 99% cases does
not need to be polymorphic. So if you need polymorphic construction, declare
an interface for a class factory and implement several factories each
encapsulating a different way of constructing instances.
As for static methods such as Graphics.FromHandle(), they have nothing to do
with interfaces, from my point of view. They are just a convenient way of
constructing objects, but they at the same time guarantee that the
construction behavior is not overridden if you implement a derived class.
--
Sincerely,
Dmitriy Lapshin [C# / .NET MVP]
Bring the power of unit testing to the VS .NET IDE today!
http://www.x-unity.net/teststudio.aspx
"Picho" <SP********@telhai.ac.il> wrote in message
news:uv**************@TK2MSFTNGP12.phx.gbl... Thanx for the reply Helge.
To sum things up, what you say is that there is no way that an interface
can enforce or dictate the way a class instanciate itself.
I am not arguing with what you said and I even accept the fact that
interfaces has to do with behavior.
but then again, we can talk all day long philosophicly wether construction
is not a behavior...
I would still like to state that I realy want an interface to declare
static methods, even not for construction...
Picho
"Helge Jensen" <he**********@slog.dk> wrote in message
news:41**************@slog.dk...Picho wrote:I want to give my classes the ability to staticly create instances,
simply because I think that calling a ''MyClass.FromSomething(Something
something)'' is more intuative than a constructor ''public
MyClass(Something something)''
For classes, you can just do that:
public class MyClass {
protected MyClass(...) {...}
public FromSomething(...) { return new MyClass(...); }
}
So, actually your problem doesn''t arise from trying to redefine
contruction. It arises from trying to do (what is often called) virtual
construction.this is just me...
Beware, that other people might not agree. Sometimes it''s just easier to
accept the common idioms, with the problems they offer, than to teach all
you work together with a new one (and sometimes, the new one has it''s own
problems :)anyway, as far as I know interfaces cannot define static members. this
pushed me into something I even like less - a class factory (even though
it is in some scenarios a good practice).
All polymorphic behaviour is on instances in C#, and you are asking for
virtual construction (which uses polymorphism). So, you need an instance,
commonly called a factory.1. Is there a more... ''elegant'' way for me to achieve this?
Not really, especially don''t fall into the pit of "prototyped
contruction" if you don''t actually *need* cloning.
You can do virtual construction using delegation (delegating to
FromSomething) but whether that is more elegant is debatable.2. is this somehing we want from C# (static member decleration in
interfaces)?
Perhaps, but I don''t think so in the sense that you ask for.
Since C# doesn''t allow free functions, it would be nice to be able to
stick static functions implemented purely in terms of the interface in
the interface declaration. This wouldn''t solve the problem of missing
free-functions for class-symmetric operations though.3. am I just being picky (should I just use constructors and forget my
intuition?)
You couldn''t get by just using constructors for virtual construction.
With regard to the "FromSomething(...)" idiom, you might want to ponder
whether it buys you enough to break out of the "new(...)" idiom, which is
widely used.
One thing which FromSomething *does* buy you is that you can do delegates
to the construction, something you cannot do with new.
Beware, also that you would want to write a contructor in the class even
if you do FromSomthing, you just would just need to decide whether to
make it public or protected.
Personally I would consider having a FromSomething only as an added
option, so I would not make the constructor protected. And I would
probably only do FromSomething if there were a *lot* of SomeThings, or I
needed to do construction by delegate.4. am I totaly wrong?
Well,.... you''re mixing up two separate issues,...hang on... can we even define constructors in interfaces today?...
god I even confused myself...
No, you can not.
You cannot instantiate an interface, since an interface is exactly a
*declaration* of what an instance *can*. Not a recepie for *how*, which
is done in a class (which can incidentally also contain state).
--
Helge
这篇关于MVP：接口中的静态方法。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
