SRP Потому что условные операторы вообще нарушают SRP, потому что, как оператор switch case или несколько операторов if-else, считаются более чем одной обязанностью. Существует два случая, поэтому есть несколько причин для изменения метода.

Я категорически не согласен. SRP следует интерпретировать с долей скептицизма. Прочтите статью об этом дяди Боба - он придумал этот принцип.

Процитирую важные моменты:

Что определяет причину изменений?

Это принцип о людях.

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

[...] размышляя об этом принципе, помните, что причины перемен - это люди. Это люди, которые требуют изменений. И вы не хотите сбивать с толку этих людей или себя, смешивая воедино код, который волнует множество разных людей по разным причинам.

OCP Потому что, если добавляется новое животное, к методу должен быть добавлен новый случай, чтобы метод не был близок к модификациям.

Верный. Этот метод предполагает определенный набор реализаций и не сможет обрабатывать новые без изменения.

LSP Каждая ветвь выполняет разные действия в зависимости от подтипа животных. Что, как мне кажется, нарушает LSP ?!

Это нарушает LSP, но по другой причине. Если бы я передал жирафа, я бы получил неожиданный результат - пустую строку. Это означает, что метод не подходит ни для одного подтипа Animal.

DIP. Условные операторы принимают зависимость, что означает, что операторы зависят от деталей, а не от абстракций, которые нарушают DIP.

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

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

Я не согласен с тем, что ваш примерный код нарушает LSP. LSP определяется следующим образом:

Пусть Φ (x) - свойство, доказуемое для объектов x типа T. Тогда Φ (y) должно быть истинным для объектов y типа S, где S - подтип T.

Учитывая два производных от Animal, а именно Dog и Cat и ваш метод getAnimalNoise, вы не принимаете решений относительно некоторого доказуемого свойства конкретного объекта. Ваш метод решает, какой шум должен быть возвращен, а не сами объекты.

Итак, давайте представим, что вы можете установить количество ног для животного.

Animal a = new Animal()
a.setLegFront(2);
a.setLegRear(2);

И если ваш Dog перезапишет это так:

 class Dog extends Animal
 {
   public void setFrontLegs(int legs)
   {
     this.frontLegs = legs;
     this.rearLegs = legs + 2; 
   }
   public void setRearLegs(int legs)
   {
     // do nothing here for demonstration purposes
   }
 }

Если теперь у вас есть завод, возвращающий Animal

Animal createAnimal()
{
   return new Dog();
}
Animal a = createAnimal();
a.setFrontLegs(2);
a.setRearLegs(2);

И вы вызываете методы setFront/setRearLegs, вы ожидаете, что результаты будут 2 и 2, но на самом деле результат совершенно другой, а именно 2 и 4. Таким образом, этот пример тесно связан с обычным примером LSP с квадратами и прямоугольниками. Но для меня это более точный пример нарушения доказываемых свойств, чем в вашем примере.

Обновление для других принципов

Я согласен с вами, что другие принципы также нарушаются, но в отношении SRP я согласен с @dcastro.