Как я убеждаю своих коллег не реализовывать IDisposable на всем? [закрытый]

Укажите на Joe Duffy's сообщение об IDisposable / finalizers - объединенная мудрость многих умных людей.

В настоящее время мне трудно увидеть там утверждение, в котором говорится: «Не внедряйте это, когда оно вам не нужно» - но помимо что-нибудь еще, показав им сложность его правильной реализации, вполне может помочь отговорить их от этого ...

К сожалению, если люди не будут слушать, они не будут слушать. Попытайтесь заставить их объяснить , почему они думают, что им нужен IDisposable . Они думают, что сборщик мусора не работает? Покажите им, что это работает. Если вы сможете убедить их, что это не приносит пользы (для большинства типов), тогда они наверняка перестанут добавлять работу для себя ...

Как говорит Брайан, реализация IDisposable не поможет с проблема события сама по себе - она ​​должна быть чем-то вызвана . Финализаторы и в этом вам не помогут. Им действительно нужно явно сделать что-то , чтобы удалить обработчики событий.

Они думают, что сборщик мусора не работает? Покажите им, что это работает. Если вы сможете убедить их, что это не приносит пользы (для большинства типов), тогда они наверняка перестанут добавлять работу для себя ...

Как говорит Брайан, реализация IDisposable не поможет с проблема события сама по себе - она ​​должна быть чем-то вызвана . Финализаторы и в этом вам не помогут. Им действительно нужно явно сделать что-то , чтобы удалить обработчики событий.

Они думают, что сборщик мусора не работает? Покажите им, что это работает. Если вы сможете убедить их, что это не приносит пользы (для большинства типов), тогда они наверняка перестанут добавлять работу для себя ...

Как говорит Брайан, реализация IDisposable не поможет с проблема события сама по себе - она ​​должна быть чем-то вызвана . Финализаторы и в этом вам не помогут. Им действительно нужно явно сделать что-то , чтобы удалить обработчики событий.

Само по себе это не поможет решить проблему с событием - оно должно быть чем-то вызвано . Финализаторы и в этом вам не помогут. Им действительно нужно явно сделать что-то , чтобы удалить обработчики событий.

Это само по себе не поможет решить проблему с событием - оно должно быть чем-то вызвано . Финализаторы и в этом вам не помогут. Им действительно нужно явно сделать что-то , чтобы удалить обработчики событий.

Простая реализация Dispose () для всех типов не решит вашу проблему. Помните, что Dispose () не вызывается автоматически, и он не имеет ничего общего с освобождением управляемой памяти. Чтобы получить какой-либо эффект от ваших методов Dispose () , вам необходимо вызвать их во всех соответствующих местах - либо явно, либо через с использованием .

Другими словами, простая реализация IDisposable не решит ваши проблемы волшебным образом, потому что методы Dispose () не будут вызываться, если вы также не измените использование каждого типа в вашем код.

Однако я бы не рекомендовал реализовать IDisposable для всех ваших типов просто потому, что это не имеет смысла. Интерфейс используется, чтобы указать, что рассматриваемый тип использует некоторый ресурс, который не обрабатывается сборщиком мусора.

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

Однажды я помог коллеге решить аналогичную проблему с возникновением ошибок OutOfMemoryException (вызванных событиями, которые оставляют ссылки на объекты висящими вокруг). Первое, что я сделал, это запустил код через FXCop, который выделил Dispose не вызывался в классе IDisposable.

Изменение этого кода для удаления устранило проблему. Возможно, вам стоит порекомендовать использовать FXCop?

Возможно, найдите код с проблемой в исходном репозитории, запустите на нем FXCop - посмотрите, выделяет ли он проблему (вероятно, будет, если она вызвана классом .NET Framework) и используйте это, чтобы убедить своих коллег.

Это сложно осуществить, но я нашел, что лучший способ заставить людей делать то, что вы хотите, - это позволить им думать, что это их идея. Вы знаете их лучше, чем я, но такие фразы, как «Если бы только был способ узнать, почему объекты так долго торчат» и «Хотел бы я знать больше о событиях, связанных с объектами», могут быть отправной точкой.

Спросите их, не хотят ли они, чтобы их заставляли выключать двигатель после езды на велосипеде, даже если двигателя нет.

Или они хотели бы вынуждены нажимать кнопку «выключить» на своем стуле, столе, чашке кофе и других предметах перед тем, как покинуть рабочее место, даже если нет ничего, что нужно было выключить.

Реализация IDisposable вынуждает пользователя явно указать объекту когда он больше не используется. Если этому объекту не нужно ничего очищать, это просто ненужная сложность.

Между прочим, ИМХО, отмена регистрации событий путем реализации IDisposable - подходящий способ очистки событий. Есть что "выключить".

IDisposable предназначен только для использования для освобождения неуправляемых ресурсов (SafeHandles и т.п.), а метод Dispose распространяется по иерархии классов. Он не предназначен для того, чтобы пытаться обойти плохие методы неуправляемого программирования.

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

Разве не для этого предназначен IDisposable? Зачем вам другое решение, если оно уже есть? И почему эти болваны не реализовали свои объекты правильно? ;)

Создать обязанность по разрешению еще одного OutOfMemoryException. Когда кто-то разрешает чужие ошибки, это накладывает ответственность на собственный код. На ранней стадии нашего проекта нам рекомендовали «флаг дурака» - виновник фатальной ошибки получает этот флаг на день.

Предложите решение, которое намного превосходит их решение; -)

Например, простой альтернативой может быть использование WeakReference в долгоживущих объектах для хранения ссылок на обработчики событий. Это потребует, чтобы обработчики событий ссылались где-то еще, пока они необходимы, но как только они выходят за пределы области видимости, они собираются мусором, и слабые ссылки могут быть удалены из долгоживущих объектов.