Итак, несколько вещей, которые выделяются идеей этого примера.IMotorcycle
не является IVehicle
, что не имеет смысла в этом примере, поскольку предполагается, что не было бы класса, который бы не наследовал функции от IMotorcycle
и IVehicle
.Поэтому изменение IMotorcycle
для наследования от IVehicle
сделает вещи более логичными.Затем вам нужно понять, что LSP и ISP работают с другими принципами SOLID для работы.Пример не удовлетворяет принципу единственной ответственности и открытого закрытого типа.
Класс Start
не следует изменять после добавления логики.Таким образом, если вы добавили новый класс, который реализовал IVehicle
, и какой-то другой класс / интерфейс (который не наследуется от IVehicle
), то логику пришлось бы изменить, то есть она не закрыта для изменений.В классе Start
должны быть переопределенные или перегруженные методы, чтобы можно было использовать переадресацию методов для обработки различных типов.
Но есть и проблема единой ответственности, которая не распространяется на класс.Если вы хотите обрабатывать общие взаимодействия с транспортными средствами, следует передать объект, который расширяет IVehicle
, но если вы создаете / строите экземпляр IVehicle
, то должен применяться шаблон фабрики / строителя.В любом случае класс Start
должен создавать, управлять или взаимодействовать с объектами IVehicle
, не создавая, не управляя и не взаимодействуя с объектами.Независимо от того, какая функция вызывается в классе Start
, она также должна реализовывать SOLID, что означает, что она ожидает только объект IMotorcycle
или IVehicle
(с IMotorcycle
наследованием от IVehicle
.) Таким образом, функция имеет единственную функциональность, делаетне нужно обновлять после добавления новых классов.
Это еще не все, но я чувствую, что уже дал много информации.Главное, о чем вы должны подумать, - это чтобы принципы SOLID работали вместе, а не изолированно.Если вы хотите использовать функции, специфичные для типа, из одного объекта после получения его от метода, который возвращает интерфейс более высокого уровня, вам нужно сделать так, чтобы интерфейс более высокого уровня имел функции, которые при реализации будут вызывать функции, специфичные для типа.В вашем случае у вас может быть что-то вроде этого:
public interface IVehicle
{
string Brand { get; set; }
string Model { get; set; }
int HorsePower { get; set; }
void setInformation;
InformObject getInformation;
}
public interface IMotorcycle : IVehicle
{
DateTime DateCreated { get; set; }
}
public abstract class Vehicle : IVehicle
{
public string Brand { get; set; }
public string Model { get; set; }
public int HorsePower { get; set; }
public void setInformation(string brand, string model, int hPower){
Brand = brand;
Model = model;
HorsePower = hPower;
}
public InfoObject getInformation(){
return new InfoObject(Brand, Model, HorsePower);
}
}
public class Car : Vehicle, IVehicle
{ }
public class Motorcycle : Vehicle, IVehicle, IMotorcycle
{
public DateTime DateCreated { get; set; }
}
public class InfoObject
{
public InfoObject(string brand, string model, int hPower){
Brand = brand;
Model = model;
HorsePower = hPower;
}
public InfoObject(string brand, string model, int hPower, DateTime timeCreated){
Brand = brand;
Model = model;
HorsePower = hPower;
DateCreated = timeCreated;
}
public string Brand { get; set; }
public string Model { get; set; }
public int HorsePower { get; set; }
DateTime DateCreated { get; set; }
}
Тогда вы будете иметь информацию как объект, который ожидает ограниченный объем информации.Это не должно отражать иерархию IVehicle
.Это просто объект, который должен иметь все транспортное средство, и все транспортные средства могут взаимодействовать с ним, а другой специфичный для типа код может взаимодействовать для обработки информации, специфичной для этого типа.Это не очень хороший пример, и его просто следует использовать в качестве общего взгляда на то, как вы могли бы улучшить свои интерфейсы, потому что нужно сделать больше, чтобы подчеркнуть функциональность, если вы планируете использовать IVehicle
во всей вашей системе.Геттер и сеттеры - не лучшая идея для создания интерфейса.