В серии "мифы ооп" уже два треда:
Начинаем третий про наследование и отношения. Во второй части был опрос про отношения, на который правильно ответило только 29 процентов! И кажется что не все поняли первый тред. #oopmyths
Начнем как обычно с опроса. Вопрос: "Объяснять ООП надо через аналогию с реальным миром". Именно так делается в подавляющем большинстве источников и сервисах типа стековерфлоу.
Строго говоря, отношение частное-общее про типы, а не классы. В статье про сабтайпинг об этом написано внизу: en.wikipedia.org/wiki/Subtyping. И принцип лисков тоже не про классы. Наследование классов это всего лишь способ убрать дублирование кода. Один из худших способов.
Почему худших? Несколько моментов. Самое простое – об этом написано на каждом углу. Каждый специалист в ооп, каждая книга говорят одно и тоже. Предпочитайте композицию наследованию. Есть даже вопросы, которые задают на собеседованиях посвященные этой проблеме плавает/летает/ходит
Вторая проблема описывается тут: Circle Ellipse problem en.wikipedia.org/wiki/Circle%E2…
Мне очень хочется разобрать всю эту статью на цитаты и добавить сюда, она проливает свет на многие аспекты и проблемы.
Среди прочего, эта проблема затрагивает классификацию как таковую, не важно речь идет про классы или про типы. Цитата:
> It may also imply that hierarchical taxonomies are difficult to make universal, implying that situational classification systems may be more practical.
Дело в том, что мир не иерархичен. Отношения между вещами всегда зависят от того как мы на них смотрим. Сегодня нам надо разделить машины по предназначению, завтра по вместимости. Как это сделать? И вот для этого используют трейты/миксины, которые намного практичнее и удобнее.
А теперь кое что интересное. В математике есть понятие необходимости и достаточности. Необходимое условие это то, без чего не может выполняться какое-то утверждение. Все это позволяет найти так называемый "базис", минимум необходимый для валидации утверждений. Где тут ооп =>
Про ООП говорят что это "наследование, полиморфизм, инкапсуляция". Теперь вопрос. Может ли называться программа ООП, если в ней не используется наследование?
en.wikipedia.org/wiki/Compositi…
in object-oriented programming (OOP) is the principle that classes should achieve polymorphic behavior and code reuse by their composition rather than inheritance from a base or parent class.
Принцип ООП нарушающий ООП!
То есть получается что наследование классов хоть и ООП фишка, но это некая дополнительная приблуда, которой могло бы и не быть. Более того, на практике композиция + трейты/миксины делают наследование рудиментом.
В принципе не так много людей считало наследование основной фишкой, но все же такое мнение существует.
Кстати немало паттернов как раз описывают разные способ ухода от наследования. Например различные варианты делегирования/проксирования.
Кстати, множественное наследование как раз пыталось решить ту самую проблему классификаций. Но в итоге получилось таким сложным, что большинство языков его не поддерживают намеренно. И снова трейты/миксины победили. На подумать en.wikipedia.org/wiki/Data,_con…
Ну и наконец абстрактные классы, анонимные классы, вложенные классы и еще куча всяких видов классов специфичных для разных языков. Все эти виды классов решают какие-то утилитарные проблемы (модули, реюз кода, дубли), часто даже искусственные (которых не было без классов).
И вот с абстрактными классами вышло неожиданно. В опросе аж 25% человек ответило что это про отношение частное-общее.
При том что в большинстве языков такого понятия нет, но есть и/или интерфейсы, классы и еще куча всяких штук.
Share this Scrolly Tale with your friends.
A Scrolly Tale is a new way to read Twitter threads with a more visually immersive experience.
Discover more beautiful Scrolly Tales like this.