Design pattern for object assuming new features at runtime?

Suppose I have a class House.

I want to be adding specifications to my house, like a Garage, a SwimmingPool or a Garden, each coming with its own set of new methods.

If I used inheritance, I would have subclasses HouseWithGarage, HouseWithSwimmingPool and HouseWithGarden. But what if I wanted to have an object with a garage and a garden at the same time? What if later I wanted to add a swimmingpool to that same object at runtime?

Obviously inheritance doesn't work well here. Are you aware of any design pattern appropriate for this kind of problem?

The pattern that closest describes what you are looking for is the Composite Pattern, described in "Design Patterns" by Gamma et al.

From the Gamma book:

Component

1. Declares the interface for object in the composition.
2. Implements default behavior for the interface common to all classes, as appropriate.
3. Declares an interface for accessing and managing its child components.
4. Optionally defines an interface for accessing a component's parent in the recursive structure and implements it if that's appropriate.

Leaf

1. Represents leaf objects in the composition. A leaf has no children.
2. Defines behavior for primitive objects in the composition.

Composite

1. Defines behavior for components having children.
2. Stores child components.
3. Implements child-related operations in the Component interface.

A House will be a Component. Garage, Garden and SwimmingPool will be either a Leaf or a Composite depending on whether they are composed of child components or not.

Needless to say (?), these interfaces can many operations besides operation().

Better with "has-a" than "is-a", which supports your statement regarding inheritance.

public interface IFeature { ... }

public class Garage : IFeature
{
   public Garage(string colour){ ... }
}

public class House 
{
  private readonly IList<IFeature> _features = new List<IFeature>();

  public House() { ... }

  public House(IList<IFeature> features) { _features = features; }

  public IFeature AddFeature(IFeature feature)
  {
     _features.Add(feature);
     return feature;
  }
}

Based on your comment you want to hold a collection of components at runtime and force your clients to make sure that a given component is added before working with it. I'm not aware of a design pattern for that, but you can simply hold a dictionary of attached components and look them up by type:

public class House
{
    private readonly Dictionary<Type, object> _components = new Dictionary<Type, object>();

    public void AddComponent<T>([DisallowNull] T component) where T : class, IHouseComponent
    {
        _components.Add(typeof(T), component);
    }

    [return: MaybeNull]
    public T GetComponent<T>() where T : class, IHouseComponent
    {
        return _components.TryGetValue(typeof(T), out var component) ? (T) component : null;
    }
}

So when you have a house and a garage you can do:

House house;
Garage garage;

...

house.AddComponent(garage);

...

// somewhere else
var garage = house.GetComponent<Garage>();

IHouseComponent is a marker interface so that you have to explicitly implement it before adding it to a House (so you can't just add any object).

If it's possible for multiple components of the same type to be added, just hold a list of them in the dictionary:

private readonly Dictionary<Type, List<object>> _components = ...

public void AddComponent<T>(...)
{
    if (_components.TryGetValue(typeof(T), out var list)
    {
        list.Add(component);
    }
    else
    {
        _components.Add(typeof(T), new List<object>{ component });
    }
}

public IEnumerable<T> GetComponents<T>() ...
{
    if (_components.TryGetValue(typeof(T), out var list))
    {
        return list.ToList();
    }
    else
    {
        return Enumerable.Empty<T>();
    }
}