По поводу п.3 - наследование - очевидно чтобы вызывать однотипно на базе контейнера методы похожие по смыслу, а специфическое держать в отдельном методе и отдельном классе.
Иначе эту специфику в виде условий пришлось бы тащить внутрь единого класса.
Собственно и вопрос в том, можно ли архитектурно условие с cast - улучшить? Моё мнение - нет.
Есть стандартный алгоритм чтобы приблизительно понять какой модуль неисправен:
отключаем периферию по-максимуму, оставляем только блок питания, материнку, оперативку, видеокарту и монитор.
Предварительно лучше зафоткать что и куда и как было вставлено.
Если проходит этап первоначального теста POST и экран показывает что нет носителя с которого можно загрузиться и долго так работает, то начинаем добавлять периферию - только внимательно, что-то можно подключать "на горячую", а что-то типа жёсткого диска не рекомендуется, лучше лишний раз перестраховаться и предварительно отключить питание. всего компьютера.
А что из деталей стучит? Бывает на материнской плате установлен динамик, который количеством и длительностью пиков сообщает о неисправности ОЗУ или видеокарты.
Иначе эту специфику в виде условий пришлось бы тащить внутрь единого класса.
Собственно и вопрос в том, можно ли архитектурно условие с cast - улучшить? Моё мнение - нет.