Окей, здесь скорее согласен, бессмысленные перестановки кода без цели вряд ли будут успешными. Если вы хорошо не можете объяснить, зачем вы что-то переставляете, не делайте этого
2. Принцип открытости/закрытости
> Тут всегда вопрос в том, а появится ли еще один тип заказа в будущем? Или мы просто так добавили 2 класса и интерфейс
Здесь вопрос сразу: если это никто и не будет в будущем трогать, то почему не использовать эту известную всем идиому с имплементацией интерфейса, а не запихивать if..else в методы. А если у калькулятора будет не один calculateTotal, а 4-5 методов?
3. Liskov Substitution Principle
> В данном случае строгое следование LSP привело к: Увеличению количества кода; Дублированию логики чтения файла; Усложнению структуры проекта
На мой взгляд стало понятнее и проще. Снова мы не лезем с непонятной логикой в тела методов, а четко разграничили разные сущности с общим интерфейсом. Вроде бы win-win. Кода стало больше: у вас есть оптимизация чанков сборщиком и всякие tree-shaking'и в бандлере
4. Interface Segregation Principle: Размер имеет значение
Не совсем ведь. Это похоже на SRP, но диктует уже то, что не нужно классу давать методы, которые ему не нужны. То, что в результате получаются маленькие интерфейсы, это следствие, а не причина
> no code should be forced to depend on methods it does not use
Иначе вы либо игнорируете некорректное наследование, что рано или поздно выстрелит в ногу, либо делаете странные вещи и даете классам ненужные методы, которые по идее не должны вообще работать, если даты под это нет у класса, а ее не должно быть, иначе разделять не нужно и ISP не подходит
5. Dependency Inversion Principle: Инверсия ради инверсии
> DIP часто превращается в догму "всегда используйте интерфейсы", что приводит к созданию ненужных абстракций
Либо я не понял, либо я не видел, чтобы так происходило. DIP это возможно, один из наиболее важных принципов в SOLID, он чаще всего как раз полезный, чем не полезный: легче тестирование, а уже этого много стоит, меньше классы, легче прийти к адаптерам, легче формируется точки входа в модулях
по пунктам SOLID
1. SRP не SRP
Окей, здесь скорее согласен, бессмысленные перестановки кода без цели вряд ли будут успешными. Если вы хорошо не можете объяснить, зачем вы что-то переставляете, не делайте этого
2. Принцип открытости/закрытости
> Тут всегда вопрос в том, а появится ли еще один тип заказа в будущем? Или мы просто так добавили 2 класса и интерфейс
Здесь вопрос сразу: если это никто и не будет в будущем трогать, то почему не использовать эту известную всем идиому с имплементацией интерфейса, а не запихивать if..else в методы. А если у калькулятора будет не один calculateTotal, а 4-5 методов?
3. Liskov Substitution Principle
> В данном случае строгое следование LSP привело к: Увеличению количества кода; Дублированию логики чтения файла; Усложнению структуры проекта
На мой взгляд стало понятнее и проще. Снова мы не лезем с непонятной логикой в тела методов, а четко разграничили разные сущности с общим интерфейсом. Вроде бы win-win. Кода стало больше: у вас есть оптимизация чанков сборщиком и всякие tree-shaking'и в бандлере
4. Interface Segregation Principle: Размер имеет значение
Не совсем ведь. Это похоже на SRP, но диктует уже то, что не нужно классу давать методы, которые ему не нужны. То, что в результате получаются маленькие интерфейсы, это следствие, а не причина
> no code should be forced to depend on methods it does not use
Иначе вы либо игнорируете некорректное наследование, что рано или поздно выстрелит в ногу, либо делаете странные вещи и даете классам ненужные методы, которые по идее не должны вообще работать, если даты под это нет у класса, а ее не должно быть, иначе разделять не нужно и ISP не подходит
5. Dependency Inversion Principle: Инверсия ради инверсии
> DIP часто превращается в догму "всегда используйте интерфейсы", что приводит к созданию ненужных абстракций
Либо я не понял, либо я не видел, чтобы так происходило. DIP это возможно, один из наиболее важных принципов в SOLID, он чаще всего как раз полезный, чем не полезный: легче тестирование, а уже этого много стоит, меньше классы, легче прийти к адаптерам, легче формируется точки входа в модулях