Реализация класса "LazyProperty" - это хорошая идея?

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

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

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

Я не думаю, что беспокойство о том, что разработчик не понимает, - хороший аргумент против того, чтобы делать что-то подобное ...

Если вы так думаете, то ничего не можете сделать из-за страха, что кто-то не поймет, что вы сделали

Вы можете написать учебник или что-то еще в центральном репозитории, у нас есть вики для таких заметок

В целом, я думаю, что это хорошая идея для реализации (не желая начинать споры о том, является ли ленивая загрузка хорошей идеей или нет)

Мне нравится ваше решение, поскольку оно очень умное, но я не думаю, что вы сильно выиграете, используя его. Ленивая загрузка частного поля в общедоступное свойство - определенно место, где код может быть продублирован. Однако мне всегда казалось, что это шаблон для использования, а не код, который нужно реорганизовать в обычное место.

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

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

Конечно, вы, по крайней мере, хотели бы, чтобы LazyPropery<T> был типом значения, иначе вы добавили память и давление сборщика мусора для каждого «лениво загружаемого» свойства в вашей системе.

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

В этом случае я создаю Фрагмент кода Visual Studio. Я думаю, это то, что тебе действительно следует делать.

Например, когда я создаю элементы управления ASP.NET, у меня часто есть данные, которые много хранятся в ViewState, поэтому я создал такой фрагмент кода:

public Type Value
{
    get
    {
        if (ViewState["key"] == null)
            ViewState["key"] = someDefaultValue;
        return (Type)ViewState["key"];
    }
    set{ ViewState["key"] = value; }
}

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

Лично я не думаю, что класс LazyProperty как таковой предлагает достаточно ценности, чтобы оправдать его использование, особенно с учетом недостатков его использования для типов значений (как упомянул Кент). Если вам нужны другие функции (например, сделать его многопоточным), это может быть оправдано как класс ThreadSafeLazyProperty.

Что касается неявного свойства, мне больше нравится свойство «Значение». Это немного больше набора текста, но для меня это намного понятнее.

Просто чтобы быть чересчур педантичным:

Предлагаемое вами решение, чтобы избежать повторения кода:

private LazyProperty<HeavyObject> first = 
  new LazyProperty<HeavyObject>(() => new HeavyObject { MyProperty = Value });
public HeavyObject First { 
  get { 
    return first; 
  } 
}

На самом деле символов больше, чем код, который вы не хотели повторять:

private HeavyObject first;
public HeavyObject First { 
  get {
    if (first == null) first = new HeavyObject { MyProperty = Value };
    return first;
  }
}

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

Не делай этого вообще.

Как правило, использование такого типа ленивых инициализированных свойств является допустимым выбором дизайна в одном случае: когда SomeOperation(); является дорогостоящей операцией (с точки зрения ввода-вывода, например, когда требуется обращение к базе данных или с точки зрения вычислений), И когда вы уверены, что вы часто будете НЕ нужен доступ к нему.

Тем не менее, по умолчанию вы должны пойти на активную инициализацию, и когда профилировщик скажет, что это ваше узкое место, измените его на ленивую инициализацию.

Если вам хочется создать такую ​​абстракцию, это запах.

Думаю, это интересная идея. Сначала я бы порекомендовал вам скрыть свойство Lazy Property от вызывающего кода. Вы не хотите просачиваться в модель своей предметной области, что оно ленивое. Что вы делаете с неявным оператором, так что оставьте это.

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