Абстрактный базовый класс по сравнению с реальным классом как SuperType

Да, хотя вы также можете использовать интерфейс, чтобы заставить класс реализовывать определенные методы.

Другая причина использования абстрактного класса в отличие от конкретного класса состоит в том, что абстрактный класс, очевидно, не может быть создан. Иногда вы также не хотите, чтобы это происходило, поэтому лучше всего использовать абстрактный класс.

Прежде всего, шаблон стратегии почти никогда не следует использовать в современном C #. Это в основном для таких языков, как Java, которые не поддерживают указатели на функции, делегаты или функции первого класса. Вы увидите это в более старых версиях C # в интерфейсах, таких как IComparer.

Что касается абстрактного базового класса по сравнению с конкретным классом, ответ в Java всегда: «Что лучше работает в этой ситуации?» Если ваши стратегии могут делиться кодом, то пусть они это делают.

Шаблоны проектирования - это не инструкции о том, как что-то делать. Это способы категоризации того, что мы уже сделали.

Абстрактные базовые классы обычно используются в сценариях, где разработчик хочет принудительно создать архитектурный шаблон, в котором определенные задачи должны выполняться одинаково всеми классами, в то время как другое поведение зависит от подклассов. Пример:

public abstract class Animal{

public void digest(){

}

public abstract void sound(){

}
}

public class Dog extends Animal{
public void sound(){
    System.out.println("bark");
}
}

Шаблон Stratergy предлагает дизайнерам использовать поведение композиции в случаях, когда для поведения существуют семейства алогирм.

Если клиент полагается на «контракт подразумеваемого поведения», он запрограммирован против реализации и против негарантированного поведения. Переопределение метода при соблюдении контракта только обнаруживает ошибки в клиенте, но не вызывает их.

OTOH, ошибка принятия контрактов, которых нет, с меньшей вероятностью вызовет проблемы, если рассматриваемый метод не является виртуальным, т. Е. Его переопределение не может вызвать проблемы, потому что его нельзя переопределить. Только если реализация исходного метода будет изменена (при соблюдении условий контракта), это может сломать клиента.

Программа для взаимодействия, а не для реализации имеет мало общего с абстрактными и конкретными классами. Помните шаблон метода шаблон ? Классы, абстрактные или конкретные, являются деталями реализации.

Причина использования абстрактных классов вместо конкретных классов заключается в том, что вы можете вызывать методы, не реализуя их, а вместо этого оставив их реализовывать подклассам.

Программирование интерфейса - это другое дело - оно определяет , что ваш API делает, а не , как он это делает. И это обозначается интерфейсами.

Обратите внимание на одно ключевое отличие - у вас могут быть защищенные абстрактные методы, что означает, что это деталь реализации. Но все методы интерфейса общедоступны - это часть API.

Вопрос о том, должен ли базовый класс быть абстрактным или конкретным, зависит, IMHO, в основном от того, будет ли полезен объект базового класса, реализующий только поведение, общее для всех объектов класса. Рассмотрим WaitHandle. Вызов "wait" на нем приведет к блокировке кода до выполнения некоторого условия, но не существует общего способа сообщить объекту WaitHandle, что его условие выполнено. Если бы можно было инстанцировать "WaitHandle", а не только инстанцировать экземпляры производных типов, то такой объект должен был бы либо никогда не ждать, либо ждать вечно. Последнее поведение было бы довольно бесполезным; первое могло бы быть полезным, но может быть достигнуто почти так же хорошо с помощью статически выделенного ManualResetEvent (я думаю, что последний тратит несколько ресурсов, но если он статически выделен, общая потеря ресурсов должна быть тривиальной).

Во многих случаях, я думаю, я бы предпочел использовать ссылки на интерфейс, а не на абстрактный базовый класс, но предоставлять вместе с интерфейсом базовый класс, который обеспечивает "реализацию модели". Таким образом, в любом месте, где можно было бы использовать ссылку на MyThing, можно было бы поставить ссылку на "iMyThing". Вполне возможно, что 99% (или даже 100%) объектов iMyThing на самом деле являются MyThing, но если кому-то когда-нибудь понадобится иметь объект iMyThing, который наследуется от чего-то другого, это можно сделать.