Статьи

О Боге и ООП

в рубрике Колонка Спанч Боба, Технологии , теги:

godИстория развития языков программирования в чем-то схожа с историей возникновения человеческой речи. Существует мнение, что содержание первых высказываний человека состояли исключительно из требований помощи, которую бы мог оказать ему другой индивид. «Если бы первые высказывания становящегося человека выразить с помощью нашего, развитого языка, они обязательно содержали бы глаголы в повелительном наклонении (“дай!”, “неси!”, “ломай!”, “режь!”, “бей!”, “поднимай!”, “тяни!” и т. п.)». Причем эти команды сопровождались жестами, которые точно указывали к чему конкретно это действие должно быть применено. Ну, очень похоже на команды императивных языков программирования! Например, команды ассемблеров с точным указанием адресов памяти или регистров.

Человек вначале учится отличать одну практическую ситуацию, взятую в целом, от другой ситуации. Выделение отдельных элементов этих ситуаций (предметов, над которыми совершаются действия, действий, которые совершаются над предметами) осуществляется позже – по мере того, как в практической деятельности человек все больше знакомится с окружающими его вещами, познает их свойства и их отношения друг к другу и к самому человеку. Постепенно человек начинает выделять из конкретной ситуации объект действия (в программировании – данные) и само действие (в программировании - функции). Овладение способностью выделять объекты действия было настоящей революцией в умственном развитии первобытного чело века. А это уже не что иное, как всеми нами любимый объектно-ориентированный подход в программировании. По крайней мере, в его современной реализации в языках Java, .NET, C++.

Да, теперь мы уже научились говорить не просто «неси», а «неси дрова» или «неси камень». В своем развитии языки программирования остановились на том, что научились различать объекты (дрова и камень), но не научились выделять действия над ними. И с точки зрения языка программирования men.carry (firewood) и men.carry (stone) будут разными языковыми единицами, если только объекты firewood и stone не имеют общего предка! Просто реализация этими объектами интерфейса «то, что может носить человек» нас не выручит, поскольку это будет две реализации, а, следовательно, и единиц исходного кода тоже будет две.

Здесь и зарыто главное ограничение ООП, которое делает наши программы сложнее, чем они могли бы быть. «Таким образом, когда мы пытаемся определить, подходит ли нам конкретный дизайн (АС: программной системы) или нет, мы не можем рассматривать данное решение изолированно. Мы должны рассматривать его с точки зрения разумных предположений о том, как будет использоваться данный дизайн пользователями». (”The Liskov Substitution Principle”). Если перевести этот тезис на язык «дров» и «камней», то это будет звучать, примерно, так. Проектируя программные объекты «дрова» и «камень», мы должны быть в курсе планов Господа по совершенствованию программной системы. А именно, мы должны предполагать, что Он не ограничится созданием дров и камней, а на шестой день сотворения мира создаст человека, который их будет перетаскивать.

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

VN:R_U [1.9.5_1105]
Rating: 0 (from 0 votes)

Комментариев: 3 на “О Боге и ООП”

  1. >И с точки зрения языка программирования men.carry (firewood) и men.carry (stone) будут
    >разными языковыми единицами, если только объекты firewood и stone не имеют общего
    > предка!

    С точки зрения какого языка? И что в этом языке понимается под объектом?
    В Java все классы являются потомками Object - и что, этот общий предок чем-то помогает в данном случае?

    >Просто реализация этими объектами интерфейса «то, что может носить человек» нас не
    >выручит, поскольку это будет две реализации, а, следовательно, и единиц исходного кода
    >тоже будет две.

    Мир не умер вместе с Object Pascal. Есть, хоть и не везде, множественное наследование. Есть template/generic. Есть масса красивых паттернов для убогих языков.

    >Таким образом, когда мы пытаемся определить, подходит ли нам конкретный дизайн
    >(АС: программной системы) или нет, мы не можем рассматривать данное решение
    > изолированно. Мы должны рассматривать его с точки зрения разумных предположений
    >о том, как будет использоваться данный дизайн пользователями».

    Thus, when considering whether a particular design is appropriate or not, one must
    not simply view the solution in isolation. One must view it in terms of the reasonable
    assumptions that will be made by the users of that design.

    Без комментариев.

    >Если перевести этот тезис на язык «дров» и «камней», то это будет звучать, примерно, так.
    >Проектируя программные объекты «дрова» и «камень», мы должны быть в курсе планов
    >Господа по совершенствованию программной системы. А именно, мы должны предполагать,
    >что Он не ограничится созданием дров и камней, а на шестой день сотворения мира
    >создаст человека, который их будет перетаскивать.

    С дуба падали
    Листья ясеня.
    Удивился я…

    Когда на шестой день по воле Господа фабрики классов начнут производить firewood6 и stone6, которые можно перетаскивать, код, написаный в первый день в рассчете на firewood и stone, которые таскать было некому и незачем, должен продолжать работать. Вот и весь The Liskov Substitution Principle.

    VN:R_U [1.9.5_1105]
    Rating: 0 (from 0 votes)
  2. Добрый день,

    На самом деле принцип, сформулированный Барбарой Лисков, звучит так:

    Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.

    Этот принцип был сформулирован в 1987 году. Сегодня его люьбой девелопер использует много раз на день — это interface + implementation.

    Хотелось бы услышать, может ли автор предложить что-нибудь рабочее взамен “провалившейся” концепции ООП?

    VN:R_U [1.9.5_1105]
    Rating: 0 (from 0 votes)
  3. 2Алексей

    >>Хотелось бы услышать, может ли автор предложить что-нибудь рабочее взамен “провалившейся” концепции ООП?

    Предложить что-нибудь _рабочее_ разумеется не могу :(
    Но могу порассуждать о том, что это такое могло быть. Подробности здесь.

    Об опасности драконов - http://softwarepeople.ru/blog/2010/01/25/arkhipenkov-about-dragons-danger/

    VN:R_U [1.9.5_1105]
    Rating: 0 (from 0 votes)

Прокомментировать

Вы должны быть авторизованы для комментирования.

Партнеры

Microsoft ITONLINE Group ScrimTrek IT Trainings

© Careerlab, ITONLINE GROUP 2012 Команда Software People

+7 (495) 933-01-33

team@softwarepeople.ru