Используя IDisposable Для Отмены подписки События — я должен Вставить Другие Вещи Расположение?
У меня есть следующий класс
public class Presenter: IDisposable
{
public IView View
{get;private set;}
//snip other object reference, all managed
public Presenter(IView view)
{
View=view;
View.MouseUp += MouseUpEvent;
}
public void MouseUpEvent()
{
//do whatever you want to do on mouse up
}
public void Dispose()
{
View.MouseUp -= MouseUpEvent;
// no more manual disposing
}
}
Вопрос теперь, я реализую Dispose() метод правильно? Или сделайте я должен вручную расположить все другие управляемые объекты просто, потому что у меня есть explicilty, определяют Dispose()?
Я считаю, что GC достаточно умен, чтобы сделать его собственное расположение (кроме подписки события) даже без меня, вручную делая его.Я прав?
2 ответа
Для работы в Интернете я использую плагин Delicious + Firefox для хранения прочитанного.
При поиске решения для того, что я не могу решить, я привык спрашивать/искать здесь.
Для своих собственных решений я стараюсь создавать многоразовые компоненты и помню, в каком проекте я решал, что и, в конце концов, возвращаюсь к нему позже, когда это нужно.
-121--3950612-Всякий раз, когда вы изучаете одну технику программирования, такую как java, вы всегда сопоставляете соответствующие вещи с C++ и perl. Java и C++ остаются одинаковыми в других концепциях. И лучше вы сохраняете свою рабочую папку в вашей почте, чтобы, когда вам нужно, вы могли скачать и иметь его.
-121--3950613-Если выбрать подписку в конструкторе, то это выглядит разумно. Я бы повторил мнение Джоша о том, что это может быть не лучшим подходом. С другой стороны, это может быть самый простой способ достижения вашей цели, что всегда хорошо. Я не собираюсь притворяться экспертом по UI узоров: подняв беспокойство, предположу, что это тот путь, над которым вы хотите работать, и решу сам вопрос:)
Я лично нахожу предписанные Джошем образцы 1 чрезмерно сложными для простых сценариев - ваш подход в порядке, с одним изменением: сделайте свой класс запечатанным. Если вы не хотите заклеивать класс, вы должны перейти к опции Dispose (bool) (но без финализатора), потому что подклассам также может потребоваться утилизация вещей, и может потребоваться финализатор. Без возможности производного типа жизнь проще (как это так часто бывает).
Вам не нужно ничего делать с другими участниками только потому, что теперь вы реализуете IDiposable по этой одной причине.
Итак, нужно ли извлекать что-либо из этого класса?
1 Я понимаю, что это стандартный рекомендуемый образец, хотя я рекомендую вам прочитать совет Джо Даффи и др. для еще более подробной информации - все это может стать очень сложным.
Лично, я бы избежал подключения / откатывающегося события в конструкторе и утилизировать. Вместо этого я бы добавил код на просмотр Get / Set Accessors и добавить их там. Но если ведущий располагается, когда просмотр прилагается, я бы не мог попытаться убрать это. Вы можете явно отсоединить вид от презентатора, если вам нужен явный отсоединение.
Сказав это, вот то, что я знаю о IDSPosable.
Рекомендуемый подход к реализует IDSposable , должен иметь метод защищенного убытка (BOOL), где вы принимаете меры. Причина в том, что вы хотите различить явную утилизацию и утилизацию, вызванную завершением (сбор мусора)
, когда вы располагаете из-за явного утилизации () вызова, это нормально, чтобы коснуться управляемых объектов, и вы ожидаете Чтобы утилизировать все, что вы создали, что также необходимо указать. Таким образом, вы делаете это только при удалении = правда.
Но если кто-то (вы) забывает позвонить, чтобы позвонить, и финализатор называется, вы расположены после сборки мусора (распоряжение = false), и вы не хотите прикоснуться к любым управляемым объектам, потому что они могут быть уже доработаны. Единственное, что вам нужно для освобождения в этом случае, - это неуправляемые ресурсы, такие как Win32 ручки и такие.
Наконец, при убывании () явно называется, вы заметите, что позвонил gc.supressfinalize (это), который представляет собой подсказку производительности для сборщика мусора. Он позволяет узнать, что объект не должен быть завершен, когда он собирается. Доработка не дешевая.
class MyObject : IDisposable {
~MyObject() {
Dispose(false);
}
public void Dispose() {
Dispose(true);
GC.SupressFinalize(this);
}
protected virtual void Dispose(bool disposing) {
if (disposing) {
// dispose of managed resources
}
// dispose of unmanaged resources
}
}