13 октября 2016 в 10:21

«Мир есть совокупность фактов, а не вещей»: Витгенштейн и операционно-ориентированное программирование из песочницы

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

Здесь и далее я буду рассматривать общекнижный пример с сотрудниками предприятия, писать будем на чем-то СИ-подобном. Наследовать класс Сотрудник (Employee) от класса Человек (Person) – прекрасная идея, особенно если хранить данные исключительно в памяти: SQL имеет некоторые проблемы с наследованием таблиц, но речь не об этом — ООП со своим иерархизмом, агрегациями, композициями и наследованиями предлагает идеальный способ организации данных. Проблемы с методами.

За каждым методом бизнес-логики стоит факт мира, который этот метод (чаще не в одиночку) моделирует. Факты программирования – это операции: дальше будем называть их так. Делая метод членом класса, ООП требует от нас привязать операцию к объекту, что невозможно, потому что операция – это взаимодействие объектов (двух и более), кроме случая унарной операции, чистой рефлексии. Метод ВыдатьЗарплату (PaySalary) может быть отнесен к классам Сотрудник (Employee), Касса (Cash), БанковскийСчет (Account) – все они равнозначны в праве владения им. Дилемма о расположении методов сопутствует всему процессу разработки: неловкое ее разрешение может оказаться критичным и даже фатальным.

В книгах по программированию честные авторы стыдливо признают, что «объекты – это как бы не совсем объекты», а ООП – всего лишь способ организации кода, а не механизм моделирования. Но все дело том, что «мир есть совокупность фактов, а не вещей» – отсюда принципиальная неспособность построить адекватную модель, применяя ООП в том виде, как этого требуют писатели учебников. Важно понять: в коде возможно моделировать мир, но атомами модели должны стать факты, а не объекты.

Оказавшись два года назад в мире разработки ПО, я с ужасом осознал, что тут до сих пор царит Аристотель: ООП – прямое порождение его философии. Этот одиозный мыслитель придумал флогистон для химиков, движущую силу для физиков – да что там говорить! — приложился к каждой из крупных дисциплин. История европейского прогресса – это история преодоления Аристотеля. Науке он принес больше зла, чем вся Святая инквизиция. Две тысячи лет потребовалось нашим ученым, чтобы затереть следы его «Физики». ООП – последнее пристанище его мрачной тени. Встречаясь с ним здесь — в ядре самых передовых технологий — хочется взять античный стилус стимулус (так в Риме называли палку погонщика скота) и загнать злобного грека обратно в его каменные склеп, как это давно уже сделали все остальные.

Людвиг Витгенштейн (его афоризм вынесен в заголовок) интересен тем, что, будучи доктором философии, не прочитал и двух страниц из Аристотеля: это его – Витгенштейна — слова. Неудивительно, что неопозитивизм – единственная «работающая» философская система, по сути – единственная на сегодня корректная философия: в подтверждение могу упомянуть, например, неопозитивиста Карла Поппера, который разработал современную методологию научного познания.

Функциональное программирование стало интуитивной реакцией миллионов разработчиков на туманность ООП – его полным отрицанием. Сам я не вижу причины в том, чтобы вовсе отказываться от иерархических принципов: в них много удобного. Известные языки не предлагают готовых средств для строительства иерархии операций, и мне сейчас сложно представить, как должен выглядеть ее синтаксис и звучать ключевые слова. Перенести фокус с объекта на операцию можно и наличными средствами: любой известный ООП-язык с этим справится.

Для начала разделим бизнес-логику на два пространства: данные и операции. Пространство данных не представляет собой ничего особенного – это классы данных, построенные в обычную иерархию – живущие только в оперативной памяти (POJO) или с возможностью сохранения состояния (сущности .NET, модели YII). Классы данных могут располагать собственными методами, как того требует фреймворк: принципиально лишь, чтобы эти методы не имели отношения к бизнес-логике.

Public Class Account {
	Public string accountBankName;
	Public string accountMfo;
	Public string accountNumber;
}

Public Class Company {
	Public string companyTitle;
	Public string companyPhone;
	Public Account companyAccount;
}

Public Class Department {
	Public string departmentTitle;
	Public Company departmentCompany;
}

Public Class Person {
	Public string personName;
	Public date personBirthDate;
}

Public Class Employee inherits Person {
	Public Department employeeDepartment;
	Public double employeeSalary;
	Public Account employeeAccount;
}

Есть компания (Company) с несколькими подразделениями (Department) и сотрудниками (Employee), унаследованными от класса людей (Person). У компании есть счет (Account), с которого сотрудникам перечисляется зарплата. Соответственно, счет (Account) для получения зарплаты есть и у каждого сотрудника. Предположим, что наша программа должна уметь:

