Офигеть! Превосходно!
Да какой же вы дилетант? Я прочитал и понял каждое слово, которые вы написали, полностью и недвусмысленно, потому что в своих исследованиях дошёл до всех ваших мыслей (кроме некоторых поправок). Вы мыслите совершенно в верном направлении.
Архитектурная проблема — это то, что вы теряетесь в графе зависимостей между классами.
Вы представляете себе весь .NET Framework? Даже если вы его разработчик? Вы можете рассказать что от чего зависит? Бред! Если вы только не человек с феноменальной памятьи, и если не разрабатывали каждую его часть. Похоже вы никогда не работали над действительно большими проектами, тогда да, в сотне классов сложно заблудиться, конечно.
Причём вы даже неправильно понимаете суть. Архитектура может быть замечательной и понятной, но это только на диаграмме, а вот когда смотришь в код, то видишь офигенное кол-во классов, и связи нужно проставлять не между компонентами архитектуры, а между классами, которые её реализуют, потому что .NET оперирует имеенно объектами для сборки мусора, а не какой-то там диаграммой архитектуры.
Вообще-то, нет. Это ведет к убиранию делегата из списка.
А что такое убрать делегат из списка? Встроенные MulticastDelegate хранят делегаты в обычном массиве []. А Delegate, это какой класс? Immutable. При отписке, создаётся новый MulticastDelegate с новый массивом, где уже нет вашего подписанного делегата. А что происходит со старым массивом? Он висит в памяти до сборки мусора. А при сборке мусора массив будет «удалён», при этом все объекты, на которые он ссыллася станут отвязанными от него, что можно считать установкой в NULL на уровне CLR.
Вы только продолжаете смешить тапочки, всё больше и больше уверяя в вашей неадекватности.
1) отписаться — не архитектурная пролема
2) отписаться — это не магия. Это косвенно ведёт к установке в NULL. В статье говорится в первую очередь про граф, а если ваше воображение заканчивается конструкцией «var = null», то это ваша проблема.
3) перестаньте умничать, это уже не смешно. Это печально.
Мистер «самый умный» или «переведу стрелки на другого»,
если вы где-то в коде подписались на событие, и забыли отписаться, причём weak reference не используется, то ваш объект (который есть в делегате), останется висеть в памяти, пока тот, у которого объявлено событие (event), не будет «удалён». И это пример не плохой архитектуры, а пример, что нужно за собой чистить ссылки.
Была бы карма у меня побольше, то заминусовал вас за вашу неадекватность! Изучайте мат часть, до того как писать глупости.
Жесть! Сколько споров и на какие темы… Это всё из-за топика о производительности приложений. Тут уже можно создавать отдельные топики по математике, проектированию приложений, методикам разработки, и пр. Хоть бери текст из комментариев — и статья готова =)
Как ни странно, .NET и Java призваны избавить рабработчика от слежки за памятью, но «утечки» всё-равно происходят по той причине, что разработчики просто забывают о принципе работы GC. Когда проект разростается до громадных размеров, то визуально представить все связи между всеми классами практически невозможно (нужно учесть не только свои написанные классы, а и frameworks которые используете). Так вы можете пропустить всего одну ссылку при «удалении», а она тянет засобой ещё пару сотен объектов. В итоге, они могут вечно остаться в памяти приложения, и рано или поздно оно упадёт с OutOfMemoryException.
Конечно, если вы на 100% уверены, что некий класс создаёт для внутренних нужд другие объекты, то при «удалении» такого класса действительно нет смысла обнулять ссылки на эти другие объекты. Если вы в этом не уверены, то лишнее присвоение в null не помешает :)
Насчёт первого — думаю не совсем так. Я познакомился с YAGNI занимаясь TDD: вначале думали где разместить желаемый код, потом писали тест на несуществующий код, потом писали код чтобы прошёл тест и ничего лишнего. Мы не писали ни лишние тесты, ни лишной код — только удовлетворяли потребности из спецификации — это и есть YAGNI. Если где-то понадобится тот код, который уже есть, то следуя стратегии Red-Green-Refactor, single responsibility (и прочее) сохраняется. Но опять же, есть куча факторов, где это может не работать или быть неразумной тратой времени.
Насчёт второго, если я не ошибаюсь, можно было решить введя константу, значение которой 360гр/2^32. Тогда проблема решилась бы изменением этой константы. Вам виднее, проекта я не видел :)
А как насчёт цветовой модели YCbCr? Подойдёт ли она для решения вашей задачи? Она более стандартная и используются как в аналоговой части, так и в кодировке цифрового видео. Там преобразования в RGB и обратно намного проще.
Да, согласен, это зависит от многих факторов. В моём случае это была вторая версия, где после первой было накопленно огромное кол-во знаний. И в таком случае, если заранее всё известно, то почему бы не сделать сразу хорошо, чтоб по 100500 раз не переделывать? Опять же, у приложения может не быть требования «быть хорошим или самым лучшим», лень и недобросовестность разработчиков, или просто незнание технической области.
Однозначного ответа здесь нет — всё зависит от конкретной ситуации. Но ваше высказывание правдиво в большей части случаев, т.к. невозможно знать всё наперёд. Я тоже не спешу делать того, что не требуется (YAGNI).
Спору нет, но фильтр, который работает 360мс на каждом элементе… Это что-то явно не здоровое. Поэтому пример сравнения с часом выполнения не совсем удачный в этом контексте.
Такие мысли толкают людей на создание более высокоуровневых языков, отходя дальше от ассемблера. Будем надеятся, что когда-то будут платформы, где можно ввести детальную спецификацию, а код будет уже сам генерироваться наилучшим способом. Тогда задача разработки будет сводится к уточнению и изменению спецификации, которая лучше всего отображает суть проблемы.
Написать сразу-правильную программу довольно рискованное мероприятие
Обычно это не проблема для людей с богатым опытом не только в программировании, а в проектировании. Люди, которые знают, например, в чём разница между heapsort и mergesort, не смотря что оба алгоритма работают за O(N*logN), просто не позволят себе плохо написать код изначально ;)
Да какой же вы дилетант? Я прочитал и понял каждое слово, которые вы написали, полностью и недвусмысленно, потому что в своих исследованиях дошёл до всех ваших мыслей (кроме некоторых поправок). Вы мыслите совершенно в верном направлении.
Идите учите проектированию разработчиков .NET framework.
Считайте как вам угодно, фактов это не изменит.
Разговор окончен.
Вы представляете себе весь .NET Framework? Даже если вы его разработчик? Вы можете рассказать что от чего зависит? Бред! Если вы только не человек с феноменальной памятьи, и если не разрабатывали каждую его часть. Похоже вы никогда не работали над действительно большими проектами, тогда да, в сотне классов сложно заблудиться, конечно.
Причём вы даже неправильно понимаете суть. Архитектура может быть замечательной и понятной, но это только на диаграмме, а вот когда смотришь в код, то видишь офигенное кол-во классов, и связи нужно проставлять не между компонентами архитектуры, а между классами, которые её реализуют, потому что .NET оперирует имеенно объектами для сборки мусора, а не какой-то там диаграммой архитектуры.
А что такое убрать делегат из списка? Встроенные MulticastDelegate хранят делегаты в обычном массиве []. А Delegate, это какой класс? Immutable. При отписке, создаётся новый MulticastDelegate с новый массивом, где уже нет вашего подписанного делегата. А что происходит со старым массивом? Он висит в памяти до сборки мусора. А при сборке мусора массив будет «удалён», при этом все объекты, на которые он ссыллася станут отвязанными от него, что можно считать установкой в NULL на уровне CLR.
Вы только продолжаете смешить тапочки, всё больше и больше уверяя в вашей неадекватности.
2) отписаться — это не магия. Это косвенно ведёт к установке в NULL. В статье говорится в первую очередь про граф, а если ваше воображение заканчивается конструкцией «var = null», то это ваша проблема.
3) перестаньте умничать, это уже не смешно. Это печально.
если вы где-то в коде подписались на событие, и забыли отписаться, причём weak reference не используется, то ваш объект (который есть в делегате), останется висеть в памяти, пока тот, у которого объявлено событие (event), не будет «удалён». И это пример не плохой архитектуры, а пример, что нужно за собой чистить ссылки.
Была бы карма у меня побольше, то заминусовал вас за вашу неадекватность! Изучайте мат часть, до того как писать глупости.
Конечно, если вы на 100% уверены, что некий класс создаёт для внутренних нужд другие объекты, то при «удалении» такого класса действительно нет смысла обнулять ссылки на эти другие объекты. Если вы в этом не уверены, то лишнее присвоение в null не помешает :)
Насчёт второго, если я не ошибаюсь, можно было решить введя константу, значение которой 360гр/2^32. Тогда проблема решилась бы изменением этой константы. Вам виднее, проекта я не видел :)
Однозначного ответа здесь нет — всё зависит от конкретной ситуации. Но ваше высказывание правдиво в большей части случаев, т.к. невозможно знать всё наперёд. Я тоже не спешу делать того, что не требуется (YAGNI).
Вот собственно почему и существует Закон Вирта :)
Обычно это не проблема для людей с богатым опытом не только в программировании, а в проектировании. Люди, которые знают, например, в чём разница между heapsort и mergesort, не смотря что оба алгоритма работают за O(N*logN), просто не позволят себе плохо написать код изначально ;)