【问题标题】:Static method with instance parameter OR instance method with no parameter?带实例参数的静态方法还是不带参数的实例方法?
【发布时间】:2012-07-19 11:53:33
【问题描述】:

可能重复:

Instance method vs. static method with ref parameter

如果我有一个类Employee,并且有一个方法AddEmployee 可以将员工添加到数据库中。我可以采用的方法有很多,一种是这样的,

protected void AddEmployee(SQLConnection con)
{
    // this is an instance method, 
    // connection is passed in parameter
    // add this class to database, using the connection
}

我会这样称呼它

   var emp = new Employee();
   // set its properties
   emp.AddEmployee(theSQLConnectionObject);

另一种方法是,我创建一个静态方法,然后传递一个Employee 类的实例和一个SQLConnecion,然后将那个雇员类的实例添加到数据库中,比如这个

static protected void AddEmployee(Employee emp, SQLConnection Con)
{
    // this is static method
    // connection again in parameter
    // add emp class to database, using the connection
}

这可以添加为,

var emp = new Employee();
// set its properties
Employee.AddEmployee(emp, theSQLConnectionObject);

我想知道哪种方法好,您更喜欢哪种方法,为什么?另外,我想知道特定于 C#,相关问题不是特定于语言的。

现在,由于这部分,我在开始时说可能会出现重复。
我正在阅读 CLR Via C#,在第 8 章节类型构造函数中,它是这样的

编译方法时,JIT 编译器确定它必须发出的天气 在方法中执行类型构造函数的调用。如果 JIT 编译器决定发出调用,它必须决定它应该在哪里发出 通话。有两种可能

  • 精确语义,在创建第一个实例的代码之前或在访问 类成员的非继承字段。

  • Before-field-init 语义,在代码首先访问静态字段或静态或实例方法之前的某个时间发出代码,或调用 实例构造函数。

更多的描述,然后给出一个性能比较的例子,性能上有很大的差异,为了简洁,我不包括,但如果有人想要,评论,我会更新问题。
例子结束后,他继续

当 C# 编译器看到一个类 使用内联初始化的静态字段,编译器发出 元数据类型定义表中的 before-field-init。当它看到一个 具有显式构造函数的类,它不会发出 before-field-into 到元数据中。

现在,如果我的 Employee 类中有一个静态字段,情况会有什么不同?据我所知,会有4种不同的情况

  • AddEmployee 是实例,类没有静态构造函数

  • AddEmployee 是实例,类有一个静态构造函数

  • AddEmployee 是静态的,类没有静态构造函数

  • AddEmployee 是静态的,类有一个静态构造函数

假设在 buttonClick 处调用方法 AddEmployee 并且每次都创建一个员工实例(在这两种情况下,无论是否为静态方法,因为它们都需要一个实例),因此每次创建一个新实例时。另外,如果这个AddEmployee 的名称有所不同,这有关系吗?

【问题讨论】:

  • 首先考虑架构/可读性。当性能成为问题时考虑性能。 (个人意见)

标签: c# performance types clr jit


【解决方案1】:

抛开性能不谈,我更愿意将保存 Employee 的责任转移到另一个类。符合 SRP,也许还有一点 OCP。

【讨论】:

  • 很抱歉听起来太笨了,但是什么是 SRP 和 OCP?
  • 对不起,不是一个非常包容的答案。单一职责原则和开闭原则。了解更多 Google SOLID OO 设计原则。
【解决方案2】:

我建议你在这种情况下不要使用静态方法。在许多情况下,静态方法是非常丑陋的解决方案。更好的方法是使用实​​例方法创建数据映射器类,例如,当您决定需要使用继承来扩展数据映射器类的行为以获得不同的保存操作时,它可以为您提供帮助。一开始不要考虑性能,尤其是在这个时刻,优秀程序员的经验告诉我们,当你面对它时,我们需要用性能来解决问题。如果您优化应用程序的每一行代码,您将根本无法完成您的应用程序。通常,有时有 2-3 个地方需要我们提高代码的性能,但有时根本没有这种地方。因此,首先尝试考虑您的设计,考虑它的可读性和可扩展性。

【讨论】:

  • 这不正是Raphel Althaus在评论中所说的吗?
猜你喜欢
  • 1970-01-01
  • 2018-01-02
  • 1970-01-01
  • 1970-01-01
  • 2015-11-25
  • 1970-01-01
  • 1970-01-01
  • 2014-10-20
  • 1970-01-01
相关资源
最近更新 更多