在 Main 中调用 运行 方法时使用什么设计模式？
What design pattern to use when calling Run method inside Main?
很多次我在程序的Main方法里面看到，独立于编程语言，下面的模式但是我不知道如何调用以及为什么这样使用。在 Main 中使用类似下面的内容可以实现什么购买？有没有alternatives/variations?
class Program
{
static void Main(string[] args)
{
new Program().Run();
}
private void Run()
{
var rep = new Repository();
dynamic data = rep.GetPerson();
Console.WriteLine(data.Name);
dynamic data2 = rep.GetPersonWrappedInAnonymousType();
Console.WriteLine(data2.Person.Name);
}
}
提前致谢。
编辑
此外，如果您在许多地方看到某些东西，是的，这是一种模式。这是模式的定义！
使 Program class 能够被实例化（而不是使一切都静态化）允许同时或在一个之后有多个 "programs" 运行ning另一个。这对于测试目的很有用。
这个class中可能有实例字段。通过每次测试都使用新实例 运行 与其他测试隔离。
现在，如果没有实例状态，这是没有用的。
如果这确实是一种模式，那么它可能与责任分离有关。您可以将其打包成一种方法：
class Program
{
static void Main(string[] args)
{
var rep = new Repository();
dynamic data = rep.GetPerson();
Console.WriteLine(data.Name);
dynamic data2 = rep.GetPersonWrappedInAnonymousType();
Console.WriteLine(data2.Person.Name);
}
}
但是编写它的人想要将程序的 "start"（标准 "main" 入口点）与要执行的实际任务（get person、getpersonwrapped ..).
"Program" class 的实例化和对象是纯粹主义者的恕我直言。在一个项目中实际拥有这些对象的多个实例是非常罕见的。但是，Java/C# 粉丝经常声称 OOP "everything is an object" 并鄙视 static 和不受对象约束的一切。 static void main 对他们来说是一个巨大的痛苦，所以他们很快就用这种方式对程序 class 进行了去静电处理。我不想对此做出判断，但我同意 HansPassant 的评论 - 看起来很狂热。但对我来说，这没什么区别，只是外观上的微小变化，正如我所说，尤其是对于计划 class 来说，这几乎无关紧要。但我不会称其为 "design pattern"。 "code style" 或 "implementation pattern"，但不是 "design"。在创建和 运行 一个 "run" 方法时确实没有架构和算法。
如果你添加更多的位，一些定义 运行() 的通用接口，一些在运行时选择正确的程序实现，那么也许你可以进入，我不知道，也许设计模式称为 "policy" 或 "strategy".. 但这大多被夸大了
不幸的是没有人愿意回答我的问题所以我不得不接受我自己的答案。但是我确实相信有些人可以对此给出更多基于经验的答案。所以答案是肯定的，这是一种模式！叫做The command pattern.
来自 Wikipedia Article :
In object-oriented programming, the command pattern is a behavioral design pattern in which an object is used to represent and encapsulate all the information needed to call a method at a later time. This information includes the method name, the object that owns the method and values for the method parameters.
Four terms always associated with the command pattern are command, receiver, invoker and client. A command object has a receiver object and invokes a method of the receiver in a way that is specific to that receiver's class. The receiver then does the work. A command object is separately passed to an invoker object, which invokes the command, and optionally does bookkeeping about the command execution. Any command object can be passed to the same invoker object. Both an invoker object and several command objects are held by a client object. The client contains the decision making about which commands to execute at which points. To execute a command, it passes the command object to the invoker object.
Using command objects makes it easier to construct general components that need to delegate, sequence or execute method calls at a time of their choosing without the need to know the class of the method or the method parameters. Using an invoker object allows bookkeeping about command executions to be conveniently performed, as well as implementing different modes for commands, which are managed by the invoker object, without the need for the client to be aware of the existence of bookkeeping or modes.
很多次我在程序的Main方法里面看到，独立于编程语言，下面的模式但是我不知道如何调用以及为什么这样使用。在 Main 中使用类似下面的内容可以实现什么购买？有没有alternatives/variations?
class Program
{
static void Main(string[] args)
{
new Program().Run();
}
private void Run()
{
var rep = new Repository();
dynamic data = rep.GetPerson();
Console.WriteLine(data.Name);
dynamic data2 = rep.GetPersonWrappedInAnonymousType();
Console.WriteLine(data2.Person.Name);
}
}
提前致谢。
编辑
此外，如果您在许多地方看到某些东西，是的，这是一种模式。这是模式的定义！
使 Program class 能够被实例化（而不是使一切都静态化）允许同时或在一个之后有多个 "programs" 运行ning另一个。这对于测试目的很有用。
这个class中可能有实例字段。通过每次测试都使用新实例 运行 与其他测试隔离。
现在，如果没有实例状态，这是没有用的。
如果这确实是一种模式，那么它可能与责任分离有关。您可以将其打包成一种方法：
class Program
{
static void Main(string[] args)
{
var rep = new Repository();
dynamic data = rep.GetPerson();
Console.WriteLine(data.Name);
dynamic data2 = rep.GetPersonWrappedInAnonymousType();
Console.WriteLine(data2.Person.Name);
}
}
但是编写它的人想要将程序的 "start"（标准 "main" 入口点）与要执行的实际任务（get person、getpersonwrapped ..).
"Program" class 的实例化和对象是纯粹主义者的恕我直言。在一个项目中实际拥有这些对象的多个实例是非常罕见的。但是，Java/C# 粉丝经常声称 OOP "everything is an object" 并鄙视 static 和不受对象约束的一切。 static void main 对他们来说是一个巨大的痛苦，所以他们很快就用这种方式对程序 class 进行了去静电处理。我不想对此做出判断，但我同意 HansPassant 的评论 - 看起来很狂热。但对我来说，这没什么区别，只是外观上的微小变化，正如我所说，尤其是对于计划 class 来说，这几乎无关紧要。但我不会称其为 "design pattern"。 "code style" 或 "implementation pattern"，但不是 "design"。在创建和 运行 一个 "run" 方法时确实没有架构和算法。
如果你添加更多的位，一些定义 运行() 的通用接口，一些在运行时选择正确的程序实现，那么也许你可以进入，我不知道，也许设计模式称为 "policy" 或 "strategy".. 但这大多被夸大了
不幸的是没有人愿意回答我的问题所以我不得不接受我自己的答案。但是我确实相信有些人可以对此给出更多基于经验的答案。所以答案是肯定的，这是一种模式！叫做The command pattern.
来自 Wikipedia Article :
In object-oriented programming, the command pattern is a behavioral design pattern in which an object is used to represent and encapsulate all the information needed to call a method at a later time. This information includes the method name, the object that owns the method and values for the method parameters.
Four terms always associated with the command pattern are command, receiver, invoker and client. A command object has a receiver object and invokes a method of the receiver in a way that is specific to that receiver's class. The receiver then does the work. A command object is separately passed to an invoker object, which invokes the command, and optionally does bookkeeping about the command execution. Any command object can be passed to the same invoker object. Both an invoker object and several command objects are held by a client object. The client contains the decision making about which commands to execute at which points. To execute a command, it passes the command object to the invoker object.
Using command objects makes it easier to construct general components that need to delegate, sequence or execute method calls at a time of their choosing without the need to know the class of the method or the method parameters. Using an invoker object allows bookkeeping about command executions to be conveniently performed, as well as implementing different modes for commands, which are managed by the invoker object, without the need for the client to be aware of the existence of bookkeeping or modes.