Общедоступные статические данные, используемые в программе

Question

Примеры кода на C #, но это общий вопрос ОО.

Я знаю, что в соответствии с правилами ОО соединение классов должно быть сведено к минимуму, а члены должны быть по возможности конфиденциальными, и т. Д.

Рассмотрим этот пример:

Вы пишете эзотерическую программу, которая имеет некоторый набор данных (я не говорю о System.Data.DataSet ), который используется буквально в каждом аспекте программы. На самом деле, программа в основном существует только для загрузки, отображения, манипулирования и сохранения набора данных. Кроме того, в любой момент может быть загружен только один набор данных, и он загружается при открытии программы.

Если строго следовать правилам ОО, у нас будет

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

однако мы потенциально можем хранить public static Data член в Program, например.

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

С одной стороны, мы обменяли чуть более короткую сигнатуру функции на значительно улучшенную связь классов. С другой стороны, мы больше не передаем параметр данных практически каждой функции, везде .

Правильный ответ * , вероятно, таков: по возможности избегайте связывания классов. Локальные переменные данных являются просто указателями, поэтому накладные расходы памяти незначительны, а поскольку классы не связаны, они могут быть использованы в других местах позднее.

Хотя, с реалистической точки зрения, структура класса Data, вероятно, будет феноменально отличаться в другом приложении, так что вы не можете просто извлечь класс из этой программы и вставить его куда-нибудь еще без каких-либо настроек. Дополнительное время и усилия, необходимые для написания классов таким образом, чтобы их можно было просто отбросить, могут быть трудно оправдать заинтересованную сторону.

Сейчас я работаю над такого рода программами, и я использовал подход OO-canon: параметры данных передаются там, где это необходимо. Я минимизировал соединение классов с интерфейсом IData, чтобы обобщить набор данных для будущего повторного кода. использовать. Учитывая приложение, я почти уверен, что этот код никогда не будет использоваться повторно. Без этих дополнительных интерфейсов и абстракции программа работала бы точно так же, как это касается конечного пользователя, но для меня это представляло бы значительно меньше головной боли и времени разработки.

Что вы думаете об этом? Как вы думаете, оправданно ли тратить все дополнительное время на написание интерфейсов и обобщений, чтобы гарантировать, что классы по возможности отделены, особенно когда вы не можете видеть, как классы используются в других местах позже?

Answer 1

Не мучайся из-за этого.Шутки в сторону.

Программные парадигмы / шаблоны существуют для того, чтобы помочь нам, а не следовать догматически.

Вы ясно даете понять в своем вопросе, что считаете чрезмерное ослабление сцепления, и можете объяснить, почему.Поэтому не используйте его.

Answer 2

Как насчет использования одноэлементного шаблона для предоставления метода или свойства только для чтения для получения интерфейса 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);
    }
}

Некоторые предостережения: Приведенный выше пример кода полностью урезан, чтобы показать концепцию единого и общего интерфейса.Не реализована безопасность потоков, нет инициализации объекта данных и т. Д.

Answer 3

Что ж, в вашем тексте есть одно большое предположение: в программе всегда будет только один набор данных.Вы уверены, что условие будет сохраняться на все времена?Было время, когда текстовые процессоры могли содержать только один текст за раз.Сегодня стандартно иметь возможность открывать несколько файлов одновременно.Я также не удивлюсь, если первые веб-браузеры смогут открывать только одну веб-страницу за раз.Сегодня никто не будет использовать веб-браузер, в котором не может быть открыто несколько страниц одновременно.Я думаю, что объект, о котором можно сказать, что в программе наверняка будет только один из них, когда-либо, встречается довольно редко.В действительности, единственное, что я бы сделал глобальным объектом или синглтоном, - это фабрики объектов.

С другой стороны, передача объекта для каждого вызова функции мне тоже кажется излишней.Поэтому я бы пошел на второй план: пусть объекты запомнят этот «глобальный» объект, поэтому вам нужно только передать его через конструктор.Это ограничивает каждый отдельный объект одним объектом данных, но все же позволяет вам легко иметь несколько объектов данных в вашей программе, если вы когда-либо решите.