关于部分方法实施 [英] Regarding partial method implementation

问题描述

我对vb.net或C＃的部分类中的部分方法实现有一个快速的问题。



我们知道部分方法实现是可选的，但是它的声明是强制性的。



如果不需要实现，为什么我们需要声明部分方法。为什么即使我们不提供任何实现，.NET编译器也不会抛出任何编译错误？



以上是否有任何实际实现？



一如既往地感谢你的时间支持。

I have quick question regarding partial method implementation in partial classes of either vb.net or C#.

We know partial method implementation is optional however its declaration is mandatory.

Why do we need to declare a partial method if its implementation is not required. Why .NET compiler will not throw any compile error even we don't provide any implementation?

Are there any practical implementation to the above?

As always thanks for your time support.

推荐答案

你应该清楚地知道，部分方法只不过是语法糖，它们不会影响任何其他功能;它们的设计只是为了提高代码的可读性，并使开发过程中的一些步骤更加方便。只是方便，没有任何功能。绝对没有一个强大的功能Krunal尝试在解决方案1中归因。


请参阅：http://en.wikipedia.org/wiki/Syntactic_sugar [ ^ ]。



有一些非实现方法的可能性是一个有点微妙的时刻，所以我将不得不说明它一些例子。简而言之：这不是一件值得认真考虑的事情。 :-)



让我们从最极端的非实现方法开始：让我们声明它甚至调用，而无需实现。由此产生的行为是不寻常的。让我们看看：

You should clearly understand that partial methods are nothing but syntactic sugar, they don't affect any additional functionality, ever; they are designed only to improve code readability and make some steps on development process a bit more convenient. Only convenience, nothing about functionality. And absolutely none of those powerful feature Krunal tried to attribute in Solution 1.

Please see: http://en.wikipedia.org/wiki/Syntactic_sugar[^].

The possibility to have some non-implemented method is a somewhat delicate moment, so I'll have to illustrate it on some examples. In brief: this is not something to be taken too seriously. :-)

Let's start from the most extreme case of non-implemented method: let's declare it and even call, without implementation. The resulting behavior is something unusual. Let's see:

public partial class PartialDemo {
    partial void Test(); //important: the method is private!
    internal PartialDemo() {
        Test(); // simply does nothing, can work during runtime
    } //PartialDemo
} //class PartialDemo

public partial class PartialDemo {
    // no implementation of void Test() yet
} //class PartialDemo

特别注意我的代码注释，它们几乎解释了所有内容。



这就是：编译器静态检测到测试没有实现。它以下列方式将代码编译为IL：好像该方法从未声明并调用。每一段代码都表现得好像从未提及 Test 。



现在，问题是：为什么是这样做了吗？对于一些人来说，它会很方便，但我个人并不需要这个功能。这只是为了一个简单的目的：暗示实现将在稍后编写，但没有它，代码仍然可以编译甚至执行。例如，我有习惯经常重新编译代码，因为 - 为什么不呢？我写了一行并重新编译。我写的声明没有实现 - 它编译。所以，对我来说，这有点方便，但如果没有它，我会轻易离开。我还建议添加此功能（不是部分方法，但保留一些方法未实现的能力）是在C / C ++文化的影响下决定的，其中有类似的功能，虽然不是很安全。



你应该理解的一件事：上面写的代码毫无意义。如果没有实现任何可想到的功能，你永远不应该写它。您可以将此视为可编辑的评论说：稍后实施。所以，如果你以后再也没有添加实现，那么它将无法在第一时间使用该功能。



现在，所有这些功能（没有实现）只能部分未实现的方法 private 。如果是 public 或 protected （并且该方法不是 abstract ，当然），汇编根本就没有意义。 Public假定您可以从其他程序集调用该方法。但是其他程序集是单独编译的;它不能知道在一种情况下该方法存在而在其他情况下则不存在。这是一个真正的电话;和电话是一个电话。即使使用 internal 也无法编译。这个设计决定并不像 public 或 protected 那么重要，但是合理。让我们看看：

Pay special attention for my code comments, they explains pretty much everything.

This is what happens: the compiler statically detects that Test has no implementation. It compiles the code into IL in the following way: as if the method was never declared and called. Every piece of code behaves as if Test was never mentioned.

