Автор Тема: Кое-что о сущности ООП  (Прочитано 23290 раз)

Valery Solovey

  • Hero Member
  • *****
  • Сообщений: 509
    • Просмотр профиля
Кое-что о сущности ООП
« : Декабрь 12, 2016, 11:10:29 pm »
ООП, как и множество других мощных концепций в своей гениальной простоте возник не из ниоткуда, а образовался путём связи уже существовавших и использовавшихся в программировании вещей. И эти вещи были образованы не просто раньше ООП, но и в программирование с компьютерами уже попали после опробования на разных дисциплинах в течение тысяч лет.

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

У многих задач, с которыми сталкивается программист, есть несколько решений. А также, на программиста влияют физиологические, культурные и биографические (эффект утёнка) причины. И в итоге, программист отдаёт предпочтение одной из вещей, составляющих фундамент ООП, и рассматривает сам ООП через призму полюбившегося ему кирпичика. Я считаю, что именно эта деталь до сих пор заставляет обсуждать или даже спорить по поводу ООП.

Но опять же, я хотел рассмотреть не эти детали, а целиком ООП. При грубом рассмотрении в ООП можно выделить две сущности: объект и класс. Междну ними существует отношение первичности. А ещё существует две школы, одна из которых рассматривает в качестве первичной сущности класс, а вторая - объект. Представителем первой школы является Симула, а второй - Смолтолк. Ну, и многие другие ООП-языки тоже принадлежат одной из этих школ.

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

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

Если первичен объект, то программист создаёт в своей системе множество объектов, затем выбирает набор признаков, и все объекты системы, обладающие данным набором, автоматически считаются принадлежащими данному классу. По сути, в этом случае класс - это идиома, и количество классов, которым принадлежит объект, ограничивается лишь фантазией программиста. Кстати, насколько я помню, именно так строятся классификации в, скажем, зоологии. Так что можно сказать, что эта школа ООП более естественная, что ли...

У каждой из школ есть свои плюсы и минусы. Например, если первичен класс, то на этапе компиляции олавливается множество ошибок, которые в другой школе придётся искать на этапе исполнения. Но зато приходится мириться с не такой уж и редкой проблемой хрупкого базового класса. Если первичен объект, то не нужны никакие приведения типов. Но зато клиент объекта может послать ему любое сообщение. А это значит, что можно наплевать на архитектуру, и слать сообщения, которые предназначены для другого уровня или вообще сокрыты (например, получение пароля к учётной записи). Если первичен класс, то объект принадлежит заранее подготовленной иерархии классов, которая может быть довольно сложной (и в поддерже в том числе). Но тогда использование объекта определяется только этой иерархией. А в школе, где первичен объект использование объекта определяется не только принадлежностью к какому-либо классу, но и мыслям программиста. То есть, мало того, чтобы объект принадлежал классу А, ещё и программист должен думать, что он принадлежит классу А.

Также, есть качественная разница в реализации. Думаю, школа с первичным объектом при прочих равных проиграет в производительности школе с первичным классом.