Принципы SOLID: извлечение кода в суперклассе

В моем приложении есть N дочерних классов, расширяющих суперкласс. Каждый класс имеет свою собственную реализацию serialize, но у них есть общий код. Например:

class Serializer {
   serialize = () => throw Exception("...")
}

class JSONSerializer extends Serializer {
   serialize = () => {
      console.info("Formatting...")
      // ...
   }
}

class XMLSerializer extends Serializer {
   serialize = () => {
      console.info("Formatting...")
      // ...
   }
}

Нарушаю ли я принципы SOLID (в частности, наследование интерфейса вместо наследования реализации - подстановка Лискова-), если я обертываю общий код внутри суперкласса в функцию format и вызываю его внутри дочерних классов? Если да, то как мне придерживаться этого принципа?

class Serializer {
   format = () => console.info("Formatting...")
   serialize = () => throw Exception("...")
}

class JSONSerializer extends Serializer {
   serialize = () => {
     this.format()
     // ...
   }
}

class XMLSerializer extends Serializer {
   serialize = () => {
     this.format()
     // ...
   }
}
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Улучшение производительности загрузки с помощью Google Tag Manager и атрибута Defer
Улучшение производительности загрузки с помощью Google Tag Manager и атрибута Defer
В настоящее время производительность загрузки веб-сайта имеет решающее значение не только для удобства пользователей, но и для ранжирования в...
Безумие обратных вызовов в javascript [JS]
Безумие обратных вызовов в javascript [JS]
Здравствуйте! Юный падаван 🚀. Присоединяйся ко мне, чтобы разобраться в одной из самых запутанных концепций, когда вы начинаете изучать мир...
Система управления парковками с использованием HTML, CSS и JavaScript
Система управления парковками с использованием HTML, CSS и JavaScript
Веб-сайт по управлению парковками был создан с использованием HTML, CSS и JavaScript. Это простой сайт, ничего вычурного. Основная цель -...
JavaScript Вопросы с множественным выбором и ответы
JavaScript Вопросы с множественным выбором и ответы
Если вы ищете платформу, которая предоставляет вам бесплатный тест JavaScript MCQ (Multiple Choice Questions With Answers) для оценки ваших знаний,...
0
0
61
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Ваши изменения в коде не нарушают принципы SOLID. Извлечение общего кода в суперкласс и вызов его внутри дочерних классов соответствует принципам.

Вот почему:

Принцип единой ответственности (SRP): Каждый класс имеет одну ответственность. Сериализатор отвечает за форматирование, а JSONSerializer и XMLSerializer отвечают за создание своих определенные типы сериализации.

Принцип открытости-закрытости (OCP). Класс сериализатора открыт для расширение, но закрыто для модификации. Вы можете добавлять новые классы, которые наследуется от сериализатора, но вы не изменяете класс сериализатора каждый раз, когда вам нужен новый тип сериализатора.

Принцип замены Лискова (LSP): дочерние классы могут использоваться в место родительских классов, не вызывая проблем. Вы не нарушаете это потому, что функция сериализации в дочерних классах не выполняет все, что могло бы нарушить функцию, как она определена в Класс сериализатора.

Принцип разделения интерфейсов (ISP): клиенты не должны быть принуждены зависят от интерфейсов, которые они не используют. Мы не видим никакого интерфейса зависимости здесь, поэтому этот принцип не нарушается.

Принцип инверсии зависимостей (DIP). Модули высокого уровня не должны зависят от низкоуровневых модулей. Оба должны зависеть от абстракций. метод сериализации высокого уровня в сериализаторе не зависит от Подробности метода низкоуровневого форматирования.

Кроме того, хорошо применяется принцип «сухого» («не повторяйся»), перемещая общий формат кода в сериализатор родительского класса, тем самым повышая удобство сопровождения кода и уменьшая потенциальные ошибки.

Однако следует предостеречь: создание исключений непосредственно из суперкласса может быть не идеальной практикой, вместо этого вы можете структурировать его так, чтобы он возвращал нереализованное сообщение или обрабатывал его каким-либо другим способом.

Интерфейс против наследования реализации

Наследование интерфейса (также известное как подтипирование) — это когда класс предоставляет реализацию методов интерфейса. Этот тип наследования представляет собой просто «контракт», который гарантирует, что класс придерживается определенной структуры. В этом случае класс соглашается реализовать ряд методов с определенными типами ввода и вывода.

С другой стороны, наследование реализации (или создание подклассов) — это когда класс наследует поведение (методы) и состояние (свойства) от другого класса, который мы называем суперклассом или родительским классом. Идея заключается в создании более конкретных классов на основе общего класса.

Ваш пример больше касается наследования реализации, поскольку вы создаете подклассы JSONSerializer и XMLSerializer, которые переносят метод формата из родительского Serializer класса.

Теперь, с точки зрения принципов SOLID, обычно рекомендуется отдавать предпочтение композиции наследованию и полагаться на интерфейсы (наследование интерфейсов). Этот принцип известен как принцип инверсии зависимостей, буква «D» в SOLID. Этот принцип говорит нам, что модули высокого уровня не должны напрямую зависеть от модулей низкого уровня, а должны зависеть от абстракций (обычно интерфейсов). Но каждый случай имеет свой собственный контекст и потребности, поэтому могут быть ситуации, когда наследование реализации более применимо.

Чтобы применить composition в вашем случае, вы можете:

1. Извлечение общего метода format() в отдельный класс Formatter:

class Formatter {
    format = () => console.info("Formatting...")
}

2. Вместо расширения Serializer наши классы JSONSerializer и XMLSerializer будут включать экземпляр Formatter для обработки форматирования:

class JSONSerializer {
    constructor(){
       this.formatter = new Formatter(); 
    }

    serialize = () => {
        this.formatter.format();
        // ... JSON specific serialization
    }
}

class XMLSerializer {
    constructor(){
       this.formatter = new Formatter(); 
    }

    serialize = () => {
        this.formatter.format();
        // ... XML specific serialization
    }
}

Или, если вы предпочитаете внедрение зависимостей:

class Formatter {
    format = () => console.info("Formatting...")
}

class JSONSerializer {
    constructor(formatter){
       this.formatter = formatter;
    }

    serialize = () => {
        this.formatter.format();
        // ... JSON specific serialization
    }
}

class XMLSerializer {
    constructor(formatter){
       this.formatter = formatter; 
    }

    serialize = () => {
        this.formatter.format();
        // ... XML specific serialization
    }
}

const formatter = new Formatter();
const jsonSerializer = new JSONSerializer(formatter);
const xmlSerializer = new XMLSerializer(formatter);

Другие вопросы по теме