Now, the question is: why is is done so? For some, it would be convenient, but I personally don't need this feature much. This is done for one simple purpose: it is implied that the implementation will be written later, but without it, the code would still compile and even executed. I, for example, have a habit to re-compile code excessively often, because — why not? I write a line and re-compile. I write declaration without implementation — it compiles. So, for me, this is a bit of convenience, but I would easily leave without it. I would also suggest that adding this feature (not partial methods, but the ability to keep some methods not implemented) was decided under the influence of C/C++ culture, where there is a similar feature, albeit not really safe.

One thing you should understand: the code written above makes no sense. You never should write it without implementation for any thinkable functionality. You can consider this almost as a "compilable comment" saying: "implement it later". So, if you never add implementation later, it would defeat the purpose of using the feature in first place.

Now, all this feature (having no implementation) will work only of the partial non-implemented method is private. If it is public or protected (and the method is not abstract, of course), the compilation would make no sense at all. Public assumes that you can call the method from other assembly. But other assembly is compiled separately; it cannot "know" that in one case the the method exist and in other case it is not. This is a real call; and a call is a call. It won't compile even with internal. This design decision is not so critically important as with public or protected, but is reasonable. Let's see:

public partial class PartialDemo {
    internal partial void First(); // WON'T COMPILE
    protected partial void Second(); // WON'T COMPILE
    public partial void Third(); // WON'T COMPILE
} //class PartialDemo

public partial class PartialDemo {
} //class PartialDemo

每个非私有方法都会在添加实现后立即编译。



因此，此功能无法解决任何插件功能。插件可以基于反射。



它也不会影响自动生成代码的可能性。请记住，即使在引入部分类型之前，自动生成的代码也几乎相同，只在一个文件中。那是非常难以理解的。此外，它激发了用于更新代码与自动生成代码所在的文件相同的文件。它很容易造成很多混乱。对于部分类型，它更安全;如果出现开发人员的错误，更容易找到目的。我个人经常在单独的文件中添加我自己的部分声明，包括自动生成的部分。







但是，Microsoft建议并使用自动生成代码的有趣方式，完全基于我上面描述的机制的方式。它在解决方案3中的MSDN文章参考中描述，第二个链接。感谢 pwasswer 获取此链接。请看看它。



再次，这个想法是一样的：隔离自动生成的代码和开发人员的代码。在此方法中，自动生成的代码使用未实现的部分方法。在单独的文件中，在同一个类的另一部分中，用户可以向这些方法添加实现。通过重新编译，对这些方法的不存在的调用将替换为实际调用。这样，用户可以通过在单独的部分中添加代码将调用注入自动生成的代码中，因此可能在单独的文件中。你可以把它想象成覆盖的编译时方式，它不是像OOP那样基于动态调度，而是基于早期绑定。它没有OOP功能，根本没有，但它没有虚拟方法调用的那个（微小的）开销。嗯...



重要的是要理解，从功能的角度来看，这种机制100％等同于仅编辑自动生成的代码，添加一些代码它并重新编译。但是自动生成的代码不是真正的源代码，在实践中，它不应该被编辑。因此，从项目维护的角度来看，它产生了很大的不同：自动生成和开发人员代码的隔离。



所以，我推测这种技术可能是.NET团队在没有实现的情况下引入部分方法的主要原因。我不确定我是否喜欢它，因为对我来说，为了实现基于自动生成代码的技术这样的次要目标，它看起来像添加 ad hoc 功能。



[结束编辑]





它只是提高了代码的可读性和易用性如果合理使用，可以进行维护。纯粹的语法糖，不再。

-SA

Each of those non-private methods will compile as soon as you add its implementation.

So, this feature cannot solve as any plug-in facility. Plug-ins can be based on reflection.

It also does not affect the possibility to auto-generate code. Remember, even before partial types were introduced, the auto-generated code was pretty much the same, only in one single file. That was very unreadable. Besides, it provoked used to update with the code the same file where the auto-generated code is. It could easily create a lot of mess. With partial types, it's a lot safer; in case of developer's mistakes, it's much easier to find ends. I personally often add my own partial declarations to types, in separate files, including auto-generated ones.



However, Microsoft suggests and interesting way of using auto-generated code, the way fully based on the mechanism I described above. It is described in the MSDN article reference in Solution 3, second link. Credit to pwasswer for this link. Please see it.

