Интерфейс использования дизайна наследования + абстрактный класс. Хорошая практика?
Я предпочитаю простой цикл forEach, например:
var hobby = ["sport", "art", "music"];
var message = "I love sport!";
var idxs = []
var vals =[]
hobby.forEach(function(val, idx){
if (message.includes(val))
{
idxs.push(idx);
vals.push(val)
}
});
if (vals.length !== 0) {
console.log('You like ' + vals.join(','));
console.log('Your hobby indices: ' + idxs.join(','));
} else {
console.log('You Like Nothing!!');
}5 ответов
Потребность в цепочке наследования сомнительна в целом.
Однако определенный сценарий объединения абстрактного базового класса с интерфейсом.. Я вижу его этот путь:
Если у Вас есть абстрактный базовый класс как это, у Вас должен также быть соответствующий интерфейс. Если у Вас есть интерфейс, то используйте абстрактный базовый класс только там, где цепочка наследования разумна.
Тем не менее, если я запишу библиотеку, и это - часть моего API/платформы, то я буду обычно включать "реализацию по умолчанию", которая может использоваться в качестве базового класса. Это реализует методы интерфейса наивным, общим способом, если это возможно, и оставлять остальных для наследников для реализования/переопределения по мере необходимости.
Это - просто удобная функция библиотеки, хотя, для помощи людям, которые хотят реализовать интерфейс путем обеспечения функционального примера, который может покрыть большую часть того, что они уже должны реализовать.
Короче говоря, интерфейс более ценен, чем базовый класс, но базовый класс мог бы сэкономить много времени и уменьшить ошибочные интерфейсные реализации.
Вам нужен интерфейс; Вы можете или, возможно, не нуждаетесь в абстрактном классе.
в целом, если можно обеспечить некоторое полезное поведение в базовом классе, затем обеспечьте базовый класс; если базовый класс не завершен, отдельно затем делают это абстрактным (MustInherit в языке VB)
иначе интерфейс достаточен
Ну, это - то, что, где ключевое слово для. Вероятно, необходимо оценить объектную модель, чтобы удостовериться, что глубина наследования необходима. Глубокие иерархии наследования имеют тенденцию усложнять проекты и обычно являются красным флагом, но он зависит от ситуации.
Обычно, Вам не нужен абстрактный класс для осуществления функциональности, о которой Вы говорите со списками, и интерфейсы являются 'предпочтительным' методом для определения ограничений типа. Я только использовал бы абстрактную версию Вашего класса, если существует общая функциональность, которую Вы хотите инкапсулировать.
Короткий ответ: удостоверьтесь, что Вы не идете сумасшедшее наследование.
Надежда, которая помогает!
Вы могли также просто использовать интерфейсы. Нет никакой причины использовать абстрактный класс.
public interface Foo : IFoo
{
}
public interface Bar : IFoo
{
}
Я не совсем уверен, является ли это тем, что Вы ищете, но возможно то, что Вы хотите сделать, фрагментировать интерфейс все вместе и сделать это:
abstract class Base
{
public abstract string ToCMD();
}
abstract class Foo : Base { }
abstract class Bar : Base { }
Надо надеяться, у Вас есть другие участники в Foo и Bar классы! Это позволит, Вы любому ограничиваете свой пользовательский набор Base или просто используйте плоскость List<Base>.