О дизайне
От: Тепляков Сергей Владимирович США http://sergeyteplyakov.blogspot.com/
Дата: 01.04.16 15:06
Оценка: 1020 (6)
Статья:
О дизайне
Автор(ы): Тепляков Сергей Владимирович
Дата: 27.10.2015
В статье рассматриваются различные аспекты дизайна приложения и влияние этих аспектов на выбор верного варианта дизайна.


Авторы:
Тепляков Сергей Владимирович

Аннотация:
В статье рассматриваются различные аспекты дизайна приложения и влияние этих аспектов на выбор верного варианта дизайна.
Re: О дизайне
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.04.16 01:18
Оценка: +2
Здравствуйте, Тепляков Сергей Владимирович, Вы писали:

По поводу:

«Нет, не стоит!», но если данный класс является библиотечным или просто он инстанцируется миллионы раз, то мой ответ уже не будет столь однозначным.

Хоть 10 миллионов раз. Код джитится один раз и держится в одном экземпляре. Совет Рихтера просто идиотский. Экономия на спичках. И то если она есть. Ведь наличие конструктора и его вызов отнюдь не бесплатны. Если он не заклинится, будут инструкции его вызова и возврата. Плюс он раздувает метаданные.

Короче, пример плохой. Хотя поднимаемый вопрос важен.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: О дизайне
От: Sinatr Германия  
Дата: 04.04.16 07:14
Оценка:
Здравствуйте, Тепляков Сергей Владимирович, Вы писали:

Почему к примеру с GetEnumerator() не прилагается результат с обьяснением, либо просто ссылка на куда-то где обьяснено? (к примеру, сюда)
---
ПроГLамеры объединяйтесь..
Re: О дизайне
От: itslave СССР  
Дата: 05.04.16 19:10
Оценка: 10 (1)
Здравствуйте, Тепляков Сергей Владимирович, Вы писали:

ТСВ>Статья:

ТСВ>О дизайне
Автор(ы): Тепляков Сергей Владимирович
Дата: 27.10.2015
В статье рассматриваются различные аспекты дизайна приложения и влияние этих аспектов на выбор верного варианта дизайна.


ТСВ>Авторы:

ТСВ> Тепляков Сергей Владимирович

ТСВ>Аннотация:

ТСВ>В статье рассматриваются различные аспекты дизайна приложения и влияние этих аспектов на выбор верного варианта дизайна.

Рекомендую аффтару открыть для себя нефункциональные требования, quality attributes и методы работы с ними. Впрочем прогресс у автора заметен: эта статья гораздо ближе к реальному миру чем к примеру вот эта: https://habrahabr.ru/post/133287/
Рекомендую осмыслить вот это:
Microsoft Application Architecture Guide, 2nd Edition особенно вот главу Chapter 16: Quality Attributes
Software Architecture in Practice
Documenting Software Architectures – Views and Beyond, Portable Documents и пока в голове не устаканится, не писать статьи про архитектуры и дизайн
Отредактировано 05.04.2016 19:11 itslave . Предыдущая версия .
Re[2]: О дизайне
От: diez_p  
Дата: 04.05.16 16:08
Оценка:
Здравствуйте, Sinatr, Вы писали:

S>Здравствуйте, Тепляков Сергей Владимирович, Вы писали:


S>Почему к примеру с GetEnumerator() не прилагается результат с обьяснением, либо просто ссылка на куда-то где обьяснено? (к примеру, сюда)

Да все просто GetEnumerator() возвращает Enumerator, а это ValueType LOL и при обращении к свойству Enumerator происходит копирование по значению всего элемента, в отличии от ссылочного объекта, когда копирование по значению происзходит только ссылки.



IL_0012: callvirt instance !0 class '<>f__AnonymousType0`1'<valuetype ConsoleApplication1.Program/MyStruct>::get_ValueTypeField()

        public struct MyStruct
        {
            public int Field;

            public MyStruct(int field)
            {
                Field = field;
            }

            public void Increment()
            {
                Field++;
            }
        }


        private static MyStruct GetStruct()
        {
            return new MyStruct(0);
        }

Вызов.

            var z = new { ValueTypeField = GetStruct() };

            for (int i = 0; i < 5; i++)
            {
                z.ValueTypeField.Increment();
            }
            Console.WriteLine(z.ValueTypeField.Field);

замена struct на class решает проблему.
Замечу, что обильное использование всяких "фишек" типа иницаилизаторов, анонимных типов и т.д. должно быть оправдано и разработчик должен понимать что происходит "под капотом". Но Enumerator реализованный в List<T> как valuetype хорошая мина
Отредактировано 04.05.2016 16:12 diez_p . Предыдущая версия . Еще …
Отредактировано 04.05.2016 16:11 diez_p . Предыдущая версия .
Отредактировано 04.05.2016 16:10 diez_p . Предыдущая версия .
Re: О дизайне
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.05.16 16:31
Оценка:
Здравствуйте, Тепляков Сергей Владимирович, Вы писали:

ТСВ>Статья:

ТСВ>О дизайне
Автор(ы): Тепляков Сергей Владимирович
Дата: 27.10.2015
В статье рассматриваются различные аспекты дизайна приложения и влияние этих аспектов на выбор верного варианта дизайна.


ТСВ>Авторы:

ТСВ> Тепляков Сергей Владимирович

ТСВ>Аннотация:

ТСВ>В статье рассматриваются различные аспекты дизайна приложения и влияние этих аспектов на выбор верного варианта дизайна.


А в чем цель статьи? Я вот прочитал и что должен для себя вынести?
Re[2]: О дизайне
От: diez_p  
Дата: 04.05.16 18:52
Оценка:
Здравствуйте, gandjustas, Вы писали:
G>А в чем цель статьи? Я вот прочитал и что должен для себя вынести?
В статье это напрямую не говориться, но прежде, чем принимать какое либо техническое решение, надо понять какую проблему решал автор этого решения, какие плюсы/минусы и на сколько это решение подходит в "нашем" случае.
И второе не придумывать себе проблем, если в модели бизнеса вероятность сценария очень мала (из серии за 10 лет это никому не надо было), то не имеет смысла закладывать в этот сценарий какую-либо гибкость — и сделать его максимально быстро и дубово и наоборот уделить внимание наиболее изменчивым областям.
Отредактировано 04.05.2016 18:53 diez_p . Предыдущая версия .
Re[3]: О дизайне
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.05.16 19:00
Оценка:
Здравствуйте, diez_p, Вы писали:

_>Здравствуйте, gandjustas, Вы писали:

G>>А в чем цель статьи? Я вот прочитал и что должен для себя вынести?
_>В статье это напрямую не говориться, но прежде, чем принимать какое либо техническое решение, надо понять какую проблему решал автор этого решения, какие плюсы/минусы и на сколько это решение подходит в "нашем" случае.
_>И второе не придумывать себе проблем, если в модели бизнеса вероятность сценария очень мала (из серии за 10 лет это никому не надо было), то не имеет смысла закладывать в этот сценарий какую-либо гибкость — и сделать его максимально быстро и дубово и наоборот уделить внимание наиболее изменчивым областям.

Капитанство чистой воды, уж простите.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.