Благодаря за отговора! Има ли на места, където мога да вдигна абстракцията и да запазя обекта в интерфейс? Говоря за Add методите в интерфейсите (AddMission и другите) и листовете.

обект в интерфейс айде не....  

 това в командо интерфейса е безумие... тея неща не се държат там.. Сега теоритично може да се слагат структури и properties в интерфейсите но не се прави не е добра практика. А колко повече да вдигаш абстракцията няма смисъл.То идеята и е да вдигнеш общите неща. Сега това че командото има addmission ами ок да си стой само при него.

Дали ти трябва отделен интерфейс icommando не можеше всичките да са просто soldier или isoldier.  Абстракцията е хубаво нещо ама човек не трябва да се увлича в нея.

Така ни го показаха на упражнението, така го правим (ICommando интерфейса с Add метода в него). Условието на задачата гласи да направим за всеки клас интерфейс.

обект в интерфейс айде не....

Извинявай за фрапантната грешка! Мисля, че се разбра какво исках да кажа:

public interface IAnimal {}

public abstract class Mammal {}

public class Person : Mammal, IAnimal {}

Animal person = new Person();

Mammal personOne = new Person();

Person personTwo = new Person();

Можеше просто да ме поправиш, за да знам как да го кажа следващия път... Просто исках да напиша тази задача като хората, съобразено, разбира се, с това, което сме учили. Все още не съм гледал лекцията за полиморфизъм, а мисля, че точно това се разглежда там.

Доколкото разбрах от коментара ти, имам прекалено много интерфейси. И аз мисля, че не е необходимо за всеки клас да имам интерфейс, но това изисква задачата, и така съм го направил. Вече в Engine използвам switch-case и изглежда better.

това с класовете е така,дори преди година на един колега му обеснявах и го имам записано на видео но там влязохме и малко в дълбокия рефлекшън и взимане на методите runtime.

Сега за абстракцията това е дълга тема. Зависи как ти е удобно зависи в какъв екип работиш някои хора предпочитат като теб да го раздробят всичко аз не го харесвам тоя подход. Абстракцията е да събереш еднаквите логически неща на едно място.

Не помня задачата точно или да и имам условието но принципно аз как бих подходил.

Един абстрактен клас soldier който общо взето май ще държи само ToString() и още нещо общо между всичките и после всеки клас ще го наслед и  толкова той ще си държи вече там мисии и тн специфичните неща.Дали ми трябва interface за 1 метод абсолютно не, дали бих си сложил струкрурите в интерфейса пак не.Едната причина да не се слагат е че там всичко е публично.Ако искам да направя публична колекция ще я инициализирам в класа.. Примерно ако приемем твоя пример с Ianimal да кажем че тоя интерфейс държи Breath() walk()  общи за всички бозайници неща.Какво ще стане ако там му сложа и Ienumerable<Person> Relatives да задължа всичките класове да го имат това ли безумно е.

Тея неща на теория звучат много забавно но на практика като сте голям екип и имате конвенции. Все пак много и различни проекти и идеята е да можете лесно да си разчитате кода ако има хиляда интерфейса търсенето на кои метод и къде и кое къде инициализира и кое вкарва DI става страшно. Същата работа и с полиморфизма много е полезен обаче на практика не строиш огромни пирамиди от наследявания и подобни защото в базата ти става малко мазало дали ще избереш table hieraracy или table per class все тая забавен смях е да си ги управляваш.

За engine класа аз бих го направил с reflection 10 -20 реда няма да ми е повече, а и е забавно но е малко объркващо отначало.