IDisposable interface pattern

Example implementation of IDisposable

public class MyResource : IDisposable
{
    public MyResource(IntPtr handle)
    {
        this.handle = handle;
    }

    public void Dispose()
    {
        Dispose(disposing: true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if(!this.disposed)
        {
            if(disposing)
            {
                component.Dispose();
            }
           
            CloseHandle(handle);
            handle = IntPtr.Zero;
            disposed = true;
        }
    }

    ~MyResource()
    {
        Dispose(disposing: false);
    }
}

MyResource object have pointer which is unmanaged. This is why this class should implement IDisposable interface. Implementation should be correct according to recommended pattern (see below for documentation).

There a re few points to highlight here:

  • IDisposable is meant to be used with using keyword.
  • using is calling IDisposable.Dispose method in the background
  • This method should be public then
  • protected Dispose(bool) method is meant to be called from finalizer via GC
  • SuppressFinalize disables this object from finalization mechanism in GC to prevent finalization code to be executed second time (see here)
  • Finalization is called from GC *only* if whoever is using this object will forget to use using or otherwise fail to call Dispose manually
  • Dispose must be save to call multiple times (if(!this.disposed))
  • Dispose(true) is meant to dispose also any other managed resources this implementation relies on
  • Dispose(false) is meant to be called from GC finalization mechanism. All managed resource are most likely already disposed so we cannot dispose them again

Further read:

https://learn.microsoft.com/en-us/dotnet/api/system.idisposable?view=net-6.0

What is DDD

  • software design approach
  • software should be driven by business domain
  • pieces of software should match the business domain
  • goals:
    • domain is primary focus
    • complex design should base on model of the domain
    • devs and business should continuously work on refining this model to address changes in business
  • common language for defining a business model of the domain
  • complex logic should be abstracted to domain

Further read:

https://en.wikipedia.org/wiki/Domain-driven_design

What is BDD

  • based on TDD
  • better collaboration between devs, QAs and business than TDD
  • behavioral tests first, implementation second
  • behavioral tests should be easy to understand, simple
  • those tests should be written in specific language, possible to understood by business
  • combines idea of unit tests naming, acceptance tests standard agile framework (As a XXX I want YY to achieve ZZ), and acceptance criteria with Gherkin

Further read:

https://en.wikipedia.org/wiki/Behavior-driven_development