Как стать автором
Обновить

10 принципов объектно-ориентированного программирования, о которых должен знать каждый разработчик

Время на прочтение5 мин
Количество просмотров52K
Всего голосов 57: ↑36 и ↓21+15
Комментарии26

Комментарии 26

Это называется «галопом по Европам»: без вдумчивого погружения в каждый вопрос, проскакали по верхам. Практически с тем же успехом можно было просто написать список из 10ти пунктов, чтобы те, кто не знает пошли гуглить конкретику.
Практически с тем же успехом можно было просто написать список из 10ти пунктов, чтобы те, кто не знает пошли гуглить конкретику.

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

Но композицию, LSP и им подобные да, надо все-таки гуглить… Но как говорили преподаватели у меня в универе — «Университет — это место, где учат находить знания».

Подавляющее большинство этих принципов относятся не конкретно к ООП, а к программированию вообще. В любой парадигме и на любом языке. Слово "класс" при необходимости меняется на слово "функция", "структура", "модуль", "файл исходных текстов" и т.д. в зависимости от особенностей конкретного языка. При отсутствии в языке явных слов private и public вместо них могут работать области видимости, слово "static" в plain C, непрозрачные структуры там же, схемы именования и др.

>Подавляющее большинство этих принципов относятся не конкретно к ООП
Только не в такой формулировке, как их тут подают. Кстати, если бы их сформулировать в несколько более общем виде, убрав ненужное упоминание ООП, они были бы намного проще, и вероятно полезнее.
Жду статью о бинарном поиске и сортировках!
Про сортировки будет очень интересно почитать!
НЛО прилетело и опубликовало эту надпись здесь
Ждём 10 способов реализовать сортировку «Пузырьком»!
НЛО прилетело и опубликовало эту надпись здесь
Liskov substitution описан, как мне кажется, неверно.
Даже если предположить существование некоторого метода
area(Rectangle r)
, работать он должен одинаково как для квадрата так и для прямоугольника. Иерархия квадрат -> прямоугольник нарушает LSP при определении контракта на изменение. (изменение высоты у прямоугольника не влечёт изменение ширины, в отличие от квадрата).
Да, почему-то очень любят использовать связь прямоугольник-квардрат как иллюстрацию наследования, хотя это очень плохой пример и (подумав) такой код никогда в реальной жизни не напишешь. Мало того, что очень сложно выбрать, кто от кого наследуется, так еще и сразу начинают лезть несоответствия вроде того, что описал Frintezza93. Из за этого обычно не рекомендуют наследоваться от реализаций, но только от специально подготовленных астрактных классов или еще лучше реализовывать интерфейсы типа Figure с метдами вроде area() и дргуих.
Квадрат это частный случай прямоугольника. Не каждый прямоугольник является квадратом. Квадрат наследуется от прямоугольника.

Квадрат — это также частный случай ромба. Некоторые ромбы — это прямоугольники, а некоторые прямоугольники — это ромбы. Уверены, что тут вообще наследование применимо?

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

Скорее квадрат — внук параллелограмма и правнук трапеции.

Тогда возможно он должен быть не потомком, а экземпляром прямоугольника?
Пример и правда не лучший — стоило бы убрать сеттеры и передавать параметры в конструктор (Rectangle(int width, int height) и Square(int size), тогда бы было меньше вопросов. Классы не обязаны быть изменяемыми.
НЛО прилетело и опубликовало эту надпись здесь

Ещё пара сотен таких статей, и люди запомнят принципы

Пара сотен таких статей, и люди запомнят вольный пересказ упрощённой интерпретации перевода очередной выжимки о принципах. Мне кажется, это тупик. Давайте уже о сортировках!

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

Надо не путать принципы обьектно-ориентированных программирования и проектирования. Или не разделять их.

когда-нибудь я соберусь с мыслями и пойму это
Обязательно напишите статью как написать программу «Привет Мир!» на 10 разных ЯП. Это очень нужно на Habrahabr!
ООП в целом не очень полезная вещь, без неё можно писать хорошие программы. Вот тут подробнее: www.youtube.com/watch?v=QM1iUe6IofM
Зарегистрируйтесь на Хабре, чтобы оставить комментарий