Oop 在整个程序中使用的公共静态数据

代码示例是C#，但这是一个一般的OO问题

我知道根据OO规则，类耦合应该最小化，成员应该尽可能保持私有，等等

考虑这个例子：

您正在编写一个深奥的程序，其中包含某种数据集（我不是在谈论System.data.DataSet），它在程序的各个方面都被使用。事实上，程序的存在基本上只是为了加载、显示、操作和保存数据集。此外，任何时候只能加载一个数据集，并且在程序打开时加载

如果我们严格遵守OO规则，我们会

public void ShowSomeGraphs(IData data)
{
  // do stuff with data which implements IData
}

但是，我们可以在

程序

中潜在地存储

公共静态数据

成员

public void ShowSomeGraphs()
{
  // do stuff with Program.Data
}

一方面，我们用稍微短一点的函数签名换取了大大增加的类耦合。另一方面，我们不再将数据参数传递给几乎所有的函数，任何地方

正确的答案可能是：尽可能避免类耦合。本地数据变量只是指针，因此内存开销可以忽略不计，并且由于类是解耦的，因此可以在以后的某个日期在其他地方使用它们

尽管现实地说，数据类的结构在不同的应用程序中可能会有显著的不同，所以你不能从这个程序中提取一个类，然后不做任何调整就把它放到其他地方。编写类所需的额外时间和精力可能很难向涉众证明

我现在正在开发这类程序，我使用了OO canon方法：在需要的地方传递数据参数。我使用IData接口最小化了类耦合，从而概括了数据集，以便将来代码重用。考虑到应用程序，我几乎可以肯定这段代码永远不会被重复使用。如果没有这些额外的接口和抽象，就最终用户而言，该程序的工作方式将完全相同，但对我来说，这将大大减少麻烦和开发时间

你觉得这个怎么样？您认为花费所有额外的时间编写接口和泛化以确保类在可能的情况下解耦是合理的吗，特别是当您以后看不到其他地方正在使用的类时？

使用提供方法或只读属性以获取IData接口如何？这样，您只需耦合到一个非常精简的单例类，所有与数据集的交互都是通过IData接口完成的

（我肯定会避免紧耦合。即使你不打算对这个应用做太多的工作，也有可能在开发过程中遇到问题，这将迫使你接触比通过界面访问数据多得多的代码。）

上述单例解决方案的代码示例：

using System;

public class MyClass {
    public static void Main() {
        // simple usage:
        Console.WriteLine("From Main: " + Singleton.Instance.IMyData.GetData());
        // client code from another type:
        new ClientObj().DoWork();
        Console.ReadKey();
    }
}

public sealed class Singleton {
    // standard singleton stuff:
    private static readonly Singleton _instance = new Singleton();
    private Singleton(){}
    public static Singleton Instance {get { return _instance; }}
    // data interface stuff:
    private MyData _myData = new MyData();
    public IData IMyData {get { return _myData; }}
}

// the interface:
public interface IData {
    string GetData();
}

// concrete implementation of the data class
public class MyData : IData {
    public string GetData() {return "Hello World!";}
}

// example of a type using the singleton and the IData interface
public class ClientObj {
    public void DoWork() {
        IData data = Singleton.Instance.IMyData;
        string str = data.GetData();
        Console.WriteLine("From other obj: " + str);
    }
}

---

一些注意事项：上面的代码示例被完全剥离，以展示单例和共享接口的概念。没有实现线程安全，没有初始化数据对象等。

好吧，在你的文本中有一个很大的假设：程序中始终只有一个数据集。你确定这种情况会一直持续下去吗？曾经有一段时间，文字处理器一次只能保存一个文本。如今，能够同时打开多个文件已成为标准。如果第一代网络浏览器一次只能打开一个网页，我也不会感到惊讶。今天，没有人会使用不能同时打开多个页面的web浏览器。我认为那种你可以说在程序中肯定只有一个的对象是非常罕见的。事实上，我唯一能创建全局对象或单例的就是对象工厂

---

另一方面，对我来说，为每个函数调用传递对象似乎也太过分了。因此，我会采取中间立场：让对象记住“全局”对象，这样您只需通过构造函数传递它。这将每个对象限制为一个数据对象，但仍然允许您在您的程序中轻松地拥有多个数据对象，如果您决定的话。

不要为此烦恼。真的

软件范例/模式的存在是为了帮助我们，而不是教条式地遵循

---

P>你在你的问题中明确指出你认为松耦合过度，你可以证明为什么。因此，不要使用它

这确实是一个意见问题。这是一个代码风格与时间的问题。程序应该能够工作，并且有尽可能少的bug。代码样式旨在降低复杂性，使代码更易于理解，更适合更改，并在项目之间可重用。真的取决于你决定做什么do@Ozzah：我在我的答案中添加了一个代码示例，以显示实现单例解决方案的速度和容易程度，从而允许您从客户端代码轻松访问数据接口。您所说的是公开使用的软件。每个人都使用文字处理器，因此使用风格千差万别。我的程序只供我公司的两个人使用，其他地方没有。我非常确信，永远不会需要一个以上的数据集。我为公司编写的很多程序都是这样的，所以我想这并不罕见。“Agonise”是一个有点强的词。我一直对这些严格的规则有自己的看法，这些规则在很多情况下可能有意义，但不一定在所有情况下都有意义。作为我所在部门唯一的程序员，我与我的同类没有太多的联系，我只是好奇其他有经验的人的意见是什么。