Пятая буква D в SOLID

Ну и этот принцип, называемый Dependency Inversion приказывает нам зависеть от абстракции, а не от конкретной реализации. Обратимся снова к первой букве, и посмотрим на класс InstagramParser. В конструкторе класса легко видеть, что там нет требования к конкретным реализациям, есть только требование абстракции, то есть реализации данного интерфейса.

Поэтому на вход может подойди любой класс который реализует интерфейс, как например в первом аргументе конструктора InstagramParser с типом IResource.

Как нарушить данный принцип? Укажем в конструкторе InstagramParser конкретную реализацию, например наследника InstagramResource класс ByHastagResource. Вот и все, зависимость получится очень жесткой, как бы опять прибили гвоздями.

Loading

Четвертая буква I из SOLID

Принцип разделения интерфейса.
Вспоминая о зонах ответственности каждого отдельного класса, где стараешься соблюдать принцип решения только одной задачи возложенной на класс. Этот принцип называемый —
Принцип разделения интерфейса обозначает тоже самое.

То есть, допустим, если опять же рассматривать
первую букву из SOLID то мы увидим что мы не создали интерфейс который заставил бы класс,  реализовать как getResource() так и метод handle(). А конкретно разбили зоны ответственности + к нему интерфейс, получилось — ничего лишнего.

Получение ресурса и что с ним делать никак не связаны, так и не должно быть никаких причин, заставлять класс реализовывать эти две несвязные вещи через объявленный интерфейс.

Много где можно заметить нарушение этого принципа, где вместо реализации метода интерфейса остаются заглушки, метод с пустым телом либо возвращающий null, false, true чисто для заглушки. Вот это и есть немного плохой пример. Но рефакторинг никто не отменял

Loading

Третья буква L из SOLID

Самый непонятный принцип на первый взгляд. О чем он говорит?

  1. Предварительные условия не могут быть усилены в подтипе.
  2. Постусловия не могут быть ослаблены в подтипе.
  3. Инварианты супертипа могут быть сохранены в подтипе.

С ума можно сойти, о чем тут речь?
Читать далее Третья буква L из SOLID

Loading

Вторая буква O из SOLID

тПринцип открытости/закрытости.
Что нам говорит вырезка из «википедии»

Программные сущности должны быть открыты для расширения, но закрыты для модификации.

По примеру из Первая буква S из SOLID
Мы уже там можем видеть этот принцип, программная сущность как агрегат (класс InstagramParser ) Является открытым для расширения. Но закрыт для модификации

Но не без примера!
Спижю с хабры, отлично объясняет этот принцип

Читать далее Вторая буква O из SOLID

Loading

Первая буква S из SOLID

Single Responsibility Principle — таким образом расшифровывается первая буква из аббревиатуры SOLID.

Как бы это банально не звучало, но в этом принципе, говориться только о том, чтобы ваш класс, отвечал только одной задаче, в этом классе, могут быть несколько методов, но служить они должны только для решения той задачи, которая возложена на данный класс.

Пример нарушения этого принципа.
Например мы парсим результаты ответа с социальной сети инстаграм, по определенному хештегу, у нас есть класс.
P.S.: приведен псевдокод, применять его в реальной жизни не стоит

Например наш класс имеет такой вид

Читать далее Первая буква S из SOLID

Loading