Да действительно, сейчас взглянул на статью с работы после запарки и у меня сложилось такое-же мнение.
В этом есть моя вина.
Но изначально данный мини-обзор писался в рамках продолжительного цикла статей о «внутренностях» скажем так (в качестве разминки) и на тот момент мне показался уместным.
Если честно, в тот момент, когда я писал данный обзор я даже не думал о том, о чем вы упомянули (о конкретике) поэтому извиняюсь за поверхностное изложение материала.
А не думал по причине того, что мне казались все эти моменты очевидными и в этом моя вторая ошибка.
Постараюсь учитывать это все в дальнейшем.
Ну это не я себе заучил, а как Вы сами сказали — это «стандарт».
В принципе возможность выстрелить себе в ногу не запрещается, но и не приветствуется :)
Эх…
Видимо у меня не получилось донести суть.
Попробую по другому.
У объекта есть конструктор и деструктор. Это все что он предоставляет.
Нет более никаких правил его использования.
Если используется работа с интерфейсной частью объекта — используйте ее.
Но не нужно вмешиваться во время жизни объекта — сие есть плохо.
Правило простое: «Я тебя породил — я тебя и убью».
Птицы фениксы, рождающиеся посредством инкремента ссылок в конструкторе — есть жестко и болезненно.
Да не хранит он ничего :)
Вы с какой версией Delphi работаете? Я просто перед глазами Classes от семерки держу и соответственно по нему и описываю картинку :)
Помогать чем? Вмешательством в логику кода?
Допустим на пальцах, есть DCU, доступа к исходникам у меня нет, поправить ничего не могу.
Я создаю наследника от такого вот «дружественного класса» в котором реализую мьютекс (или любой другой объект синхронизации).
Вы действительно хотите мне сказать, что за удаление объекта синхронизации реализованного в деструкторе класса, должен отвечать ваш код, который сам решит когда ему делать _Release?
Хорошо, другой пример — Вы когда либо реализовывали расширения оболочки?
Я периодически сталкиваюсь с различными их вариациями, где люди делают принудительный _AddRef самому себе, думая что в деструкторе спасет _Release.
А потом появляются вопросы — а почему проводник с моим расширением падает :)
Ну собственно именно этим и занимается TComponent, была в свое время хорошая статья даже о том, почему перекрывался _AddRef в данном случае на кодецентрале (или как он там назывался, когда еще площадкой не эмбаркадеро и не кодегир владели)
Допустим, тогда зачем реализация компонента должна мне мешать?
Разве конструктор класса должен решать где увеличить количество ссылок на экземпляр, или все-же программист, создающий экземпляр данного класса?
… дальним предком, разумеется.
Он как-бы никогда ни у кого не вызывал вопросов, хотя вот оно самое — интерфейсы в наличии.
Как-то ни у кого не появилась мысль в перекрытии счетчика ссылок данного экземпляра класса.
Но позвольте, любой объект, реализующий интерфейс, будучи применен правильным образом не нуждается ни в каких дополнительных методах. Где я не прав? :)
Взять тот-же TInterfacedObject
Немного неверный подход, объекту ничего не должно быть нужно — он вещь в себе, реализующая некий функционал, который ничего не знает о вызывающем его коде. Точка.
К примеру, если по такому принципу реализовывать код для расширений оболочки, то можно наткнутся на большие неприятности из-за игр со счетчиком ссылок.
Если внешний код использует объект не правильно, это проблема только внешнего кода.
Да, тут действительно немного сумбурно получилось. Я достаточно много раз расширял уже готовые и работающие десяток лет классы интерфейсами и ни разу не потребовались такие вот «допманевры» :)
Не переживай — первый блин все таки :)
Все-же перекрывать счетчик ссылок огромный моветон, да и чревато.
Тут лучше переосмыслить подачу материала, а то так и получается что суть статьи — попытка исправить изначально неправильный код, причем не в месте возникновения ошибки.
А это, по сути — костыль :)
Да, конечно…
Это самый первый этап, после которого я сижу и подробно объясняю кандидату все его промахи, предварительно выслушав его вариант ответа на вопросы из тестового задания.
Без этого никто не уходит.
Ибо, без этого, у кандидата может сложиться неверное мнение что мол «ко мне предвзято отнеслись».
Нам лишние рекламации не нужны :)
К сожалению нам это не подходит, продукт достаточно специфичен и расширение IT отдела происходит раз в год ровно на одного программиста.
Приходится работать над отбором и искать тот самый «бриллиант» каждый год :)
Правда и текучки нет, из-за столь тщательного отбора кадров…
Отличная подача материала, по существу и без преувеличений. +1
Единственно не могу понять одной вещи:
Сколько лет занимаюсь собеседованием кандидатов на вакансию в IT отдел и так и не смог понять для себя следующее: откуда студенты берут диапазоны цифр, которые они желают получать?
Собеседуя специалиста с историей и рекомендациями — я заранее закладываюсь на завышенные уровни ЗП (ибо это специалист) и получаю на выходе ожидаемые требования 90-110 тыр. (а то и больше — зависит от уровня)
Собеседуя же выпускников ВУЗ-ов, новоиспеченных можно сказать «специалистов» — первое что я слышу, это не вопрос по условиям работы, не вопросы о возможностям повышения квалификации и прочее…
Первое что я слышу это вопрос: «каков уровень заработной платы?».
Когда начинаю объяснять, что для начала с вашим опытом можно начать к примеру с 60 тыр, обычно начинается полемика — мол вы что, дворника нанимаете или специалиста с дипломом? :) Я хочу начать сотрудничество с вашей компании например со 120 тысяч…
И ведь не объяснить что нам не диплом нужен, а знания :))
Вроде сам учился когда-то, но не помню что-бы были такие завышенные претензии у меня к работодателю.
Все-же адекватно оценивать собственные знания в МИРЭА в свое время учили :)
В этом есть моя вина.
Но изначально данный мини-обзор писался в рамках продолжительного цикла статей о «внутренностях» скажем так (в качестве разминки) и на тот момент мне показался уместным.
Если честно, в тот момент, когда я писал данный обзор я даже не думал о том, о чем вы упомянули (о конкретике) поэтому извиняюсь за поверхностное изложение материала.
А не думал по причине того, что мне казались все эти моменты очевидными и в этом моя вторая ошибка.
Постараюсь учитывать это все в дальнейшем.
Thread — нить, Fiber — волокно, Stream — поток.
В принципе возможность выстрелить себе в ногу не запрещается, но и не приветствуется :)
Видимо у меня не получилось донести суть.
Попробую по другому.
У объекта есть конструктор и деструктор. Это все что он предоставляет.
Нет более никаких правил его использования.
Если используется работа с интерфейсной частью объекта — используйте ее.
Но не нужно вмешиваться во время жизни объекта — сие есть плохо.
Правило простое: «Я тебя породил — я тебя и убью».
Птицы фениксы, рождающиеся посредством инкремента ссылок в конструкторе — есть жестко и болезненно.
Вы с какой версией Delphi работаете? Я просто перед глазами Classes от семерки держу и соответственно по нему и описываю картинку :)
Допустим на пальцах, есть DCU, доступа к исходникам у меня нет, поправить ничего не могу.
Я создаю наследника от такого вот «дружественного класса» в котором реализую мьютекс (или любой другой объект синхронизации).
Вы действительно хотите мне сказать, что за удаление объекта синхронизации реализованного в деструкторе класса, должен отвечать ваш код, который сам решит когда ему делать _Release?
Хорошо, другой пример — Вы когда либо реализовывали расширения оболочки?
Я периодически сталкиваюсь с различными их вариациями, где люди делают принудительный _AddRef самому себе, думая что в деструкторе спасет _Release.
А потом появляются вопросы — а почему проводник с моим расширением падает :)
В статье то именно он и упоминается :)
Разве конструктор класса должен решать где увеличить количество ссылок на экземпляр, или все-же программист, создающий экземпляр данного класса?
TForm — всем известный и понятный класс наследуемый от…
… дальним предком, разумеется.
Он как-бы никогда ни у кого не вызывал вопросов, хотя вот оно самое — интерфейсы в наличии.
Как-то ни у кого не появилась мысль в перекрытии счетчика ссылок данного экземпляра класса.
Взять тот-же TInterfacedObject
К примеру, если по такому принципу реализовывать код для расширений оболочки, то можно наткнутся на большие неприятности из-за игр со счетчиком ссылок.
Если внешний код использует объект не правильно, это проблема только внешнего кода.
Не переживай — первый блин все таки :)
У них немного другие задачи :)
Тут лучше переосмыслить подачу материала, а то так и получается что суть статьи — попытка исправить изначально неправильный код, причем не в месте возникновения ошибки.
А это, по сути — костыль :)
Это самый первый этап, после которого я сижу и подробно объясняю кандидату все его промахи, предварительно выслушав его вариант ответа на вопросы из тестового задания.
Без этого никто не уходит.
Ибо, без этого, у кандидата может сложиться неверное мнение что мол «ко мне предвзято отнеслись».
Нам лишние рекламации не нужны :)
Приходится работать над отбором и искать тот самый «бриллиант» каждый год :)
Правда и текучки нет, из-за столь тщательного отбора кадров…
Единственно не могу понять одной вещи:
Сколько лет занимаюсь собеседованием кандидатов на вакансию в IT отдел и так и не смог понять для себя следующее: откуда студенты берут диапазоны цифр, которые они желают получать?
Собеседуя специалиста с историей и рекомендациями — я заранее закладываюсь на завышенные уровни ЗП (ибо это специалист) и получаю на выходе ожидаемые требования 90-110 тыр. (а то и больше — зависит от уровня)
Собеседуя же выпускников ВУЗ-ов, новоиспеченных можно сказать «специалистов» — первое что я слышу, это не вопрос по условиям работы, не вопросы о возможностям повышения квалификации и прочее…
Первое что я слышу это вопрос: «каков уровень заработной платы?».
Когда начинаю объяснять, что для начала с вашим опытом можно начать к примеру с 60 тыр, обычно начинается полемика — мол вы что, дворника нанимаете или специалиста с дипломом? :) Я хочу начать сотрудничество с вашей компании например со 120 тысяч…
И ведь не объяснить что нам не диплом нужен, а знания :))
Вроде сам учился когда-то, но не помню что-бы были такие завышенные претензии у меня к работодателю.
Все-же адекватно оценивать собственные знания в МИРЭА в свое время учили :)