Суслов 363

[limard687]

https://github.com/HukuTa45/HomeWork363/blob/a799518340267c6510e84def1ebcfcbfd0a98226/ConsoleApp1/FirstExample.cs#L3

Чтобы исправить нарушение этого принципа, необходимо использовать внедрение зависимостей (Dependency Injection). Для этого нужно передавать объект EmailService в конструктор класса Notification:

namespace ConsoleApp1;

public class Notification { private EmailService _emailService;

public Notification(EmailService emailService)
{
    _emailService = emailService;
}

public void Get(string message)
{
    _emailService.SendEmail(message);
}

}

public class EmailService { public void SendEmail(string message) { Console.WriteLine("Sending email: " + message); } }

https://github.com/HukuTa45/HomeWork363/blob/a799518340267c6510e84def1ebcfcbfd0a98226/ConsoleApp1/SecondExample.cs#L21

метод MakeMeow() не существует в базовом классе Animal, но переопределен в классе Cat.

namespace ConsoleApp1;

public class Animal { public virtual void MakeSound() { Console.WriteLine("Some generic animal sound"); } }

public class Dog : Animal { public override void MakeSound() { Console.WriteLine("Woof"); } }

public class Cat : Animal { public override void MakeSound() { Console.WriteLine("Meow"); } }

public class Fish : Animal { public override void MakeSound() { throw new InvalidOperationException("Fish cannot make sound"); } }

https://github.com/HukuTa45/HomeWork363/blob/a799518340267c6510e84def1ebcfcbfd0a98226/ConsoleApp1/ThirdExample.cs#L5

Данный код не соответствует принципу, так как каждый раз, когда появляется новый тип платежа (например, новый тип карты), необходимо будет изменять класс PP, добавлять новые проверки в метод PP.

Для исправления нарушения принципа, возможно, целесообразно использовать принцип полиморфизма и создание отдельных классов для каждого типа платежа, которые реализуют общий интерфейс IPaymentMethod. Тогда код будет следующим:

namespace ConsoleApp1;

public interface IPaymentMethod { decimal ProcessPayment(); }

public class CreditCard : IPaymentMethod { public decimal ProcessPayment() { // Какая-то логика обработки платежа через кредитную карту return 100.00m; } }

public class Mir : IPaymentMethod { public decimal ProcessPayment() { // Какая-то логика обработки платежа через Mir return 150.00m; } }

public class PP { public decimal PP(IPaymentMethod paymentMethod) { return paymentMethod.ProcessPayment(); } }

Надеюсь, я не ошибся в примерах.

[HukuTa45]

Чтобы исправить нарушение этого принципа, необходимо использовать внедрение зависимостей (Dependency Injection). Для этого нужно передавать объект EmailService в конструктор класса Notification:

Ввести интерфейс IMessageService и сделать так, чтобы Notification зависел от абстракции, а не от конкретной реализации.

метод MakeMeow() не существует в базовом классе Animal, но переопределен в классе Cat.

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

Данный код не соответствует принципу, так как каждый раз, когда появляется новый тип платежа (например, новый тип карты), необходимо будет изменять класс PP, добавлять новые проверки в метод PP.

А какому принципу то?)

[limard687]

Забыл указать, К 1 принципу - принцип Инверсии зависимостей К 2 примеру - принцип Liskov Substitution Principle К 3 примеру - принцип открытости/закрытости