Перечислите основные принципы разработки программного обеспечения.

1. DRY (Don't Repeat Yourself — Не Повторяйся)

• Суть: Каждый фрагмент знания или логики должен иметь единственное, однозначное представление в системе.
• Почему: Устраняет дублирование, упрощает поддержку (изменения вносятся в одном месте), снижает вероятность ошибок.
• Как: Выносить повторяющийся код в методы, утилитные классы, использовать наследование и композицию.

// Нарушение DRY
class UserReport {
    void print() { System.out.println("Headern" + generateData()); }
}
class AdminReport {
    void print() { System.out.println("Headern" + generateData()); }
}

// Следование DRY
abstract class Report {
    abstract String generateData();
    void print() { // Общая логика
        System.out.println("Headern" + generateData());
    }
}
class UserReport extends Report { /* ... */ }
class AdminReport extends Report { /* ... */ }

2. KISS (Keep It Simple, Stupid — Делай Проще)

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

3. YAGNI (You Aren't Gonna Need It — Вам Это Не Понадобится)

• Суть: Не добавляйте функциональность, пока она не понадобится явно.
• Почему: Разработка "на будущее" тратит время, увеличивает сложность кодовой базы и часто приводит к созданию неиспользуемого или неправильного кода.

4. Принципы SOLID (Пять принципов ОО-дизайна)

• S — Single Responsibility (Принцип единственной ответственности): Класс должен иметь только одну причину для изменения.
• O — Open/Closed (Принцип открытости/закрытости): Классы должны быть открыты для расширения, но закрыты для модификации.
• L — Liskov Substitution (Принцип подстановки Барбары Лисков): Объекты базового класса должны быть заменяемы объектами производных классов без изменения корректности программы.
• I — Interface Segregation (Принцип разделения интерфейсов): Много специализированных интерфейсов лучше одного общего.
• D — Dependency Inversion (Принцип инверсии зависимостей): Зависимости должны строиться на абстракциях, а не на деталях. Модули верхнего уровня не должны зависеть от модулей нижнего уровня. Оба должны зависеть от абстракций.

// Пример DIP
interface NotificationService { void send(String message); }

class EmailService implements NotificationService { /* ... */ }
class SMSService implements NotificationService { /* ... */ }

class OrderProcessor {
    private final NotificationService notifier; // Зависимость от абстракции
    public OrderProcessor(NotificationService notifier) { // Внедрение через конструктор
        this.notifier = notifier;
    }
    public void process(Order order) {
        // ... логика
        notifier.send("Order processed"); // Использование абстракции
    }
}

5. Law of Demeter (Закон Деметры / Принцип наименьшего знания)

• Суть: Объект должен иметь как можно меньше знаний о структуре и свойствах других объектов. Метод объекта должен вызывать только методы:
  1. Самого объекта.
  2. Своих параметров.
  3. Любого созданного им объекта.
  4. Своих прямых компонентов (полей).
• Почему: Уменьшает связность между классами, делает систему более гибкой и удобной для тестирования.

// Нарушение: объект "залезает" слишком далеко
customer.getWallet().getMoney().getAmount();

// Следование: делегирование ответственности
customer.getWalletAmount(); // Метод в классе Customer делегирует вызов Wallet

Следование этим принципам ведёт к созданию поддерживаемого, гибкого и тестируемого кода.