— принимать сотрудника на работу;
— выплачивать сотруднику зарплату;
— увольнять сотрудника с выплатой выходного пособия;

Прием на работу и увольнение сотрудника можно назвать кадровыми (Staff) операциями, а выплату выходного пособия и зарплаты – бухгалтерскими (Accounting) операциями.

Для каждой из операций понадобится:

— инициализировать данные о компании;
— инициализировать данные о сотруднике;
— распечатать некий документ.

Для приема / увольнения сотрудника нам придется:

— инициализировать данные о соответствующем подразделении фирмы;

Для двух указанных бухгалтерских операций нам также понадобится:

— инициализировать данные о банковских счетах сотрудника и компании.

Переходим к главному – собственно пространству операций. Мы реализуем его как иерархию классов, каждый из которых представляет собой нечто, что мы назовем «контекст операций» (Operation Context). Публичными методами (API) этих классов будут операции бизнес-логики, а свойства и приватные методы помогут в формировании абстракций. В соответствии с принятым ранее разделением, в нашей программе появятся классы StaffOperationContext и AccountingOperationContext, унаследованные от базового BaseOperationContext. Уложить вспомогательные члены в иерархию операций окажется проще, чем в иерархию объектов.

Public Class BaseOperationContext {
// конструкторы
	BaseOperationContext () {
		InitCompanyData();
	}
	BaseOperationContext (Employee employee) {
		InitEmployeeData(Employee employee);
		InitCompanyData();
	}
// приватные и защищенные методы
	private void InitCompanyData();
	private void InitEmployeeData(Employee employee);
	protected void PrintDocument(Document doc);
}

Public Class AccountingOperationContext inherits BaseOperationContext {
// конструкторы
	AccountingOperationContext ()  {
		super();
	}
// приватные и защищенные методы
	Private InitAccountData(Account account);
	Private BankTransfer(Account account, Double amount);
// публичные методы – API класса
	Public void PaySalary (Employee employee)  // выплата з/п
	{ 
// … некоторый кусок логики
		InitAccountData (employee.employeeAccount);
// … некоторый кусок логики
		BankTransfer (employee. employeeAccount, salaryAmount);
// … некоторый кусок логики
		PrintDocument (someSalaryPayDocument);
	}
	Public void PayRedundancy (Employee employee) // выплата выходного пособия
	{
// … некоторый кусок логики
		InitAccountData (employee. employeeAccount);
// … некоторый кусок логики
		BankTransfer (employee. employeeAccount, redundancyAmount);
// … некоторый кусок логики
		PrintDocument (someRedundancyPayDocument);
	}
}

Public Class StaffOperationContext inherits BaseOperationContext {
// конструкторы
	StaffOperationContext (Employee employee)  {
		super(employee);
	}
// приватные и защищенные методы
	Private InitDepartmentData(Department department);
// публичные методы – API класса
	Public void RecruitEmployee (Person person, Department department)  // прием сотрудника 
	{
		InitDepartmentData(department);
		Employee employee = person;
// … некоторый кусок логики
		PrintDocument (someRecruiteDocument);
	}
	Public void FireEmployee (Employee employee, Department department)  // увольнение
	{
		InitDepartmentData(department);
// … некоторый кусок логики
// инициализируем AccountingOperationContext для платы выходного пособия
		AccountingOperationContext accountingOC = new AccountingOperationContext ();
		accountingOC.PayRedundancy (employee);
// .. некоторый кусок логики
		PrintDocument (someFireDocument);
	}
}

Этим кодом мы ломаем принципы ООП: наш метод FireEmployee относится к своему классу StaffOperationContext как «является», а не «содержится»: то есть увольнение сотрудника становится частным случаем кадровой операции (наследником), а не ее элементом (членом). Компенсацией будет обретение здравого смысла. Некорректное высказывание «увольнение сотрудника является членом объекта 'сотрудник'» мы заменяем на корректное «увольнение сотрудника является кадровой операцией». Корректность высказываний дает надежду на построение корректной модели.

Проблема детерминации (какой метод куда положить) не кажется разрешенной по умолчанию, но она разрешима. В своем единственном разработанном «по Витгенштейну» приложении я опирался на интерфейс. Имея на фронт-энде около десяти экранов, я разбил логику на десять контекстов операций с базовым контекстом наверху иерархии.

Можно по-разному классифицировать операции, важен сам принцип: объектно-ориентированное программирование мы заменяем на операционно-ориентированное. Еще раз повторюсь: речь идет исключительно о бизнес-логике – мире программы. Использовать классы среды и порождать их наследников ничто не мешает.

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

