Принципы SOLID, только понятно

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

1. Single responsibility. В вашем примере нарушается инкапсуляция класса непонятно за какими целями. Вообще вполне нормально может быть, что робот может и move и speak. Вполне возможно, что у него эти методы завязаны на одних и тех же данных внутри класса. Если слепо следовать S, то у класса вылезают кишки наружу, логика переносится в другие классы, плодятся контроллеры, сервисы и прочие странные мутанты. Я уж не говорю про DDD, где класс соответствует термину предметной области - тут прямой конфликт с принципом единственной ответственности.

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

3. LSP. А что, если подставить экземпляр студента вместо персоны, он не будет работать? Пример нарушения - это как раз когда наследуют прямоугольник от квадрата и удивляются, почему при задании одного размера его не видно. Конечно, квадрат - это частный случай прямоугольника.

4. ISP. Интерфейс вообще-то строится для клиентского кода. Соответственно, интерфейс может дробиться только до уровня требований этого кода. Если он требует объект, который должен и говорить и двигаться, то разделять эти интерфейсы не нужно. В вашем примере вы рассматриваете неправильную проектировку самого класса, а не интерфейсов. Ну на этапе создания Robot уже должно дойти, что он не умеет летать, верно?

5. Интерфейс ради интерфейса? Вот зачем? Внедрять лишнюю сущность, когда нет ещё уверенности, что будет другая база данных - это раздувание кода ради культа карго.

С годами начал испытывать отвращение к красивым акронимам. В большинстве случаев "красота" акронима ущемляет смысловое наполнение. В частности какой нахрен "Liskov Substitution Principle", вы ваще о чем? Надо было что-то ткнуть на "L"?

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

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

Для OCP пример плохой. OCP это возможность расширять или изменять поведение класса "внешним" для него кодом, не добавляя этот код в него и не модифицируя его существующий код.

Говнокод плохой код:

public abstract class Character
{
    protected Character() {}

    public abstract void SayHello();
}

public class Wizard: Character
{
    public override void SayHello() => Console.WriteLine("Hello, I'm the Wizard!");
}

public class Knight: Character
{
    public override void SayHello() => Console.WriteLine("F*** you, I'm the Knight!");
}

Хороший код:

public abstract class Character
{
    protected Character() {}

    public abstract void SayHello(TextWriter output);
}

public sealed class Wizard: Character
{
    public override void SayHello(TextWriter output) => output.WriteLine("Hello, I'm the Wizard!");
}

public sealed class Knight: Character
{
    public override void SayHello(TextWriter output) => output.WriteLine("F*** you, I'm the Knight!");
}

Single Responsibility Principle

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

Еще чтобы было проще прочитать и понять. Переключение контекста проблемы в мозгу очень затратная операция. А еще задачи можно разделит между разными программистами.

Open Closed Principle 

Опять же смотри полиморфизм

Принцип подстановки Барбары Лисков

почти что = определение подтипов

Полиморфизм подтипов для этого и вводят. Как тут подсказывают, LSP = полиморфизм типов + правило что подтип не должен "усиливать предусловия"

Но есть и другие виды полиморфизма, не менн полезные:

Interface Segregation Principle

это практически определение интерфейса: чтобы уменьшить зависимость между классами выдели зависимость в интерфейс. YAGNI в чистом виде

Dependency Inversion Principle

Тут все сложно. И то что определение не поместилось в одном предложении намекает на это. Для борьбы с зависимостями можно использовать абстракции. Но есть еще следующие методы:

• DI (зависимости внедрены внешним кодом и класс их помнит всю свою жизнь при инжекции в конструктор или только в контексте вызова при инжекции в метод)

• IoC (зависимости знает внешний код, а класс их вообще не знает)

• Factory method (для управления зависимостями создается специальный класс, который больше ничего не умеет)

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

Но и это еще не все про DIP

Пресловутую проблему "You wanted a banana but what you got was a gorilla holding the banana and the entire jungle" можно обойти тем что банану не нужно знать кто его владелец. Т.е. если код следует предметной области, то DIP не нужен.

Вотъ(С)

Неверная трактовка:

Single Responsibility Principle

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

Верная трактовка:

The single-responsibility principle (SRP) is a computer programming principle that states that "A module should be responsible to one, and only one, actor."

Я когда-то пытался сформулировать эти принципы своими словами, может быть, кому-то это покажется полезным:

SRP

Single-responsibility principle, принцип единственной ответственности. Предполагает проектирование классов, имеющих только одну причину для изменения, позволяет вести проектирование в направлении, противоположном созданию «Божественных объектов». Класс должен отвечать за удовлетворение запросов только одной группы лиц.

OCP

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

LSP

Liskov substitution principle, принцип подстановки Барбары Лисков: поведение наследующих классов должно быть ожидаемым для кода, использующего переменную базового класса. Или, другими словами, подкласс не должен требовать от вызывающего кода больше, чем базовый класс, и не должен предоставлять вызывающему коду меньше, чем базовый класс.

ISP

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

DIP

Dependency inversion principle, принцип инверсии зависимостей. Модули верхнего уровня не должны обращаться к модулям нижнего уровня напрямую, между ними должна быть «прокладка» из абстракций (т. е. интерфейсов). Причем абстракции не должны зависеть от реализаций, реализации должны зависеть от абстракций.

Сам Роберт Мартин считал SRP самым трудным для понимания и уточнял, что в первую очередь под "единой ответственностью" имеется в виду ответственность группы лиц, т. е. класс не должен закрывать потребности, например, бухгалтерии и транспортного отдела.

Я очень люблю задавать вопрос про SOLID на собеседованиях, не потому что жду четкого и верного ответа, а потому что мне интересно как человек понимает принципы. Даже по комментариям здесь видно что сколько людей - столько трактовок и мнений :) А из трактовки и понимания уже легко понять опыт человека, и проблемы, с которыми он сталкивался.

Если вам кажется, что вы понимаете принципы SOLID, значит вы не понимаете принципы SOLID.

Блин, на самом деле в первом примере проще было бы тогда сделать класс с каким нибудь более абстрактным названием NCP (например) и в конструкторе прокинуть нужный указатель на Move и Speaker чем в каждом классе писать руками делегирующий вызов.

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

Причем тут ЯП вообще? Это как сказать, принципы аэродинамики справедливы для автомобилей любой марки. ЯП вообще может быть функциональным, а принципы, они для ООП.

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

Я могу на собесе красиво рассказать про SRP и ISP. Но в жизни это для меня одно и тоже. Интерфейс, это то что определяет ответственность класса, если он не достаточно сегрегейтед, то фиг вам, а не сингл респонсибилити класса. (Под интерфейсом я воспринимаю, то что можно сделать с классом, а не специальный объект язака, как в java).