Предел Парадигмы ООП в действительно сложной системе? [закрыто]

Просто прочтите свою статью о Entity Systems, в которой ES сравнивается с ООП, и она явно ошибочна в отношении некоторых аспектов ООП. например, когда существует 100 экземпляров класса, ООП не требует, чтобы в память было загружено 100 копий методов класса, необходим только один. Все, что ES претендует на то, чтобы делать «лучше», чем ООП, потому что в нем есть «Компоненты» и «Системы», ООП поддерживает также интерфейсы и статические классы (и / или синглтоны).

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

Системы любой заметной сложности не являются линейными. Даже если вы очень усердно работали над тем, чтобы сделать систему одним линейным процессом, вы все равно полагаетесь на такие вещи, как диски, память и сетевые соединения, которые могут быть нестабильными, так что вам придется работать над этим.

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

На самом деле нет предела тому, с чем может иметь дело ООП - точно так же, как нет реального предела тому, с чем может иметь дело C, или ассемблер в этом отношении. Все они являются полными по Тьюрингу, и это все, что вам действительно нужно.

ООП просто дает вам более высокоуровневый способ разбивки программы, точно так же, как C - это более высокий уровень, чем ассемблер.

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

Итак, у вас есть теоретический вопрос.

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

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

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

Ребят, а разве вопрос не больше об ORM, чем о ООП? ООП - это стиль программирования: фактически сравнивается реляционная база данных, отображаемая на объекты.

ООП на самом деле больше, чем просто ORM! И дело не только в наследовании и полиморфизме! Это чрезвычайно широкий спектр шаблонов проектирования и, прежде всего, то, как мы думаем о самом программировании.

Хорхе: это нормально, что вы указали на оптимизирующую часть - вы не добавили, что этот шаг должен быть выполнен последний и в 99% случаев медленная часть - это не ООП.

Теперь понятно и просто: стиль ООП со всеми добавленными к нему принципалами (чистый код, использование шаблонов проектирования, не до структур глубокого наследования и давайте не будем забывать модульное тестирование!) Это способ помочь большему количеству людей понять, что вы написали. Это, в свою очередь, необходимо компаниям для обеспечения безопасности своего бизнеса. Это также прием для небольших команд, чтобы лучше понимать друг друга. Это похоже на общий метаязык поверх самого языка программирования.

О Entity Systems. Это интересная концепция, но ничего особенного в ней нет. Например, в нем говорится:

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

Но разве это не то же самое, что антипаттерн Мартина Фаулера под названием «Анемический домен» Модель »(которая фактически широко используется в настоящее время) ссылка ?

Так что, по сути, ES - это« идея на бумаге ». Чтобы люди приняли это, это ДОЛЖНО быть подтверждено рабочими примерами кода. В статье нет ни слова о том, как реализовать эту идею на практике. Ничего не сказано о масштабируемости. Ничего не сказано об отказоустойчивости ...

Что касается вашего фактического вопроса, я не понимаю, насколько Entity Systems, описанные в статье, могут быть похожи на реляционные базы данных. В реляционных базах данных нет такого понятия, как «аспекты», описанные в статье. Фактически, реляционная структура данных, основанная на таблицах, очень ограничена, например, когда дело доходит до работы с иерархическими данными. Более ограниченный, чем, например, объектные базы данных ...

Проблема не в объектно-ориентированном подходе в большинстве ситуаций, проблема заключается в производительности и фактическом развитии базового оборудования.

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

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

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

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

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

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

РЕДАКТИРОВАТЬ: Чтобы ответить на вопрос о том, зачем использовать чистый объектно-ориентированный объект. Каждая «наука» хочет иметь законченную модель для представления вещей. У нас есть две физические модели для описания природы: одна на микроскопическом уровне, а другая - на макроскопическом, и мы хотим иметь только одну, потому что она упрощает вещи и дает нам лучший способ доказывать, тестировать и развивать вещи. С OO применяется тот же процесс. Вы не можете аналитически протестировать и доказать систему, если система не следует точному набору правил. Если вы переключаетесь между парадигмами в программе, ваша программа не может быть должным образом проанализирована, ее необходимо исследовать в каждой из них, проанализировать, а затем снова проанализировать, чтобы убедиться в правильности взаимодействия. Это значительно усложняет понимание системы, потому что на самом деле у вас есть две или три системы, которые взаимодействуют по-разному.

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

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

Не могли бы вы пояснить, что именно вы здесь пытаетесь сравнить и доказать? ООП - это парадигма программирования, одна из многих. Это не идеально. Это не серебряная пуля.

Что означает «реляционно-ориентированное программирование»? Ориентация на данные? Что ж, Microsoft двигалась в сторону более ориентированного на данные стиля программирования, пока они не отказались от Linq2Sql и полностью сосредоточились на своей O / RM EntityFramework.

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

В первом фрагменте кода Something является простым объектом, а не конструктором. В частности, нельзя называть:

var o = new Something();

Такая форма создания объектов идеальна для одиночек; объекты, для которых вам нужен только один экземпляр.

Во втором фрагменте , Something является конструктором, и вы можете использовать с ним ключевое слово new .

Изменить:

Кроме того, во втором фрагменте, поскольку вы используете Something.name в отличие от this.name , он всегда будет предупреждать имя конструктора само, которое является "Something" , если вы не переопределите это свойство чем-то вроде Something.name = "Cool"; .

Вы, вероятно, хотели, чтобы в этой строке говорилось:Я @ 190d11В мире C # это дает нам строго типизированную систему, так что все от начала до конца может быть скомпилировано и протестировано. База данных с трудом проходит тестирование, рефакторинг и т. Д. ООП позволяет нам организовать наше приложение по уровням и иерархиям, чего не позволяют реляционные системы.