Рекомендации по шаблону проектирования: использование массива пользовательских объектов в качестве одиночного

Question

После долгих занятий я начинаю кодировать свое первое приложение.

В моем коде у меня есть класс под названием "Измерение". Я хочу реализовать массив измерений. Этот массив измерений должен быть доступен для нескольких контроллеров представления, поэтому я создал для него собственный класс MeasurementsArray и превратил его в одноэлементный.

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

Если бы не факт, что массив измерений должен быть одноэлементным, казалось бы, этот массив принадлежит классу "Measurement" как метод класса. Но я понимаю, что может быть только один экземпляр класса, когда он является синглтоном.

Но каким-то образом наличие отдельного класса с именем "MeasurmentsArray" кажется мне немного хакерским.

Мой вопрос:

Правильно ли я подхожу к этому или я что-то упускаю?

Если мне нужно разделить массив Measurements на отдельный класс, чтобы он был единичным, будет ли MeasurementsArray подходящим именем класса? Если нет, пожалуйста, предоставьте соглашение об именах, которое вы бы использовали для такой ситуации.

Редактировать: после некоторых первоначальных ответов могут помочь некоторые разъяснения относительно функции приложения.

Это фитнес-приложение, которое записывает, сохраняет и отслеживает процент жира и массу тела. Каждый раз, когда пользователь записывает свой жир и вес, он становится экземпляром класса «Измерение». Массив измерений необходим для отслеживания изменений веса и жира с течением времени. Одиночка необходима, потому что нескольким контроллерам представления необходим доступ к массиву.

Answer 1

Требуется одноэлементное, потому что нескольким контроллерам представления необходим доступ к массиву.

Существуют и другие, более эффективные способы обмена данными между объектами, чем использование одиночного.

Контроллеры представления обычно создаются либо делегатом приложения, либо другим контроллером представления.Модель данных приложения (в данном случае это ваш массив измерений) часто также создается эфиром делегатом приложения.Поэтому, когда делегат приложения создает контроллер представления, он также может дать этому контроллеру указатель на модель данных.Если этот контроллер создает какие-либо контроллеры представления, он также может поделиться своим указателем на модель данных.

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

Answer 2

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

Похоже, вы, возможно, уже реализуете что-то похожее на шаблон Model-View-Controller , что было бы уместно. В этом контексте этот массив измерений является частью вашей модели, и для него может иметь смысл быть отдельным классом, но, вероятно, нет необходимости, чтобы он был единичным.

Имя MeasurementsArray зависит от реализации. Я был бы более склонен назвать это просто Measurements или дать ему имя, отражающее то, что измеряют измерения.

На самом деле мне интересно, как называется ваш Measurement класс. Что это измеряет? Что это на самом деле представляет?

Если вы опубликуете некоторый код, мы могли бы предоставить более конкретные идеи.

Основываясь на своем обновлении и немного размышлений, вы можете подумать о Шаблон репозитория . Вместо того, чтобы ваши контроллеры хранили массив, у них есть доступ к хранилищу, из которого они могут его получить.

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

Вместо того, чтобы этот репозиторий был синглтоном (хотя это, безусловно, иногда делается), его лучше просто создать один раз, а затем ввести во все, что ему нужно. См. http://en.wikipedia.org/wiki/Dependency_injection и блог дяди Боба

Answer 3

Если я вас правильно понимаю, массив измерений представляет прошлые измерения конкретного пользователя.
Если это так, вы вообще не ищете синглтон.
Помните, что синглтон - это одинзначение PER APPLICATION, и здесь вы ищете одно значение PER USER.
Дон Роби абсолютно прав - измерения, вероятно, являются свойством класса User.например (я использую нотацию c #, но вы понимаете, как это работает ...):

public class User
{
    public string Name {get; set;}
    public int Id {get; set;}
    public Measurement[] Measurements {get; set;} //one array per-user... 
}

Answer 4

Я чувствую, что отдельный класс, вероятно, является избыточным, если у него нет нескольких собственных методов, и в этом случае это может быть оправдано.Эта проблема может быть просто артефактом структуры вашего приложения, которая еще не была четко определена.Будут ли данные постоянными между сеансами?Если это так, будет ли класс «manager», в который вы можете поместить свойство для получения массива;что-то вроде allMeasurements в классе MeasurementStore?Другой вариант - сохранить массив в делегате приложения.

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

Редактировать: Чтобы уточнить, нет ничего "неправильного" в вашем подходе;возможно, есть более приятные способы сделать это.