Где-то в степиПравильно ли сконструировали тип?
Не совсем, классическая реализация disposable-паттерна включает в себя два перегруженных метода Dispose - один public и без параметра, второй protected (либо private, если класс sealed) с параметром, указывающим на то, откуда происходит вызов - т.е. как-то так:


Выполнять вызов GC.SuppressFinalize при вызове Dispose из финализатора избыточно - объект уже попал в обработку из очереди на финализацию (а вот промаркировать его, как не требующего финализации, при вызове Dispose извне очень даже нужно и полезно). Плюс, если операция диспозинга сводится только к диспозингу инкапсулируемого объекта, то при вызове Dispose извне из очереди на финализацию нужно удалить и экземпляр объекта-враппера (Class).
Dima TЕМНИП надо инициализировать, дефолтных значений C# не признает, хотя и забивает все нулями.
Не надо:
10.4.4 Field initialization
The initial value of a field, whether it be a static field or an instance field, is the default value (Section 5.2) of the field's type.
Обязательны для инициализации локальные переменные, но не поля класса.

Где-то в степиСон Веры Павловны,
то есть если класс не sealed, виртуал желателен ( писал выше) а если не sealed - то и так сойдет?
Нет, перегрузка Dispose с параметром в общем случае нужна всегда. "И так сойдет" в том случае, если в вашем классе нужно осовбождать только managed-ресурсы, реализующие IDisposable. Если же нужно освобождать какие-то unmanaged-ресурсы (например, IntPtr на какой-нибудь буфер), то это освобождение должно выполняться всегда (см. здесь , например). И всё равно даже в таком случае рекомендуется сто раз подумать, нужен ли финализатор, т.к. сборка мусорных объектов с финализаторами намного затратнее, чем без финализаторов (у Рихтера это подробно расписано - почему и как). Рекомендуется, например, рассмотреть вариант с CriticalFinalizerObject.
Резюмируя: если у вас враппится только IDisposable-объект - оставил бы, как есть, и выкинул бы финализатор.

Где-то в степине соглашусь, где же защита от дурака - программист проспал using?
Выше же писал - например, CriticalFinalizerObject - это во-первых. Во-вторых - если у инкапсулируемого IDisposable есть финализатор, то у враппера он вообще не нужен. В третьих, обязательного-кровь-из-носу освобождения требуют только unmanaged-ресурсы, и то далеко не все - большинство из них автоматически освободятся при закрытии процесса (как хэндл глобального хоткея, например), так что "программист проспал using" не приведет к концу света.
Dima TГде-то в степи не соглашусь, где же защита от дурака - программист проспал using?
Деструктор объекта вызывается сборщиком мусора, из-за этого и родились IDisposable, using и т.д.
Вовсе нет, и даже почти с точностью до наоборот - вызов Dispose вполне детерминирован и явен, в отличие от вызова финализатора. Ну, и реализация disposable-паттерна имеет усеченные варианты, в которых финализатора нет.

Dima TИМХУ разработчики C# накосячили в синтаксисе: ~Class() это синтаксис описания деструктора в С++, что в итоге приводит к непонимаю как работает код.
Рихтер, CLR via C#If you’re familiar with C++, you’ll notice that the special syntax C# requires for defining a Finalize method looks just like the syntax you’d use to define a C++ destructor. In fact, the C# Programming Language Specification calls this method a destructor. However, a Finalize method doesn’t work like an unmanaged C++ destructor at all, and this has caused a great deal of confusion for developers migrating from one language to another. The problem is that developers mistakenly believe that using the C# destructor syntax means that the type’s objects will be deterministically destructed, just as they would be in C++. However, the CLR doesn’t support deterministic destruction, preventing C# from providing this mechanism.
Chapter 21 Automatic Memory Management (Garbage Collection) / Using Finalization to Release Native Resources
Видимо, вы этого не читали - почитайте, это полезная книга.

А IDisposable - вовсе не костыль, просто следует четко понимать разницу (касательно CLR) между освобождением ресурсов класса, и уничтожением самого экземпляра класса. Первая задача вполне управляема и детерминирована, вторая - неуправляема и недетерминирована (её выполняет GC). Даже если попытаться дернуть финализатор через рефлекшн (метод Finalize), это к освобождению памяти, заянтой под объект, не приведет.

Roman Mejtesда ни чего не будет, если метод SuppressFinalize не будет вызвать в реализации Disposible, то объект просто будет поставлен в очередь на финализацию, а дальше уже зависит от реализации этого метода.
Не будет удален из очереди на финализацию. Ставится от в эту очередь при создании экземпляра, когда CLR видит у объекта финализатор.