Как это не будут? Объект будет обязательно создан, только ссылка потеряется. И при попытке, удалить файл до сборки мусора поднимется исключение по доступу.
Выполнение описываемых предписаний не защитят вас от проблем между строками «var tmpFile» и «try» (например, из-за асинхронных исключений). Они скорее говорят как уменьшать вероятность возникновения проблем, уменьшив прослойку. Для полной уверенности надо предпринимать отдельные усилия, подобные habrahabr.ru/post/144240/#comment_4841489
Мне кажется, что проблемы не существует при понимании работы using(...). Все что в скобках — не финализируется; в теле — финализируется.
А вообще напоминает объявление переменных через запятую: int a,b;
Я когда это вижу всегда коллег спрашиваю: «Что это?». Когда получаю ответ — до меня доходит. Вот и здесь сидел и думал: «А в чем суть?». Смешно то, что +2 строки. Удачный сахарок. Я не про инициализацию вообще, только вместе с using. Не конструкция — беременный гиппопотам.
В общем, если бы анализировал этот код перетащил бы определение параметров в тело только бы из эстетических соображений. И не когда бы не узнал, что пофиксил страшный баг.
Но в ней и не сказано, что это проблема решается путем отказа от статиков.
Еще раз — это проблема времени жизни объекта (или метаобъекта, если хотите) и решается она явным его определением. Все остальное — это нейтрализация тонких особенностей с помощью других тонких тонких особенностей функционирования CLR.
Не жалко себя, подумайте обо мне. Прихожу я завтра в вашу организацию и получаю код, который работает только потому, что статическое поле «abc» находится в классе «def». Если перенести его в «ghi» все разваливается. Как вы думаете, долго будет спасать вас дверь туалетной кабинки?
Китайский коммунизм. Сначала создаем проблемы, а затем героически их решаем.
Когда вы описываете статическую конструкцию вы отказываетесь от контроля времени жизни. Как только у вас возникает в нем необходимость надо убирать слово статик — проблема исчезнет сама.
По поводу оптимизации: глобальная видимость и оптимизация, немного разные вещи. Можно запросто использовать единственный экземпляр объекта и не обращаться к его глобальному носителю где не попадя (статическому полю класса). ИМХО, статических полей инициализируемых статическими полями быть не должно — это абсолютно бессмысленно.
Тестирование в отдельном домене, то что не работает в отдельном домене тоже сомнительно. Уберите статики и проблема исчезнет.
Сколько раз натыкался на то, что какая-то логика изначально не тестировалась из-за цены: это тестировать дорого, я как нибудь по старинке. Во время развития она начинала, то тут, то там сбоить. В какой-то момент понимаешь, что затраты на тесты были бы ниже. И что так дальше нельзя — пишешь тесты.
Если бы на момент начала написания логики имел бы набор инструментов (примитивов, библиотек и др. байды) помогающих писать тесты для конкретной области, вопрос писать или нет бы не стоял. Поэтому, по крайней мере, пробую писать. Что бы получить пищу для размышления, «почему сложно» и как по необходимости эту сложность решить.
Мне кажется место этапа «Обобщение» не в конце текущей итерации, а после «Анализа требований» следующие итерации (или другого проекта). Похоже на рефакторинг для облегчения внесения изменений, только в общем случае охватывающий несколько проектов.
Sory. Действительно, для JavaScript этот вопрос не принципиален (могли бы и сделать), т.к. в отличии от например, C++ "{" и "}" не ограничивают область видимости.
Спасибо за ликбез. У меня ни когда даже сомнений не возникало. Да и не возникло бы.
Интерестно, как вы будете складывать огурцы и помидоры. А самое главное, что у вас после этого получится.
Все операции в математике определены на каком-то конкретном типе объектов. Сложение натуральных чисел — для яблок, или помидоров, или сущностей. Помимо натуральных есть комплексные числа, вероятностные величины, вектора и другие математические абстракции.
Конкретная «формальная арифметика» определяет сущности и операции над ними. Не одну и не две, а столько сколько нужно. Так для векторов определено умножение на число, скалярное умножение векторов, векторное умножение векторов. Маразм ясен.
Мы с вами не идеальных коней в вакууме строим. Наша «формальная арифметика» имеет возможность расширяться с введением новых требований, а потому можно говорить о обязательной «невыводимости», только на несуществующую функциональность. Для всего остального мы должны выдумывать новое «сложение» (или скорректировать старое), при котором функциональность будет непротиворечиво существовать.
Программа не должна 100% верно описывать реальный мир (и 1% не обязателен). Достаточно абстрактной модели, удовлетворяющей условиям, описанным в техзадании. Если в нем нет того, что кошка по вызову деструктора распадается на атомы, значит она может и не распадаться (это ее личное дело, если конечно это не вызовет утечку ресурсов).
«любой часто используемый метод нужен всем объектам»
Это ерунда. Вы говорите, что недопроектированность системы — это норма. Цель декомпозиции системы, как раз в том, чтобы уменьшить связанность отдельных компонентов. Даже методы сериализации нужна только тем, кто ее производит. А определение их необходимо только для сущностей, которые, например передаются по сети.
Если таковых много, значит либо вы строите сереализатор, либо недопроектировали свое решение.
Мне тоже не понравилось описание этого паттерна. По сути автор сказал — это фабрика, только где-то в недрах ее происходит собирание реальных объектов из частей.
Builder применяется для создания сложных объектов из отдельных частей (обычно родственных, но не обязательно). Фабрика — целого сразу. Пример Buildr-а:
Не скажу, что я пользуюсь far-ом для чтения кода очень часто — раз 3 месяца максимум. Мог бы этим удобством и пожертвовать. Вопрос в скорости написания (та же ссылка).
Я не готов отказаться от проверенных временем инструментов (абстрагирование, полиморфизм, рефакторинг, tdd и т.д.) в пользу концепции, которая по факту не работает в других областях для больших задач (стоял рядом с промышленным примененим matlab при конструировании моделей блока управления двигателем).
Если серьезно, то в студенчестве я работал с Flash (передал работу брату, FlashScript — это его основной сейчас язык). На третьей задаче мне критически перестало хватать его графических редакторов и инъекций кода. Захотелось листинг всего кода сразу.
По поводу кода написанного блок-схемами, в том же вузе их построение было самым нелюбимым делом. 1 час творческой работы на код и 3 часа рутины на блок-схему. Слава богу эту «фичу» на 4-ом курсе упразнили.
Еще аргумент. На текущий момент одной из ведущих направлений развития «кодостроения» является методика рефакторинга. Полуавтоматическое безопасное преобразование кода. Не представляю как это будет выглядеть в графике.
Еще. Для чего вообще нужна графика? Что бы увеличить масштаб решения проблеммы. Но того же самого можно добиться и абстрагированием (графика помоему, тоже самое).
Об образовании. Школьникам нужно общее понимание, процесса решения реальных задач. То как строились игрушки в которые они играют каждый день. Лучше всего на простеньком паскале или бейсике (пускай и промышленно полумертвых). А наш минобр. поощряет псевдопонятные методологии (вероятнее всего пролоббированные), применяемые в узкоспециализированной среде (например, в строительстве или дизайне). И то, только сразу после вуза. Через два года специалисту становится недостаточно этих средств и он начинает изучать сначала язык AutoCad-а, а затем и C.
Выполнение описываемых предписаний не защитят вас от проблем между строками «var tmpFile» и «try» (например, из-за асинхронных исключений). Они скорее говорят как уменьшать вероятность возникновения проблем, уменьшив прослойку. Для полной уверенности надо предпринимать отдельные усилия, подобные habrahabr.ru/post/144240/#comment_4841489
точно не лучше
А вообще напоминает объявление переменных через запятую: int a,b;
Я когда это вижу всегда коллег спрашиваю: «Что это?». Когда получаю ответ — до меня доходит. Вот и здесь сидел и думал: «А в чем суть?». Смешно то, что +2 строки. Удачный сахарок. Я не про инициализацию вообще, только вместе с using. Не конструкция — беременный гиппопотам.
В общем, если бы анализировал этот код перетащил бы определение параметров в тело только бы из эстетических соображений. И не когда бы не узнал, что пофиксил страшный баг.
Еще раз — это проблема времени жизни объекта (или метаобъекта, если хотите) и решается она явным его определением. Все остальное — это нейтрализация тонких особенностей с помощью других тонких тонких особенностей функционирования CLR.
Не жалко себя, подумайте обо мне. Прихожу я завтра в вашу организацию и получаю код, который работает только потому, что статическое поле «abc» находится в классе «def». Если перенести его в «ghi» все разваливается. Как вы думаете, долго будет спасать вас дверь туалетной кабинки?
Когда вы описываете статическую конструкцию вы отказываетесь от контроля времени жизни. Как только у вас возникает в нем необходимость надо убирать слово статик — проблема исчезнет сама.
По поводу оптимизации: глобальная видимость и оптимизация, немного разные вещи. Можно запросто использовать единственный экземпляр объекта и не обращаться к его глобальному носителю где не попадя (статическому полю класса). ИМХО, статических полей инициализируемых статическими полями быть не должно — это абсолютно бессмысленно.
Тестирование в отдельном домене, то что не работает в отдельном домене тоже сомнительно. Уберите статики и проблема исчезнет.
Сколько раз натыкался на то, что какая-то логика изначально не тестировалась из-за цены: это тестировать дорого, я как нибудь по старинке. Во время развития она начинала, то тут, то там сбоить. В какой-то момент понимаешь, что затраты на тесты были бы ниже. И что так дальше нельзя — пишешь тесты.
Если бы на момент начала написания логики имел бы набор инструментов (примитивов, библиотек и др. байды) помогающих писать тесты для конкретной области, вопрос писать или нет бы не стоял. Поэтому, по крайней мере, пробую писать. Что бы получить пищу для размышления, «почему сложно» и как по необходимости эту сложность решить.
Не до конца понятно только, как это рисовать.
Спасибо за ликбез. У меня ни когда даже сомнений не возникало. Да и не возникло бы.
Все операции в математике определены на каком-то конкретном типе объектов. Сложение натуральных чисел — для яблок, или помидоров, или сущностей. Помимо натуральных есть комплексные числа, вероятностные величины, вектора и другие математические абстракции.
Конкретная «формальная арифметика» определяет сущности и операции над ними. Не одну и не две, а столько сколько нужно. Так для векторов определено умножение на число, скалярное умножение векторов, векторное умножение векторов. Маразм ясен.
Мы с вами не идеальных коней в вакууме строим. Наша «формальная арифметика» имеет возможность расширяться с введением новых требований, а потому можно говорить о обязательной «невыводимости», только на несуществующую функциональность. Для всего остального мы должны выдумывать новое «сложение» (или скорректировать старое), при котором функциональность будет непротиворечиво существовать.
Программа не должна 100% верно описывать реальный мир (и 1% не обязателен). Достаточно абстрактной модели, удовлетворяющей условиям, описанным в техзадании. Если в нем нет того, что кошка по вызову деструктора распадается на атомы, значит она может и не распадаться (это ее личное дело, если конечно это не вызовет утечку ресурсов).
Главное не забывать при этом говорить «тр-тр-тр...»
Это ерунда. Вы говорите, что недопроектированность системы — это норма. Цель декомпозиции системы, как раз в том, чтобы уменьшить связанность отдельных компонентов. Даже методы сериализации нужна только тем, кто ее производит. А определение их необходимо только для сущностей, которые, например передаются по сети.
Если таковых много, значит либо вы строите сереализатор, либо недопроектировали свое решение.
А «в недрах» нас и не должно интересовать. интересная ссылка
Builder применяется для создания сложных объектов из отдельных частей (обычно родственных, но не обязательно). Фабрика — целого сразу. Пример Buildr-а:
Фабрика:
Не скажу, что я пользуюсь far-ом для чтения кода очень часто — раз 3 месяца максимум. Мог бы этим удобством и пожертвовать. Вопрос в скорости написания (та же ссылка).
Я не готов отказаться от проверенных временем инструментов (абстрагирование, полиморфизм, рефакторинг, tdd и т.д.) в пользу концепции, которая по факту не работает в других областях для больших задач (стоял рядом с промышленным примененим matlab при конструировании моделей блока управления двигателем).
Вашу позицию, я понял еще вчера. Не скажу, что я ее считаю жизнеспособной (мое оценочное суждение). Но реализуема — это точно.
По поводу кода написанного блок-схемами, в том же вузе их построение было самым нелюбимым делом. 1 час творческой работы на код и 3 часа рутины на блок-схему. Слава богу эту «фичу» на 4-ом курсе упразнили.
Еще аргумент. На текущий момент одной из ведущих направлений развития «кодостроения» является методика рефакторинга. Полуавтоматическое безопасное преобразование кода. Не представляю как это будет выглядеть в графике.
Еще. Для чего вообще нужна графика? Что бы увеличить масштаб решения проблеммы. Но того же самого можно добиться и абстрагированием (графика помоему, тоже самое).
Об образовании. Школьникам нужно общее понимание, процесса решения реальных задач. То как строились игрушки в которые они играют каждый день. Лучше всего на простеньком паскале или бейсике (пускай и промышленно полумертвых). А наш минобр. поощряет псевдопонятные методологии (вероятнее всего пролоббированные), применяемые в узкоспециализированной среде (например, в строительстве или дизайне). И то, только сразу после вуза. Через два года специалисту становится недостаточно этих средств и он начинает изучать сначала язык AutoCad-а, а затем и C.