Является ли объектно -ориентированное программирование решением сложности? [закрыто
-
22-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Как вы думаете, объектно -ориентированное программирование - это решение сложности. Почему? Эта тема может быть немного противоречивой, но я намерения узнать ответ о том, почему эксперты здесь!
Решение
Нет решения сложности.
В «Мифическом человеке» Фред Брукс обсуждает разницу между случайной и существенной сложностью в программировании. Случайная сложность вызвана нашими инструментами и методами, такими как необходимость писать и тестировать дополнительный код на языке, потому что мы не можем выразить наши идеи напрямую и тому подобное. Новые методы и методы могут уменьшить случайную сложность. Я могу писать программы быстрее и лучше, чем мог двадцать пять лет назад, потому что у меня есть лучшие языки и инструменты.
Основная сложность возникает из -за того, что то, что мы пытаемся сделать с программированием, по своей сути сложно, и что существует неприводимая сложность. «Существенный» в этом контексте означает «отношение к сущности вещи», а не «очень необходимо».
Поэтому он утверждал, что не будет серебряной пули, что программное обеспечение для письма будет оставаться трудным.
Я настоятельно рекомендую вам прочитать его книгу: в частности, я рекомендую издание Silver Anniversary, с дополнительным эссе «Нет серебряной пули». В этом он рассматривает предлагаемые решения о сложности и рассматривает их влияние. (То, что он находит наиболее эффективным, - это программное обеспечение Shrink -WRAP - один раз напишите что -то сложное и продайте тысячи или миллионы копий.)
Теперь объектно-ориентированное программирование помогает, когда все сделано правильно, создавая абстракции и скрывая сложность. Объект класса имеет определенное определенное поведение, из которого мы можем рассуждать, не заботясь о сложности реализации. Правильно написанные классы имеют низкую связь друг с другом, а разделение и привлечение-отличный способ справиться со сложностью, если вы можете сойти с рук. Они также имеют высокую сплоченность, поскольку они набор функций и данных, которые очень тесно связаны друг с другом.
Другие советы
Я ожидаю, что вы получите несколько лучших ответов в ближайшее время, но вот простой:
ООП помогает* со сложности путем моделирования программного обеспечения более ближе к тому, как мы моделируем все остальное в мире. В целом легче представить, что шаровой объект взаимодействует с стеновым объектом, чем представить серию процедур и структур данных, чтобы сделать то же самое, поскольку он ближе к тому, как мы взаимодействуем с реальным миром.
*Потому что ничто не может «решить» сложность
Я думаю, что текущее основное определение ООП не является хорошим решением для управления сложностью.
Если вы вернетесь к его корням, я полагаю, что Алан Кей был под влиянием "LISP".
Поскольку LISP не был поврежден в результате принятия основного направления, ему, вероятно, удалось сохранить свои основные ценности. Поэтому я думаю, что, глядя на то, как LISP решает эту проблему сложности, может дать нам некоторое понимание, и мы можем использовать ее как основу, чтобы судить, насколько полезен OOP для борьбы со сложностью.
Если вы посмотрите на конец «лекции 3A: пример Хендерсона Эшер» SICP, Хэл Абельсон предлагает, чтобы сложность управлялась не путем разбивания задачи на более мелкие подзадачи, а создавая слои абстракции. На самом высоком уровне вы выражаете решение сложной проблемы с точки зрения решения более низкого уровня абстракции.
Я думаю, что ООП изначально предназначался как механизм для создания этих слоев абстракций.
К сожалению, в настоящее время OOP (AB) используется для написания кода/структур спагетти.
Я сделаю пример: FPS-Multi-Player игра.
На самом высоком уровне игра работает, заставляя кучу игроков, бегающих по карте и стреляя друг в друга с помощью оружия.
На следующем нижнем уровне мы должны поговорить о картах, оружии и игроках. Возможно, мы сможем говорить о них как о физических объектах, которые взаимодействуют в мире игры.
На следующем более низком уровне мы можем поговорить о том, как объекты взаимодействуют физически (движение, столкновения и т. Д.).
И так далее.
Что это значит (и я как бы цитирую SICP ..), так это то, что на каждом уровне мы решаем не только конкретную проблему, но и класс проблем, которые падают по соседству с проблемой, которую мы » Попытка решить. Так что, если в описании проблемы произойдет небольшое изменение, это, вероятно, потребует лишь небольшого изменения в решении.
Таким образом, мудрый способ использования ООП - создать слои абстракций, на каждом уровне абстракции вы решаете проблему под рукой, используя «объекты» с уровня, который находится непосредственно ниже.
Вот бит, который я цитировал от лекции: http://www.youtube.com/watch?v=cytrfncmqhq
Как обычно, я не согласен со всеми. ООП, далеко не давая вам инструменты для управления сложностью, создает огромное количество сложности, потому что это неадекватная и математически поддельная парадигма. Это сбивает с толку программистам, чтобы попытаться моделировать вещи с ООП, которые не могут быть смоделированы с ООП.
На мой взгляд, оригинальная работа здесь - объектно -ориентированное программное обеспечение Meyer. В нем подробно описывается набор требований, в том числе один, который я считаю решающим: принцип открытого закрытия. Это говорит о том, что вещь должна быть открыта для расширения, но закрыто для использования, в то же время.
Мейер продолжает вывести объектную ориентацию из этих требований, как воплощено в Эйфелеве. Инкапсуляция обеспечивает закрытие, наследование открытия, а «вещь» упомянута-это класс.
Я считаю эту работу хорошей наукой, потому что Мейер был очевидно неправ, и это возможно из -за качества его работы, чтобы определить ошибку и исправить ее.
Ошибка заключается в том, чтобы сделать класс или тип, единицу модульности. Это неправильно, и это, как доказательно, так. Даже Мейер признал эту проблему (называемую проблемой ковариации), что ООП не может справляться с отношениями артистического языка выше одного (то есть ООП отлично работает для свойств, но терпит неудачу в бинарных отношениях). В Эйфелеве эта проблема привела к неоснащению в системе типов!
Решение довольно ясное. Единица модульности должна быть больше, чем один тип. Он должен состоять из нескольких типов и методов, связанных с ними.
Вряд ли удивительно, что эта модель абстракции подкреплена математической теорией абстракции, а именно теории категорий: типы являются объектами категории, а методы (функции) являются стрелками.
С этой моделью представления несколько Типы известны набору функций. Представление скрыто от общественности, так что это энкапульсность, но мы используем модули, а не классы.
Стандартный мета-языковый (SML) и OCAML основаны непосредственно на этой модели. У OOP также есть классы и ООП: это не бесполезно, потому что ООП дает вам отправку на свойствах, так как динамическое связывание. Однако большинство проблем реального мира связаны с отношениями, и вряд ли удивительно, что классы не используются в OCAML.
Вряд ли удивительно наследство вряд ли используется вообще в библиотеке стандартных шаблонов C ++.
Простой факт заключается в том, что ООП не дает вам правильных инструментов для обработки сложности, он даже не дает вам инструментов для решения действительно простых проблем, вместо этого он вводит в заблуждение и запутало два поколения программистов. Далеко не помогая, ООП - самая злая и плохая вещь, которая произошла с программированием с тех пор, как С., Фортран и Кобол начали уставать.
Объектно-ориентированное программирование имеет корни, которые можно проследить до 1960-х годов. Поскольку аппаратное и программное обеспечение становилось все более сложным, управляемость часто стала проблемой. Исследователи изучили способы поддержания качества программного обеспечения и разработали объектно-ориентированные программы частично для решения общих проблем, уделяя особое внимание Дискретные, многоразовые единицы логики программирования.
Таким образом, объектно-ориентированная программа может рассматриваться как набор взаимодействующих объектов, в отличие от обычной модели, в которой программа рассматривается как список задач (подпрограммы) для выполнения. В ООП каждый объект способен получать сообщения, обрабатывать данные и отправлять сообщения на другие объекты. Каждый объект можно рассматривать как независимую «машину» с особой ролью или ответственностью. Действия (или «методы») на эти объекты тесно связано с самим объектом.
http://en.wikipedia.org/wiki/object-oriented_programming
Это разделение проблем, наряду с другими особенностями объектной ориентации, такими как полиморфизм, наследование, передача сообщений, развязка и инкапсуляция, обеспечивает логическую и концептуальную основу, с помощью которой может управляться сложность крупных программ.
Есть много видов сложности в разработке программного обеспечения. На уровне программирования OOP стремится учитывать сложность, используя объекты и классы для моделирования проблемного домена. Известный гуру сказал, что решение проблем просто представляет проблему, так что решением является само представление. Следовательно, путем абстракции с использованием классов, инкапсуляции с использованием модификаторов доступа и методов, наследование для определения взаимосвязи и повторного использования, состав в установлении отношений и сотрудничества между классами, полиморфизма как среднего для упрощения определения различных поведений в аналогичных объектах может управлять сложностью.
Существуют также другие способы управления сложностью программного обеспечения, например, логическое (Prolog) и функциональное (Haskell) программирование.
На уровне выше, чем программирование, нам нужны шаблоны проектирования и принципы для руководства ООП. Следовательно, ООП управляет сложностью на низком (кодирующем) уровне, в то время как эти методологии, такие как проектные шаблоны и принципы, направляют проектирование решения на более высоком уровне (системный и приложение) и делают разработку программного обеспечения и сложность обработки более управляемыми.
Чтобы ответить на ваш вопрос, да, ООП - это просто решение для обработки сложности среди многих других решений. Это решение на низком уровне. Нам нужны шаблоны дизайна и принципы, чтобы направлять ООП на более высоком уровне.
Объектно-ориентированного программирования Управляется Основная и дополнительная сложность, но не уменьшается.
Я предпочитаю определение, предоставленное Эриком Стивеном Рэймондом в Искусство программирования UNIX, потому что это определяется между важной, необязательной и случайной сложностью.http://www.faqs.org/docs/artu/ch13s01.html#id2964646
ООП ничего не делает для существенной или необязательной сложности, они являются функцией требований программы. Это может повлиять на случайную сложность, поскольку вы можете иногда создавать более элегантный дизайн с ООП. Иногда, однако, дизайн хуже при использовании ООП.
Сложные проблемы не могут быть проще с помощью технологий, они могут быть только удалось через технологии.
ООП - это технология, концепция и способ решения проблемы.
ООП дает вам инструменты для обеспечения соблюдения дизайн Это может облегчить управление сложностью, но вы можете так же легко иметь плохой дизайн, который увеличивает вашу сложность. Другими словами, если они не используются должным образом, вы можете иметь сложность, вызванную технологиями в ваших проблемах.
Имейте в виду, что есть много других аспектов, которые будут определять, насколько успешным будет ваш проект (т.е. стиль управления проектами, определение проблем, управление изменениями и т. Д.). Технология, которую вы используете, актуальна только в том, сколько она вам поможет управлять проблема.
В конце, объектно -ориентированное программирование не может быть решение к сложности; Это просто инструмент для управления им. (Если правильно используется)
Объективная ориентация (как используется традиционно) является полезным инструментом во многих обстоятельствах, но это не достаточное решение для сложности.
В частности, это часто добавляет много »случайная сложность«Примеры - это сложность наследства реализации, необходимость обеспечения большого количества« стандартной функциональности »Suach As Equals () и Hashcode () и т. Д.Простота нелегко"
Объекты на большинстве языков также имеют тенденцию инкапсулировать много изменчивое состояние - который в одновременном мире все больше начинает выглядеть как плохое решение о дизайне. Снова интересный Видео Рич Хикки Взгляните на различие между идентичностью объекта и состоянием, и как может быть ошибка сопряжение их.
Объектно -ориентированное программирование - это способ представить проблему, не более того, не меньше. Само по себе он не менее сложный, чем любая другая парадигма программирования. Хорошо разработанная система ООП управляет и уменьшает сложность, но также очень легко разработать систему, которая гораздо сложнее, чем необходимо, и мешает всем.
Как сказал о C ++, OOP дает вам достаточно веревки, чтобы повесить себя.
Я думаю ДА, только потому, что он позволяет вам нарезать сложность на небольшие самодостаточные «строительные блоки», которые скрывают детали, а затем используют их для создания необходимой вам функциональности, шаг за шагом, слой за слоем.
Разделите и победите.
ООП - это попытка решения.
Лучший способ управлять сложностью - это создать абстракции. Если я смогу превратить свои данные в полезные коллекции с узнаваемыми функциями, которые работают на этих коллекциях, я могу начать думать о коллекциях как «дискретные" вещи ". Это основа для классов и методов. В этом отношении правильно разработанный ООП может помочь справиться с сложностью.
Где-то по пути кто-то решил, что мы можем использовать ООП, чтобы помочь решить проблему повторного использования кода. Я имею в виду, зачем заново изобретать колесо? Если кто -то еще проделал большую часть работы по решению этой проблемы, используйте то, что он сделал, добавьте настройки, которые требуют ваш, конкретный проект, и вуаля! Вы создали мощное, сложное приложение с относительно небольшой работой с вашей стороны. OO программисты могут быть очень продуктивными программистами.
Конечным результатом является то, что современные программисты ОО в конечном итоге становятся «учениками колдуна», где они связывают кучу больших, громоздких библиотек с несколькими линиями «клея» и получают что -то, что работает. Сорта Как бы. Большую часть времени. Есть ли потенциальные побочные эффекты от использования этой библиотеки с этой? Может быть. Но у кого есть время, чтобы действительно покопаться в коде, содержащемся в этих библиотеках? Особенно, когда библиотеки развиваются. В результате мы получаем раздутые приложения, где программисту нуждалась несколько классов и методов из этой библиотеки, но приложение должно носить вес всех остальных вещей, которые им не нуждались.
Конечным результатом является то, что у вас гораздо больше сложности, чем вам нужно.
Еще один механизм, чтобы справиться со сложностью, которую вы хотите разделить функциональность. Вы хотите, чтобы все ваши функции доступа к данным в одном месте. Вы хотите, чтобы все функциональные возможности пользовательского интерфейса в одном месте. Вы хотите, чтобы все ваши контроллеры в одном месте. Таким образом, вы создаете разные классы, которые управляют разными частями функциональности. Все идет нормально. И это масштабируется до некоторой степени; Ваши разработчики, которые обладают опытом доступа к данным, могут написать эти классы, ваши люди пользователя могут написать классы пользователя-интерфейса и т. Д. Все хорошо и хорошо.
Пока вы не должны сохранить что -то написанное кем -то другим.
Да, приятно знать, что все функции доступа к данным расположены здесь. Но что их называет?
Этот метод вызывает этот метод в этом классе. Но когда я смотрю на определение класса, с этим именем нет метода. О, это унаследовано от чего -то еще одного или двух слоев в цепочке наследования. Подождите минуту; Этот класс реализовал интерфейс? Сколько разных классов реализуют этот интерфейс? И мы используем какую-то сложную систему времени выполнения (я смотрю на вас, весна), чтобы «провести вместе» экземпляры классов во время выполнения? Где можно использовать любой класс, который реализует этот интерфейс?
В итоге вы получаете множество небольших, дискретных методов, которые делают точные вещи. Но этот называет это, в другом классе. Который называет это, в еще одном классе. Который называет это, в еще одном классе. Который называет это, в дополнительном классе. Который возвращает результат конкретного типа. На котором вы должны назвать метод, чтобы сделать определенную вещь. Который возвращает результат другого типа. И т.п.
Для этого есть термин: код спагетти.
Вы получите очень сложную систему, необходимую только для составления кода. Следовательно, как визуальная студия, затмение и Netbeans. Все это имеет значительную кривую обучения. Действительно, многие из них способны инкапсулировать/собирать несколько инструментов, разработанных различными группами, каждая из которых имеет свои собственные кривые обучения.
Это управление сложностью?
Код отладки в два раза выше, чем написание. Удачи отладки некоторых из этих вещей. Особенно, если он использует несколько библиотек, «соединяется вместе» во время выполнения, используя какую-то систему инъекции зависимостей.
Таким образом: ООП предоставляет то, что выглядит как многообещающий инструмент, чтобы помочь управлять сложностью. Реальность такова, что в результате код имеет тенденцию быть ужасно раздутым (потому что вы не можете извлечь только те куски, которые вам нужны из всех этих связанных библиотек), и вам нужны сложные инструменты, чтобы навигацию по коду. Это быстро становится кошмаром обслуживания.
ИМХО, это чистая потеря; Это добавляет больше сложности, чем устраняет. Это позволяет вам делать то, что было бы чрезвычайно сложным, возможно, даже невозможно, без этого. Но любой крупный проект быстро превращается в невозметимый беспорядок.
Если вы уже знаете, как это работает, и вы можете вспомнить это, у вас может быть шанс поддерживать его.
Не забудьте применить закон Иглсона: любой собственный кодекс, который вы не смотрели в течение шести месяцев, также может быть написан кем -то другим.
До некоторой степени...
Почему? Потому что это облегчает очень логичную модульность. По крайней мере, по сравнению с процедурным программированием, где слишком заманчиво просто писать огромные кучи кода спагетти.
Причина, ориентированное на объект, похоже, помогает нам справиться с сложностью, заключается в том, что оно заставляет нас писать код определенным образом, а не огромным разнообразием способов. Программирование, ориентированное на задачу, гораздо более интуитивно понятно, поэтому программирование началось таким образом. Объектно-ориентация требует обучения и практики для эффективного понимания и использования, но, ограничивая программирование в определенный путь, это позволяет тем, кто обучен эффективно поддерживать написанный код.
Это не более логично или реально, чем любой другой метод, это просто способ сосредоточить наше решение проблем с помощью аналогичных линз. Многие технические специальности используют парадигму неинтуированной жесткой методологии для выполнения сложности их задач.
Третий метод для обработки сложности будет функциональное программирование, и в будущем, вероятно, будут и другие новые методы.
Я думаю, что это скорее решение для обслуживания, потому что, как программист, вы должны размещать методы, в которых у вас есть данные, создавая тем самым объектную модель вашего приложения.
Да, это также решение сложности, предоставляя вам модель, чтобы «увидеть» свой код естественным образом, как объекты, которые имеют свойства и возможные действия
