Что такое нарушения принципов ООП?

Question

[raiboon]

Попалась довольно старая статья от зептолаб с разбором их конкурса. Там они очень ругали за "Грубые ошибки в коде. Они чаще всего связаны с нарушением принципов ООП".
Что под этим может пониматься?
Пытался нагуглить статьи в тему. Но "базовых принципов" и солида на первых страницах нет

Answer 1

[Александр Макаров]

Скорее всего имеются ввиду инкапсуляция, наследование и полиморфизм. Они самые базовые.

Comments

[God Emperor]

Ещё порой выделяют "композиция"

[raiboon]

Они настолько базовые, что я не представляю, что надо написать, что бы это могло считаться "ошибкой".

[Александр Макаров]

Да ладно, ошибки на тему полиморфизма сплошь и рядом.

[God Emperor]

Александр Макаров: на инкапсуляцию чаще, как мне кажется

[Freeman]

Александр Макаров: @God-emperor: Ошибки на тему полиморфизма -- это старый добрый copy-paste. Вместе с ними и инкапсуляция страдает, отож.

Answer 2

[Тимофей]

3 заветных слова: наследование, инкапсуляция, полиморфизм. По ним можно много нагуглить.
Элементарный пример нарушения принципа инкапсуляции - объявление public поля класса. Нужно все поля делать private, а доступ к ним организовывать через методы доступа типа get..., set... или как-то более прозрачно, если позволяет язык (__get, __set в php, свойства в C#). По наследованию и полиморфизму накосячить уже сложнее, так как этого не позволит синтаксис скорее всего. Хотя кто знает, какие у человека есть скрытые возможности...

Comments

[bogolt]

Очень распространенное заблуждение что если обернуть все поля класса в методы get/set то у нас сразу же все будет красиво и инкапсулировано. Фигня это.
Вот например делаю я класс для работы с файлом:

class File{
public:
void set_ptr(FILE* p);
FILE* get_ptr();
private:
FILE* ptr = nullptr;
};

Инкапсуляция? Вроде да, ведь есть get/set но самом деле это типичная дырявая абстракция которая ничего не инкапсулирует.
Уж скорее инкапсуляцией можно назвать скрытие реализации за интерфейсом. Причем такое скрытие которое не позволит внутренней кухне реализации выскользнуть за границы интерфейса.

[Тимофей]

bogolt: так мой ответ нисколько этому не противоречит. Я показал самый очевидный вариант ошибки. Естественно, за методами доступа должна стоять какая-то логика проверок, преобразований и т.п., иначе это не имеет смысла. А такая логика хотя бы на минимальном уровне должна присутствовать в подавляющем большинстве случаев. В остальных же случаях я бы все равно сделал так же просто для того, чтобы сделать все однородным, так что даже твой вариант кода может быть применим.
А интерфейс - это вариант полиморфизма, и внутренняя кухня тут значения никакого не имеет, поскольку код, который использует объект класса, реализующего интерфейс, не может иметь представления о том, что в объекте есть помимо собствтенно реализованного интерфейса.

Answer 3

[Mercury13]

Нарушение инкапсуляции. Наружу (т.е. public) торчат какие-то данные, которые можно изменить, и объект уходит в противоречивое состояние.

Инверсия абстракции. Простые вещи, которые, вероятно, понадобятся потомкам, недоступны даже через protected.

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

Класс вместо интерфейса. Если можно, родителя делайте классом без данных с двумя видами функций: public virtual = 0, и protected/public не-virtual (т.н. интерфейс с утилитами). Наследоваться от нескольких классов с данными очень некузяво (а во многих языках вообще невозможно).

Всемогущий родитель. Слишком много функциональности придумали родительскому классу.

В общем, покажите интерфейсы (protected/public, без точных реализаций) ваших классов, и погоняем, что там неверного.

Answer 4

[mamkaololosha]

Gang of Four, SOLID и прочие фабрики-синглтоны-обзерверы. Видимо зептолабам не понравилось, как авторы их намешали в коде.

Answer 5

[raiboon]

Все обрывки фраз понабросали...
В общем, пока что увидел:

• Использование copy-paste вместо наследования-полиморфизма
  
• Неиспользование инкапсуляции - отсутсвие геттеров-сеттеров, игнорирование модификаторов доступа к свойствам
  
• Применение паттернов не к месту
  

Я правильно вас понял, господа? Есть что еще добавить?

Answer 6

[Don Kaban]

https://ru.wikipedia.org/wiki/SOLID_(объектно-ориентированное_программирование)

Answer 7

[Михаил Потанин]

Основное нарушение в чужем коде, которое очень мешало мне мешало когда я программировал на ОО-языках - игнорирование принципа подстановки Лисков.
То есть код, корректно работающий с объектом базового класса, должен так же корректно работать с отъуктом класса-наследника.
Пример нарушения - SSL-сокет в библиотеке Qt унаследован от простого сокета, но для корректного завершения соединения требует других плясок с бубном.