Какой смысл в ООП?
Насколько я могу судить, несмотря на бесчисленные миллионы или миллиарды, потраченные на обучение, языки и инструменты ООП, ООП не повысила производительность труда разработчиков или надежность программного обеспечения, а также не снизила затраты на разработку. Мало кто использует ООП в каком-либо строгом смысле (мало кто придерживается или понимает такие принципы, как LSP); похоже, что подходы, применяемые к моделированию проблемных областей, мало единообразны или непротиворечивы. Слишком часто класс используется просто для его синтаксического сахара; он помещает функции для типа записи в их собственное маленькое пространство имен.
Я написал большое количество кода для самых разных приложений. Хотя были места, где истинно замещаемый подтип играл важную роль в приложении, они были довольно исключительными. В целом, хотя много говорят на словах о "повторном использовании", реальность такова, что если часть кода не выполняет именно то , что вы хотите, то очень мало рентабельного "повторного использования". Очень трудно спроектировать классы, чтобы их можно было правильно расширять, поэтому стоимость расширения, как правило, настолько велика, что повторное использование просто не стоит.
Во многих отношениях это меня не удивляет. Реальный мир - это не "ОО", и идея ОО, подразумеваемая в ОО - что мы можем моделировать вещи с помощью некоторой классовой таксономии - кажется мне очень фундаментальной ошибкой (я могу сидеть на столе, пне, капоте автомобиля кто-то на коленях - но не один из тех - стул). Даже если мы перейдем к более абстрактным областям, ОО-моделирование часто бывает трудным, нелогичным и, в конечном счете, бесполезным (рассмотрим классические примеры кругов / эллипсов или квадратов / прямоугольников).
Так чего мне здесь не хватает? Где ценность ООП, и почему все время и деньги не смогли сделать программное обеспечение лучше?
45 ответов
Исходя из моего опыта, который начался в C/Unix (не OOP) в середине 1980-х годов, затем перешел на C++ (OOP) в 1990 году, а затем в Java в 1996 году (OOP), я обнаружил, что OOP значительно повышает производительность, удобство обслуживания и надежность. по сравнению с большими не ООП программами, над которыми я работал ранее.
Главное, что я заметил, это то, что в приложениях без ООП я работал над сложностью, которая, казалось, росла экспоненциально по сравнению со сложностью приложения, тогда как в приложениях ООП, над которыми я работал, сложность, казалось, имела гораздо более линейный характер. Отношения с уважением к сложности приложения.
Другими словами - с хорошо разработанными ООП-приложениями вы никогда не получите "OMG, исходный код для этого приложения выходит из-под контроля", что вы получаете с большими не ООП-приложениями.
Другие вещи, без которых я как разработчик ООП не могу обойтись, это способ, которым я могу написать код, который моделирует сущности реального мира, которые существуют в проблемной области приложения. Объекты живут своей собственной жизнью - за пределами того, что какие-либо структуры (C) или Записи (Паскаль) делали в старые добрые =] не ООП дни.
Одно условие состоит в том, что главный архитектор проекта ООП должен знать, что он делает, и он должен обычно тратить больше времени на обдумывание правильного дизайна, чем на его фактическую реализацию, но окупаемость "продумывания вещей заранее" действительно удивительна, Выявляются возможности для повторного использования или потрясающе крутой оптимизации дизайна, когда вы бьете в воздух и делаете приземления в офисе... хорошо, это может выглядеть немного странно для других в офисе, но такого рода энтузиазм никогда не случался в ООП дни:)
Я видел довольно плохо написанный ООП-код и, возможно, это то, что вы испытали, что могло заставить вас задать вопрос. Как подрядчик, в середине 90-х я часто обнаруживал, что проект "ОО" уже был начат кем-то, кто знал, что такое класс, но не намного. Это был очень болезненный опыт, и я часто обнаруживал, что мои первые несколько месяцев работы включали обучение команды совершенно другому способу мышления "ОО". Только после того, как мозг каждого был перемонтирован, мы все могли действовать как одна команда, чтобы создать что-то потрясающее.
Многие люди находят процесс "перестройки мозга" слишком сложным, болезненным или просто слишком большим усилием, и поэтому проводят всю свою жизнь, разворачивая ООП, и поэтому вы найдете там много ОО ненавистников, но я рад этому, потому что это те люди это заставляет людей, подобных мне, выглядеть хорошо: "Что, вы можете сделать это за $X, и это будет готово через 2 месяца, и вы дадите нам поддерживаемую кодовую базу!!! Ого, вы можете начать сегодня?"
"Реальный мир - это не" ОО ""
В самом деле? Мой мир полон объектов. Я использую один сейчас. Я думаю, что наличие программных "объектов" моделирует реальные объекты не так уж плохо.
ОО-проекты для концептуальных вещей (таких как Windows, не окна реального мира, а панели дисплея на мониторе моего компьютера) часто оставляют желать лучшего. Но для вещей реального мира, таких как счета, заказы на доставку, страховые претензии и тому подобное, я думаю, что эти вещи в реальном мире являются объектами. У меня на столе стопка, поэтому они должны быть настоящими.
Для меня ценность ООП состоит в том, чтобы уменьшить область и отделить состояние от поведения. С меньшей областью кода легче понять.
Это может быть сделано в большинстве языков, все, что нужно для достижения этой цели, - это способ для государства делегировать вызов метода поведению и способ для поведения, чтобы далее делегировать вызов родительскому поведению.
Поскольку набор классов эффективно моделирует домен, магического метода не существует. Как пианино, мы должны практиковаться. ООП - это абстрактный инструмент, он может помочь вам создавать код более простым способом, но он не может думать и анализировать область вашего приложения для вас.
Что мне подходит, так это как можно дольше оставаться рядом с доменом, при этом избегая дублирования кода.
Реальный мир не "ОО". Реальный мир в основном не состоит из разумных частей. Вместо этого он сделан из хаотично движущихся частиц. Земля - это суп из частиц. Еще люди видят птиц, деревья, небо, землю, леса, пруды. ОО - это абстракция программных компонентов. В корне неверно думать о ОО для моделирования чего-то другого, кроме программ.
Все деньги и время не смогли сделать программное обеспечение лучше, потому что оно не сделало программистов умнее, а также потому, что оно не смогло изменить отношение людей к программному обеспечению. "ООП" в том смысле, в каком вы его используете, это модное слово, используемое для получения денег от идиотов. Да, люди, вложившие деньги в образование и инструменты "ООП", - идиоты. Люди, которые имеют тенденцию падать на обман, как правило, идиоты.
Значение "ООП" - это абстракция и повторное использование кода внутри одной и той же программы. ООП предназначен для использования с императивными программами.
Если вы встаете из сборочных процедур. Сборка представляет собой упорядоченные последовательности пар, составленные из меток и инструкций. Код сборки похож на "суп из частиц". Теперь вы можете перейти к подпрограмме. Подпрограмма выбирает метку из этой метки: инструкция -soup и скрывает остальные метки внутри подпрограммы. Поскольку код эффекта становится более абстрактным, а ваше пространство имен становится чище.
Теперь, если вы думаете, что делают подпрограммы... Несколько десятилетий назад люди думали, что подпрограммы в своих лучших проявлениях, когда они работают над аргументами. Это заставило их дать каждому объекту свой собственный протокол. Протокол будет содержать метку: процедура-пары. Теперь вызывается селектор: метод-пары. Процедуры больше не были связаны напрямую с другими процедурами, объясняя термин "позднее связывание". Наряду с сохранением истории из протоколов (наследование), это сформировало "объектную ориентацию" в разговоре.
Вы были выведены из строя механизм позднего связывания и забыли, что означает наследование. И вам пока интересно, чего вам там не хватает. "Где ценность ООП, и почему все время и деньги не смогли сделать программное обеспечение лучше?" - Я думаю, что ты засунул их в свою задницу. Когда вы попытаетесь сделать колоноскопию, вы найдете их.
Будем ли мы говорить то же самое через десять лет о функциональном программировании?
На этот вопрос уже есть много ответов, так как это старый пост, но я подумала, что подумаю.
Вы упомянули "классовую таксономию", которая проникает в подтипы и полиморфизм. Все это вращается вокруг наследства, которое в его расцвете считалось серебряной пулей ООП. В настоящее время наследование и большие иерархии классов фактически не поощряются, даже среди магазинов, которые делают много ООП. Это связано с тем, что другие факторы ООП, такие как инкапсуляция, слабая связь, сплоченность и т. Д., Оказались гораздо более полезными, чем наследование. Я бы даже сказал, что слабая связь является причиной ОО, а не повторного использования кода. Повторное использование кода обычно происходит на уровне метода / функции. Я иногда повторяю занятия в разных обстоятельствах, но не так часто. Однако слабая связь помогает немного организовать систему. Каждый объект имеет свою собственную область, данные в объекте не обрабатываются или не должны обрабатываться, за исключением методов доступа или свойств, каждый объект должен выполнять одну простую вещь и должен взаимодействовать с другими объектами через простые интерфейсы. Эта горстка принципов помогает удобочитаемости кода, помогает локализовать ошибки и избавляет вас от необходимости вносить много изменений в разных местах, чтобы изменить что-то одно. Когда объекты не тесно переплетены, вы можете изменить один, не влияя на другие. Это было огромным преимуществом для меня. Наследование полезно только сейчас и потом.
Повторное использование кода по-прежнему важно, и если вы копируете и вставляете или переписываете один и тот же код, это плохая практика даже при простом старом процедурном, структурированном или функциональном программировании. Это на самом деле увеличивает затраты из-за дублирования усилий, увеличения технического обслуживания и большего количества ошибок.
ООП помогает отделить интерфейс от реализации. Вам не нужна поддержка ООП на языке, чтобы воспользоваться ОО-дизайном.
Один небольшой пример, где ООП очень помог:
Уровень виртуальной файловой системы UNIX (VFS) представляет собой единый интерфейс (открытие / чтение / запись) с использованием таблиц указателей функций - во многом аналогично диспетчеризации виртуальных таблиц C++.
Клиенты используют один и тот же набор вызовов независимо от того, общаются ли они с локальной файловой системой, удаленной сетевой файловой системой (NFS) или (сегодня) поддельными файловыми системами (например, /proc).
См. Оригинальную статью Sun: Vnodes: архитектура для нескольких типов файловых систем в Sun UNIX
РУЧКИ (и остальная часть WinAPI) - ООП!
Хотя они? Они не наследуются, они, конечно, не заменяемы, им не хватает четко определенных классов... Я думаю, что они далеки от "ООП".
"Даже если фактической [информационной архитектуры] не существует, это не значит, что мы не испытываем и не воспринимаем ее как таковую. Дзен-буддисты говорят, что фактического" я "не существует, но они по-прежнему называют своих детей", - Эндрю Хинтон.
Может быть, капот, колени или дерево не стул, но все они ISittable.
Да, но только ex post facto. Они ISittable, потому что кто-то сел на них.
Я знаю, что ООП полезен почти исключительно на синтаксической основе (инкапсуляция, перегрузка операторов, проверка типов). Что касается преимуществ ООП... я не знаю. Я не думаю, что это хуже, чем процедурные вещи.
С другой стороны, мой лектор ООП сказал, что ООП важен, потому что в противном случае "код имел бы слишком много циклов". Да уж. Иногда удручает, что я плачу 500 долларов за бумагу.:(
ООП снизило затраты и повысило эффективность.
Когда я сделал переход с классического ASP/VBScript на C#, я заметил ОГРОМНОЕ увеличение производительности благодаря ООП.
ООП - это создание экземпляров... вы хотите снова и снова повторять одно и то же, с несколько иной классификацией его деятельности. Совместная деятельность означает общий класс.
Если вы не хотите так думать, не делайте ООП. это определенно искажает разум, чтобы начать думать об этом после, скажем, паскаля, отсюда раздраженные программисты.
Вы детализируете своего экземпляра робота до последней черты, и вы не повторяете себя один раз.
У вас есть только 1 ярлык / класс для каждой разницы в классификации (не для каждой другой вещи!), Это сила ООП... и это похоже на некоторую сверхъестественную сеть для ai, в которой никогда не заканчиваются имена для разных вещей, потому что он опирается на общее распределение, чтобы назвать его.
-Магнус В.
Я согласен с InSciTek Джефф. Даже если вы не используете ОО в чистом виде, теория инкапсуляции может помочь уменьшить потенциальную структурную сложность: http://www.edmundkirwan.com/
@ DrPizza
Если процедурное программирование использует преимущества инкапсуляции в той же степени, то это хорошо!
Реальный мир не может быть ОО, но люди склонны учиться или думать лучше по аналогии (абстракция), а не по логике.
ООП не для компьютера, но для программиста, который плохо разбирается в сложной системе без аналогии. Я считаю, что основной целью ООП является лучшая организация кода с использованием абстракции, поэтому без знания других частей программист может легко понять, что делает конкретная часть или целая система на том уровне, на котором она / он хочет быть.
Чтобы организовать код с помощью абстракции, вам также понадобятся инкапсуляция, наследование и полиморфизм в вашем языке. И принципы SOLID OOP и шаблоны проектирования помогают лучше работать в этой организации. Но я думаю, что весь смысл ООП - это абстракция, потому что таким образом человек мыслит лучше.