Again, the idea is the same: isolation of the auto-generated code and the developer's code. In this approach, the auto-generated code uses unimplemented partial methods. In a separate file, in the other part of the same class, the user can add implementation to such methods. With recompilation, the non-existent calls to such methods are replaced with actual calls. This way, the user can inject the calls into auto-generated code by adding code in a separate part, and, hence, possibly in a separate file. You can think of it as of compile-time way of overriding which is not based on dynamic dispatch like in OOP, but is based on early binding. It does not have the OOP power, not at all, but it does not have that (tiny) overhead of the call of the virtual method. Hm…

It's important to understand that, from the stand point of functionality, this mechanism is 100% equivalent to just editing of the auto-generated code, adding some code to it and recompiling. But auto-generated code is not the real source code, in practice, it should not be edited. So, from the standpoint of project maintenance, it makes a big difference: isolation of auto-generated and developer's code.

So, I would speculate that this technique could be the major reason for .NET team to introduce partial methods without implementation. I am not sure I like it, because to me, it looks like adding an ad hoc feature for the sake of such a secondary goal as the techniques based on auto-generated code.

[END EDIT]


It just improves readability of code and ease up maintenance, if used reasonably. Pure syntactic sugar, no more.

—SA

我读过对目前的讨论感兴趣。它引导我到这些观点：



1. msdn不是理解为什么存在部分方法的最好方法。

2.引用来自其他地方的逐字记录有其危险性。



这里的最佳答案给出了一些引导并引用了LINQ：

http://stackoverflow.com/questions/42187/how-are-partial-methods -used-in-c-sharp-3-0 [ ^ ]



这进一步解释了这一点：

http://msdn.microsoft.com/en-us/library /bb546176(v=vs.110).aspx [ ^ ]



最后这个：

http://stackoverflow.com/questions / 3628804 /为什么你需要部分方法在c-can-events中用来实现同一目标 [ ^ ]

I read with interest the discussion so far. It leads me to these points:

1. The msdn is not the best way to understand why partial methods exist.
2. Quoting verbatim from elsewhere has its dangers.

The top answer here gives some leads and refers to LINQ:
http://stackoverflow.com/questions/42187/how-are-partial-methods-used-in-c-sharp-3-0[^]

This explains that point further:
http://msdn.microsoft.com/en-us/library/bb546176(v=vs.110).aspx[^]

Finally this:
http://stackoverflow.com/questions/3628804/why-you-need-partial-methods-in-c-can-events-be-used-to-achieve-the-same-goal[^]

部分方法类似于类中的常用方法，除了用户可能实现也可能不实现它。部分方法仅在具有实现时才执行。没有实现的方法有什么用？这些方法可以作为插入代码的钩子，例如采用生成类的代码生成工具。它可以有部分方法，类的用户可以实现它们或只留下它们。如果用户离开它们，编译器不会将它们包含在最终代码中，从而提高整体性能。如果用户为它们编写了一些实现代码，那么它们就像普通方法一样。



使用部分方法可以提高性能因为任何编译器从汇编代码中删除对没有植入的部分方法的调用。部分方法旨在解决由代码生成工具引起的主要问题。使用子类可以实现类似的功能，但它会产生性能开销，而且部分方法更容易理解。

请参阅整篇文章这里 [ ^ ]。



部分方法对自定义自动生成的代码特别有用通过该工具。每当工具生成代码时，工具可能会推迟一些部分方法，这些方法的实现由开发人员决定。



例如，去这里 [ ^ ]，此处 [ ^ ]和此处 [ ^ ]

然后 MSDN [ ^ ]就在那里。 :)



-KR

A partial method is like a usual method in a class except that the user may or may not implement it. A partial method gets executed only when it has an implementation. What is the use of a method that does not have an implementation? Such methods can act as hooks for plugging in code, for instance take a code generation tool that generates a class. It can have partial methods, the user of the class can implement them or just leave them. If the user leaves them, the compiler does not include them in the final code thus improving the overall performance. If the user writes some implementation code for them, then they act as normal methods.

The use of partial methods improves the performance because any call to a partial method without an implantation is removed from the assembly code by the compiler. Partial methods are intended to solve a major problem that is caused by code-generation tools. Similar functionality can be achieved with sub classing, but it creates a performance overhead and moreover partial methods are more clear to understand.
See the whole article here[^].

Partial methods are particularly helpful for customizing auto generated code by the tool. Whenever the tool generate the code then tool may decalare some partial method and implementation of these methods is decided by the developers.

For Example, go here[^], here[^] and here[^]
And yet MSDN[^] is there. :)

-KR

这篇关于关于部分方法实施的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！