Описанным способом я реализовал бизнес-логику в своем последнем на сегодняшний день проекте. В результате полного рефакторинга (проект достался мне по наследству) код сократился на 70% и стал невероятно дружественным в отношении любых — даже весьма значительных — правок. Опыт вышел удачным: предлагаю попробовать.
@mnikolaev83
карма
5,0
рейтинг 0,0
Самое читаемое Разработка

Комментарии (61)

  • +9
    Вы изобрели паттерн проектирования Mediator («диспетчер»). И, подозреваю, очень скоро додумаетесь до Event Sourcing. (Только не стоит переоценивать философскую глубину этих паттернов, они вовсе не переиначивают ООП, операция вполне себе может быть объектом.)
    • +3
      Мне кажется, это больше на паттерн Command похоже — задается некий контекст исполнения и собственно команда execute().

      Если пофантазировать на тему развития модели классов для приведенного примера, то, операции не осуществляются же сами по себе. Их выполняют вполне конкретные агенты. ИМХО, можно было бы ввести сущности HRDepartment (кадровый отдел) и AccountingDepartment (бухгалтерия) — и вот у них могли бы быть методы fireEmployee() и payRedundancy().
      • +1
        Event Sourcing (с командами и CQRS) я предположил как дальнейшее развитие диспетчера из статьи. Пока там «контекстом» названа сама кадровая бизнес-логика. Но мог и что-то недопонять.
  • 0
    Некорректное высказывание «увольнение сотрудника является членом объекта 'сотрудник'» мы заменяем на корректное «увольнение сотрудника является кадровой операцией».

    А почему для примера используется недоделанная ООП иерархия?
    Где классы «Сотрудники»? «Департаменты»?
    • 0

      трудовойДоговор.расторгнуть() :)

      • +3
        Ну да, или, если не чинить, структуру, то:
        Сотрудник.Уволиться()
        Организация.Уволить(Сотрудник)

        Собственно, почти все критики чего-либо, как правило, чего-либо сначала ухудшают.
        • +3

          Мне кажется, судя по количеству дублирования в коде, непонятным идентификаторам и выбору Delphi в качестве языка для рассуждений об ООП автор не очень подкован в предмете своих рассуждений. И в предметной области, которую выбрал для примера.

  • 0
    Метод ВыдатьЗарплату (PaySalary) может быть отнесен к классам Сотрудник (Employee), Касса (Cash), БанковскийСчет (Account) – все они равнозначны в праве владения им

    Мне кажется зарплата термин специфичный именно для отношений между людьми и предприятием, а это отношение и обозначается термином Работник.


    То Касса и Банковский счет могут быть использованы и в других контекстах.

  • 0
    В модели связи прописаны как в БД, из-за этого логика страдает:
    Чтобы выплатить зарплату сотрудникам некоторой компании,
    мы должны просмотреть все департаменты в мире во всех компаниях, чтобы узнать сотрудникам каких департаментов выплачивать зарплату,
    Потом просмотреть всех сотрудников в мире, чтобы узнать, кто из них работает в найденных департаментах.
    И только затем можно выплатить зарплату.
    Больше похоже на попытку реализовать хранимые процедуры СУБД в коде.
  • +9

    Есть маленькая проблема: поскольку реализациия операции не является деталью реализации объекта, вы теперь не можете это инкапсулировать. В частности, если операция "увольнение" проставляет объекту "сотрудик" флаг "уволен", то как вы реализуете требование "флаг "уволен" может быть проставлен только в ходе операции "увольнение""?


    Далее, группировка операций по "контекстам" не имеет никакого смысла с точки зрения разработки: операции в рамках "контекста" друг с другом, на самом деле, не связаны. С равным успехом можно вынести каждую операцию в отдельный "контекст" и получить, по большому счету, паттерн Command (с определенными оговорками) — каковой паттерн, будем честными, полностью объектно-ориентирован.


    Но по большому счету, то, что у вас описано, называется Transaction Script и описано Фаулером в PoEAA больше десяти лет назад.


    сочетанию объектно-ориентированного и функционального программирования

    Не-а. Ваш код остался объектно-ориентированным. Модель — нет, но модель — это не код. И ваш код не приобрел ничего от функционального программирования, потому что практически первое, чем ценно функциональное программирование — это отсутствие побочных эффектов; у вас же каждая операция порождает эти побочные эффекты во множестве.

  • +3
    Науке он принес больше зла, чем вся Святая инквизиция.

    Ок, низвергаем мыслителей древности, идём дальше.
    Две тысячи лет потребовалось нашим ученым, чтобы затереть следы его «Физики».

    Я бы не клеймил так его трактат, ведь он заочно полемизировал в своих трудах с другими учеными своего времени. На его труды опирались последующие поколения учёных. Пусть он был не прав, но давал пищу для размышления.
    хочется взять античный стилус (так в Риме называли палку погонщика скота)

    Что? Вы про стилос?
    единственная на сегодня корректная философия

    Вы про ранний или поздний период его работы? Они достаточно сильно отличаются, в позднем он отказался от многого, что утверждал в раннем.
    «Единственная»? Как-то очень много пафоса в нескольких абзацах.
    Функциональное программирование стало интуитивной реакцией миллионов разработчиков на туманность ООП – его полным отрицанием.

    Прочитайте вот это

    В комментариях верно заметили — вы изобрели зоново паттерн Медиатор
    • +2
      Что? Вы про стилос?

      Не, про стимулус

    • +1
      низвергаем мыслителей древности
      Да. И между прочим, кроме физики, он принес еще Аристотелеву логику, легшую в основу (с определенными переосмыслениями) современной мат.логики. Чтобы мы сейчас делали без логики? Как бы программировали?
    • +1
      Пусть он был не прав, но давал пищу для размышления.

      Что в глазах любителей «прорывов в науке» должно оправдывать большинство теоретических рассуждений, гипотез и вообще текстов на habrahabr.ru

      единственная на сегодня корректная философия

      Я бы не советовал делать таких утверждений без вводной конструкции «Я считаю» или «Мне так кажется».

  • 0
    Вообще-то палка погонщика называлась стимул. А стилус это таки средство письма. Фейл.
  • +2
    В книгах по программированию честные авторы стыдливо признают, что «объекты – это как бы не совсем объекты»

    Пожалуйста, приведите пару ссылок на эти книги.

    Оказавшись два года назад в мире разработки ПО

    Очень не большой срок.

    Неудивительно, что неопозитивизм – единственная «работающая» философская система, по сути – единственная на сегодня корректная философия: в подтверждение могу упомянуть, например, неопозитивиста Карла Поппера, который разработал современную методологию научного познания.
    Методология Поппера далеко не единственная и не общепризнанная, как и философия неопозитивизма. Многие Все другие философии настаивают на своей истинности. Говоря упрощенно (на уровне упрощений статьи) философия — это тоже модель. А в моделировании нетривиальных сущностей, ситуаций и т.д. не бывает, чтобы одна модель полностью исключала все другие. Одна модель использует одни свойства прототипа и больше подходит для одних целей, другая — другие и больше подходит для других целей.

    Функциональное программирование стало интуитивной реакцией миллионов разработчиков на туманность ООП
    Функциональное появилось раньше: лямбда-исчисление (Алонзо Чёрч, 1930), Лисп (конец 1950х), т.е. раньше, чем Simula 67.

    Пример ИМХО слишком тривиальный для критики методов в ООП. Взять пример сложнее, и мы увидим роль полиморфизма и т.д.

  • +2
    Проблема некоторых разработчиков в том, что они отождествляют class из ООП с некими существующими объектами. Отнюдь, class может представлять собой не только существительное, но и глаголы и прилагательные.

    Поэтому «выдача/получение зарплаты» сама может быть объектом.

    И не смотря на то, что из ООП кто-то пытается сделать религию, а другие дьявола, лично для меня, это всего лишь удобный инструмент.
  • +1
    По моему автор этого опуса, не понял ООП, а когда разобрался, то что бы не считать себя дураком, обвинил в своей косности систему.

    Ну что сказать удобно — все дураки, только один я Дартаньян!
    • +1
      а когда разобрался

      По-моему, еще не :)

    • 0
      Обвинил Аристотеля.
  • –1

    Неплохо для начала самостоятельных изысканий. Мысли и желания идут в верном направлении. Если не хотите тратить много времени, то вот вам ключевое слово — DDD.

  • 0
    Критерий научности Поппера не выдерживает рекурсивной проверки самого себя. Поэтому его претензии на универсальность совершенно не обоснованы. Но за упоминание Витгенштейна зачёт. Всегда приятно видеть признаки хорошего гуманитарного образования. Описанная методика реализации операций на базе контекстов, конечно, отстой. Но не вообще в целом, а только данное конкретное воплощение. В качестве примеров выбраны крайне неудачные объекты и операции, на которых преимущества методики не видны. Они её скорее дискредитируют. Хотя очевидно, что существуют такие операции, которые действительно нельзя корректно привязать ни к какому объекту. Вот на их примере методика заиграла бы совсем иными гранями и выглядела бы достойно.
    • 0
      Критерий научности Поппера не выдерживает рекурсивной проверки самого себя

      Это общеизвестный факт или вы сами додумались? Можно ли ссылку на источник?

      • +1
        https://ru.wikipedia.org/wiki/Проблема_демаркации
        (Не делайте из науки атеистическую религию Великого Пруфа.)
      • 0
        Очевидно, не общеизвестный… раз вы об этом спрашиваете. Скажем так, это общедоступная информация. Более того, об этом нетрудно догадаться самому. Поппер преподносит нам свой критерий как некую догму. Мы должны просто тупо уверовать в то, что это как раз и есть единственно верный способ определения научности. По идее, он должен был бы дополнить свой критерий рассуждением типа: «Если бы этот критерий не работал, то мы бы могли очень легко это обнаружить, поскольку увидели бы то-то и то-то. А раз мы этого не видим, то значит критерий работает.»

        Но это всё не очень интересно, поскольку почти тривиально. По-настоящему интересное написано в книге Пола Фейерабенда «Против метода». Она не конкретно про критерий Поппера, а про то, что научный метод в целом — это фуфло.
        • 0
          Более того, с точки зрения философии даже абсолютность науки недоказуема ))
          • 0
            В философии никто даже не пытается доказывать этот заведомо ложный тезис. Любой адекватный философ знаком с понятием онтологии и прекрасно понимает, что научная онтология является лишь одной из многих. Тем не менее, это всё-таки полноценная онтология. А значит её можно инсталлировать в мозг в качестве единственной и не знать никаких проблем, объясняя всё вокруг исключительно через неё.
            • 0
              > А значит её можно инсталлировать в мозг в качестве единственной и не знать никаких проблем

              Нельзя, да и не получится, «проинсталлируется» только уверенность в том, что наукообразные формулировки — истинны (и агрессия к «гумманитариям», в которые записываются все несогласные). Большинство «бытовых» коммуникаций людей лежат не в сфере выяснения объективной истины, а в сфере синхронизации мнений и вкусов. Часто путают знание фактов с пониманием принципов. Часто называют оценку рисков логическим доказательством. Часто называют умным (научным, объективным, истинным) то, что совпадает с их точкой зрения. Научный метод — лишь один из множества формальных инструментов познания, им не заменить человеческое мышление.
              • 0
                Я именно об этом и говорю. Можно проинсталлировать научную онтологию в мозг и не знать никаких проблем. Подразумевается, что речь идёт о бытовых проблемах. Практически всё, с чем человек сталкивается в обыденной жизни, может быть объяснено в научной парадигме. И даже не факт, что объяснение чего-то будет корректным. Важно, что оно будет убедительным для самого носителя. А значит снимет то тревожное чувство дискомфорта, которое мучило бы его в отсутствие какого-либо объяснения.

                Научный метод сам по себе, разумеется, недостаточен. Для того, чтобы это понять, достаточно приложить минимальное интеллектуальное усилие. Нужно задаться всего лишь одним простым вопросом. Допустим, что с помощью научного метода я могу проверить любую гипотезу — подтвердить или опровергнуть её. Но откуда брать новые гипотезы, требующие проверки? Ведь научный метод начинается с того, что некая гипотеза уже есть. Тем не менее, многие так носятся с этим научным методом, как будто это универсальный ответ на всё. При этом они отнюдь не глупы. Значит у них в мозгу установлена какая-то прошивка, которая содержит такой набор базовых понятий, который не позволяет формулировать вопросы, не имеющие ответов в рамках научной картины мира. Другого объяснения этому нет. По крайней мере, я другого не знаю.
                • 0
                  У научного метода лишь одно назначение — накопление объективных («очищенных» от влияния субъективности), разделяемых, проверяемых знаний. В жизни человека таких знаний не так уж и много, чаще всего человек при принятии решений обходится своей необъективизированной, неформализованной картиной мира из набора разрозненных шаблонов и эмоций. Более того, сам научный метод — не статичный набор аксиом, а консенсус развиваемых философских точек зрения, имеющий разное состояние в разное время и в разных коллективах. Ваша [обращение к неопределённому кругу читателей] вера в науку — завуалированная попытка отнесения себя в социальной иерархии к более высоким позициям, не более того.
                  • 0
                    P.S.: Про «всё может быть объяснено наукой», кстати, вы опоздали на сотню лет, в современном научном методе «объяснительная сила» теориям не требуется, требуется лишь «практическая воспроизводимость опыта». Как сказал Дэвид Мермин: «Заткнись и считай!» Объяснительные интерпретации — удел метанаук и философии.
                    • 0
                      Как сказал Дэвид Мермин: «Заткнись и считай!»
                      Интересная, хоть и популярная публикация на эту тему: Андрей Борисов, Заткнись и считай (Кого не удовлетворит популярный уровень: см. в конце статьи ссылки на научные издания).
                      • 0
                        Вы её даёте в дополнение или в качестве возражения чему-то?
                        • 0
                          В дополнение и как информацию к размышлению, т.к. там конкретные примеры из современной физики.
            • 0
              Вот как раз «не знать никаких проблем» — это и есть недоказуемый тезис.
  • 0
    стилус (так в Риме называли палку погонщика скота)

    Не стимулус, не?
  • –1
    Друзья! Благодарю за ваше внимание, ссылки, комментарии, указания на шаблоны. Именно такой информации я ждал от вас — опытных разработчиков, — поднимая этот вопрос. Спасибо!

    Говоря о Витгенштейне, я подразумеваю ранний период: некоторые базовые положения Логико-Философского трактата — это представляется очевидным, исходя из написанного. Логика, как-то сформулированная Аристотелем, не была им открыта. Она предшествовала не только грекам, но и человеку — и даже миру, возможно. Не будем углубляться в метафизику. Здесь я остаюсь при своем мнении: Аристотель бесполезен как философ и крайне вреден как лжеученый.

    Набросок кода, написанный «на языке Deplhi» (на самом деле, это несуществующий язык с понятными на слух ключевыми словами), я придумал и привел здесь, чтобы не быть голословным. Мне просто был нужен пример. Этот удобен тем, что использует минимум средств языка и платформы. Имея богатые средства, можно сделать лучше. Для меня выжным было показать не инженерный, а философский принцип: адекватное моделирование требует рассматривать факты, а не объекты. Мы-то с вами знаем, что, в отличие от какого-нибудь авиастроения, программирование имеет синтетическую природу: с одной стороны оно — раздел практической философии (как математика), а с другой — инженерная дисциплина. Все, что я тут написал, касается философии исключительно.

    PS Отдельное спасибо за бдительность!:) Зловредную опечатку исправил.
    • +1
      адекватное моделирование требует рассматривать факты, а не объекты

      Нет, не так. Адекватное моделирование требует рассматривать то, что представляет интерес в предметной области.

    • +1
      в отличие от какого-нибудь авиастроения, программирование имеет синтетическую природу: с одной стороны оно — раздел практической философии (как математика), а с другой — инженерная дисциплина
      К «какому-нибудь авиастроению» Вы явно не справедливы: программирование входит и в современное авиастроение, начиная с систем автоматического проектирования и кончая программированием бортовых компьютеров. То, что математика — раздел практической философии, крайне экстравагантное утверждение. Есть область философия математики, но она определяется иначе, чем вся математика.
    • 0
      Да бросьте вы Аристотеля ругать. Они там, в древней Греции, впервые додумались думать о том, как они думают, откуда у всей науки ноги и растут.
    • 0
      Вот здесь вы немного противоречите Витгенштейну. Ну как немного? Ненароком, всего лишь одним предложением вы полностью опровергаете всё его учение. Согласно Витгенштейну, сформулировать нечто на определённом языке как раз и означает открыть это. А применительно к логике, которая существует лишь умозрительно, правильнее будет сказать не просто «открыть», а вообще «создать». Несформулированная логика, которая кому-то предшествовала, абсолютно ни на что не влияла. Говорить о существовании несформулированной логики бессмысленно. Это всё равно, как говорить об использовании ООП, про которое никто в точности не знает, что это вообще такое. Типа, ООП — это когда ты делаешь с объектами всякие разные прикольные штуки, которые всё упрощают. Это вообще ни о чём. Когда ты говоришь об ООП в таком стиле, нельзя сказать, что ты говоришь об ООП.
      • 0
        Изречённое Дао перестаёт быть Дао. :)
  • 0
    Спасибо за очень разумный и глубокий текст! И да, нельзя при помощи ООП моделировать мир, — не для этого он был придуман. Правда, всегда существуют оптимисты, которым кажется, что можно натянуть презерватив на глобус и начать при помощи ООП строить модели предметной области. И да, не каждый программист знаком с логикой Аристотеля и ее ограничениями. Я много писал про ограничения ООП, но понимают эти ограничения лишь те программисты, которые умеют программировать в разных парадигмах. Те, кто научился только ООП, как правило, понять их (ограничения) не в состоянии. Но и у вас я вижу ошибку — наследие ООП. Например, понятие метод. Если речь идет об описании типа объектов (то, что в ООП по ошибке называют «класс»), то в описании типа не может быть метода, там может быть только тип метода. Иначе мы получили бы коллизию. А метод — это то, что есть у объекта. Поэтому правильно говорить про тип объектов, который включает в себя тип методов.
    • 0
      Я много писал про ограничения ООП, но понимают эти ограничения лишь те программисты, которые умеют программировать в разных парадигмах.
      И я писал про ограничения ООП, а начинал программировать со стандартного Паскаля и Фортрана-4, где ООП не было. Поэтому меня заинтересовала Ваша точка зрения. И т.к. могу кодить без ООП, то надеюсь, что могу понять Вашу точку зрения. Ранее Ваши публикации не читал и сейчас только очень бегло проглядел. Первые впечатления очень странные. Так, нпр.:
      Я развиваю мысль о том, что такое реальность и о том, как мы ее моделируем. Я подчеркиваю тот факт, что мир, в котором мы живем, — это иллюзия. Мы даже не знаем, есть ли мы на самом деле, или наше существование — тоже иллюзия. Наше «Я» думает, что существует, но существует оно в мире иллюзий. Все, что мы видим, и что моделируем, — мы видим иллюзию и моделируем иллюзию.
      Это, простите, на солипсизм похоже. Но далее у Вас оговорка:
      Поэтому между реальностью и моделью я всегда рисую субъекта. Каждый субъект видит свою иллюзию. У каждого субъекта своя модель. Мы предпринимаем невероятные усилия, чтобы сделать наши иллюзии похожими.

      Простите за м.б. наивный вопрос: каждый субъект видит прямой угол по-своему, у каждого своя модель и свой аналог теоремы Пифагора? Но не будем сейчас это обсуждать, я просто понадеялся, что Ваши публикации помогут разобраться с тем, что Вы утверждаете здесь, но мне они, к сожалению, пока не помогли. А здесь Вы сказали:

      И да, нельзя при помощи ООП моделировать мир
      Не уверен, что понял, что Вы подразумеваете под словами «моделировать мир», но моделированием явлений данного нам мира традиционно занимается математика. Нпр., есть в нашем с Вами мире хим. реакция между водородом и азотом — при достаточно высоком давлении образуется аммиак. Эта реакция равновесная и моделируется диффурами хим.кинетики настолько хорошо, что с помощью этой модели оказывается экономически оправданным проектирование промышленных установок синтеза. И тут возникает вопрос: почему эту мат. модель я не могу реализовать в программу методами ООП? Допустим, у меня есть некая мат.библиотека, где класс «вектор», у которого методы — скалярное и векторное произведение. Если мне нужен этот класс, я его применю, и это по сути не будет отличаться от процедурного подхода. Но, нпр., в стандартном Паскале для векторов разного размера мне придется написать разные процедуры. Т.е. ООП для модели этого явления мира будет использовать дешевле при одинаковом результате.
      • +1
        каждый субъект видит прямой угол по-своему, у каждого своя модель и свой аналог теоремы Пифагора?

        Понятие угол, прямой угол существуют только у геометров. в другой области деятельности нет углов и нет прямых углов.. Я написал статью на эту тему.

        моделированием явлений данного нам мира традиционно занимается математика.


        Я бы сказал, что математика дает нам инструмент для моделирования. И то, недавно изучая матлогику, я обнаружил у преподавателя слепое пятно: неразличие понятия типа и класса.

        Под моделированием я понимаю построение модели в рамках определенной парадигмы построения моделей. ООП предназначено для моделирования кода, как той предметной области, для которой оно предназначено. И не годится ООП для моделирования предметного мира. Потому что наследование в обычном мире и наследование в мире ООП отличаются. Понятие класса в мире и понятие класса в ООП — тоже отличаются
        • 0
          Понятие угол, прямой угол существуют только у геометров

          Тем не менее, у двух геометров понятия "угол" (и "прямой угол") совпадают.


          (впрочем, нет, понятие "угол" существует не только у геометров)


          И то, недавно изучая матлогику, я обнаружил у преподавателя слепое пятно: неразличие понятия типа и класса.

          А вы не задумывались, что это может быть не его слепое пятно, а просто другая терминологическая система?


          ООП предназначено для моделирования кода, как той предметной области, для которой оно предназначено

          Это утверждение неверно. Модель, построенная с помощью ООП (где П — это программирование), не является моделью кода, потому что в этом случае код это была бы автореферентная модель (код моделировал бы сам себя).


          И не годится ООП для моделирования предметного мира. Потому что наследование в обычном мире и наследование в мире ООП отличаются.

          Это плохой аргумент. Есть много отраслей, понятия в которых не совпадают с понятиями в других отраслях, но это не значит, что они не подходят для моделирования.


          Понятие класса в мире

          Хочу напомнить вам, что, согласно вашей же логике, "в мире" нет понятия класса, понятие "класса" есть только у конкретного субъекта, и нет никакого способа сказать, что одно понятие правильнее другого.

          • +1
            Тем не менее, у двух геометров понятия «угол» (и «прямой угол») совпадают.

            До 20-го века не совпадало. Да и сейчас два геометра легко разойдутся во мнении, что считать прямым углом.

            Про ООП я только в русскоязычных источниках читал про моделирование предметной области. Сами создатели ООП никогда не заикались об этом.

            Про автореферентность — ошибка. Нет ее. ООП описывает то, что потом создает движок, так что автореферентности нет.

            • 0
              Про ООП я только в русскоязычных источниках читал про моделирование предметной области

              The formal programming concept of objects was introduced in the mid-1960s with Simula 67, a major revision of Simula I, a programming language designed for discrete event simulation, created by Ole-Johan Dahl and Kristen Nygaard of the Norwegian Computing Center in Oslo

              :)

              • 0
                Да, а где сказано про моделирование чего-то еще кроме событий?
                • 0

                  А почему должно быть моделирование чего-то еще?

                  • 0
                    Потому что помимо событий есть множество вещей, которые требуют моделирования для решения различных практических задач
                    • 0

                      И что? Вроде, никто не утверждает, что ООП лучше всего подходит для любого моделирования. Но для каких-то вещей подходит.

                • +1

                  А там же: "Simula was used for physical modeling, such as models to study and improve the movement of ships and their content through cargo ports".

            • +1
              Да и сейчас два геометра легко разойдутся во мнении, что считать прямым углом.

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


              ООП описывает то, что потом создает движок, так что автореферентности нет.

              Эээ, простите, что описывает объектно-ориентированное программирование? Какой "движок"?


              Про ООП я только в русскоязычных источниках читал про моделирование предметной области.

              Открываем, значит, "Domain-Driven Design" Эванса.


              Object-oriented design, the paradigm that currently dominates the majority of ambitious projects, is the approach used primarily in this book. [...] simple as the concept of object modeling is, it has proven rich enough to capture important domain knowledge [...] most projects attempting MODEL-DRIVEN DESIGN are wise to use object-oriented technology as the core of their system.

              Для сравнения:


              domains that are intensely mathematical or that are dominated by global logical reasoning do not fit well into the object-oriented paradigm.

              Ну и так далее. Типичная иллюстрация того, что если вы о чем-то не читали, это не значит, что его нет.


              Сами создатели ООП никогда не заикались об этом.

              А кого вы нынче считаете "создателем ООП"?

              • 0
                «Шла конференция по ООП. Одни докладчики говорили про моделирование объектов предметной области, другие выступали по делу.»

                OOP и OOD, а тем более DDD это три разные три буквы.
                • 0
                  OOP и OOD, а тем более DDD это три разные три буквы.

                  Я в курсе. А вот автор поста, как неоднократно замечено — нет.

        • 0
          Понятие угол, прямой угол существуют только у геометров. в другой области деятельности нет углов
          Вот это новость! Даже ребенок-дошкольник понимает, если ему сказать: «встань в угол».
          Я бы сказал, что математика дает нам инструмент для моделирования.
          Есть четкое понятие мат.модель, а бывают другие модели, нпр., модель самолета из дерева для испытаний в аэродинамической трубе.
          ООП предназначено для моделирования кода
          Т.е. код — прототип? Но нетривиальная модель не тождественна прототипу. Получается противоречие: программа не тождественна коду, на котором написана, т.е. не тождественна самой себе!
          Потому что наследование в обычном мире и наследование в мире ООП отличаются.
          Чем? В обычном мире наследуются свойства и методы, и в ООП наследуются свойства и методы. Ребенок подражает родителям и наследует их методы поведения (как хорошие, так и плохие), а от рождения он может унаследовать родительские свойства, нпр., рыжие волосы.
          Понятие класса в мире и понятие класса в ООП — тоже отличаются
          Чем? Нпр., в мире наблюдается класс любителей риторики. Экземпляры этого класса используют одинаковые риторические методы, чтобы «наводить тень на плетень» :)
  • +1
    ООП – всего лишь способ организации кода, а не механизм моделирования.
    • 0
      https://ru.wikipedia.org/wiki/UML

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.