Czy w książce jest błąd?

Witam,
w pewnej książce do c# znalazłem coś takiego:

public IEnumerable<Enemy> Enemies {get; private set; }

private void NewLevel(Random random)
        {
            level++;
            switch(level)
            {
                case 1:
                    Enemies = new List<Enemy>();
                    Enemies.Add(new Bat(this, GetRandomLocation(random)));
                    WeaponInRoom = new Sword(this, GetRandomLocation(random));
                    break;
            }
        }

Problem w tym, że dostaję error:

'IEnumerable<Enemy>' does not contain a definition for 'Add' and no extension method 'Add' accepting a first argument of type 'IEnumerable<Enemy>' could be found (are you missing a using directive or an assembly reference?)

Czy to faktycznie błąd, że zamiast List<Enemy> napisali IEnumerable, czy da się to jednak jakoś zrobić?

Sprawdźmy poprzez autoimplementację interfejsów...

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ForProgCS
{
    class Data { }

    class EnumerableTest : IEnumerable<Data>
    {

        public IEnumerator<Data> GetEnumerator()
        {
            throw new NotImplementedException();
        }

        System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
        {
            throw new NotImplementedException();
        }
    }

    class EnumerableTest : IList<Data>
    {

        public int IndexOf(Data item)
        {
            throw new NotImplementedException();
        }

        public void Insert(int index, Data item)
        {
            throw new NotImplementedException();
        }

        public void RemoveAt(int index)
        {
            throw new NotImplementedException();
        }

        public Data this[int index]
        {
            get
            {
                throw new NotImplementedException();
            }
            set
            {
                throw new NotImplementedException();
            }
        }

        public void Add(Data item)
        {
            throw new NotImplementedException();
        }

        public void Clear()
        {
            throw new NotImplementedException();
        }

        public bool Contains(Data item)
        {
            throw new NotImplementedException();
        }

        public void CopyTo(Data[] array, int arrayIndex)
        {
            throw new NotImplementedException();
        }

        public int Count
        {
            get { throw new NotImplementedException(); }
        }

        public bool IsReadOnly
        {
            get { throw new NotImplementedException(); }
        }

        public bool Remove(Data item)
        {
            throw new NotImplementedException();
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
        }
    }
}

I już wiadomo.
Tak na szybko powinno być IList.

@john_klamka, słyszałeś o czymś takim jak statyczne typowanie?
Jak zachowa się Twój kod, gdy zadeklarowane pole typu IEnumerable<Enemy> będzie przechowywało zmienną, która nie jest List<Enemy>?
Czemu tworzyć pole typu IEnumerable<T> skoro zakładamy, że będziemy do niego dodawać nowe obiekty?
Jaki jest sens rzutowania czegoś nad czym mamy pełna kontrolę? Przecież jako autorzy klas przecież możemy sobie dowolnie manipulować szczegółami implementacji.
Czy przechowywałbyś liczbę w polu o typie string i konwertował na typ liczbowy przy okazji każdej operacji matematycznej?

@john_klamka przecież takie podejście jest po prostu brzydkie. Od razu robi się odpowiedni interfejs i już, a nie inny tylko po to, żeby zrobić do niego rzutowanie na właściwy. Tak się po prostu nie robi, to powoduje sytuację kiedy patrząc na wycinek kodu zwyczajnie już nie wiadomo z jakim obiektem ma się do czynienia. Jak będziesz chciał np. zrobić DI z jakiegoś IoC to w argumentach konstruktorów też będziesz podawał takie interfejsy na około żeby później rzutować je do właściwych? No chyba nie. To co tam jest napisane to zwykła pomyłka z książki, a już na pewno nie praktyka.