Какой смысл в ООП?
Насколько я могу судить, несмотря на бесчисленные миллионы или миллиарды, потраченные на обучение, языки и инструменты ООП, ООП не повысила производительность труда разработчиков или надежность программного обеспечения, а также не снизила затраты на разработку. Мало кто использует ООП в каком-либо строгом смысле (мало кто придерживается или понимает такие принципы, как LSP); похоже, что подходы, применяемые к моделированию проблемных областей, мало единообразны или непротиворечивы. Слишком часто класс используется просто для его синтаксического сахара; он помещает функции для типа записи в их собственное маленькое пространство имен.
Я написал большое количество кода для самых разных приложений. Хотя были места, где истинно замещаемый подтип играл важную роль в приложении, они были довольно исключительными. В целом, хотя много говорят на словах о "повторном использовании", реальность такова, что если часть кода не выполняет именно то , что вы хотите, то очень мало рентабельного "повторного использования". Очень трудно спроектировать классы, чтобы их можно было правильно расширять, поэтому стоимость расширения, как правило, настолько велика, что повторное использование просто не стоит.
Во многих отношениях это меня не удивляет. Реальный мир - это не "ОО", и идея ОО, подразумеваемая в ОО - что мы можем моделировать вещи с помощью некоторой классовой таксономии - кажется мне очень фундаментальной ошибкой (я могу сидеть на столе, пне, капоте автомобиля кто-то на коленях - но не один из тех - стул). Даже если мы перейдем к более абстрактным областям, ОО-моделирование часто бывает трудным, нелогичным и, в конечном счете, бесполезным (рассмотрим классические примеры кругов / эллипсов или квадратов / прямоугольников).
Так чего мне здесь не хватает? Где ценность ООП, и почему все время и деньги не смогли сделать программное обеспечение лучше?
45 ответов
Нет эмпирических данных, свидетельствующих о том, что объектная ориентация является более естественным способом для людей думать о мире. Есть некоторые работы в области психологии программирования, которые показывают, что ОО не является более подходящим, чем другие подходы.
Объектно-ориентированные представления не кажутся универсально более удобными или менее пригодными для использования.
Недостаточно просто принять методы ОО и требовать от разработчиков использования таких методов, потому что это может оказать негативное влияние на производительность разработчика, а также на качество разрабатываемых систем.
Который из "О юзабилити OO представлений" от Communications of ACM Oct. 2000. В статьях в основном сравнивается OO с процессно-ориентированным подходом. Существует множество исследований того, как "думают" люди, работающие с методом ОО (Int. J. of Human-Computer Studies 2001, выпуск 54, или Human-Computer Interaction 1995, том 10, имеет целую тему об исследованиях ОО), и из того, что я прочитал, ничто не указывает на некоторую естественность ОО-подхода, который делает его более подходящим, чем более традиционный процедурный подход.
Реальный мир - это не "ОО", и идея ОО, заключающаяся в том, что мы можем моделировать вещи с помощью некоторой классовой таксономии, кажется мне очень фундаментальной ошибкой.
В то время как это верно и было замечено другими людьми (возьмите Степанова, изобретателя STL), остальное - ерунда. ООП может быть ошибочным, и это, конечно, не серебряная пуля, но это делает крупномасштабные приложения намного проще, потому что это отличный способ уменьшить зависимости. Конечно, это верно только для "хорошего" дизайна ООП. Небрежный дизайн не даст никакого преимущества. Но хороший, отделенный дизайн может быть очень хорошо смоделирован с использованием ООП и не очень хорошо с использованием других методов.
Существуют гораздо лучшие, более универсальные модели (на ум приходит модель типа Haskell), но они также часто являются более сложными и / или трудными для эффективного внедрения. ООП - хороший компромисс между крайностями.
ООП не о создании повторно используемых классов, а о создании используемых классов.
Слишком часто класс используется просто для его синтаксического сахара; он помещает функции для типа записи в их собственное маленькое пространство имен.
Да, я нахожу это слишком распространенным. Это не объектно-ориентированное программирование. Это объектно-ориентированное программирование и ориентированное на данные программирование. За 10 лет работы с OO Languages я вижу людей, которые в основном занимаются объектно-ориентированным программированием. OBP ломается очень быстро IMHO, поскольку вы по сути получаете худшее из двух слов: 1) процедурное программирование без соблюдения проверенной методологии структурированного программирования и 2) ООП без соблюдения проверенной методологии ООП.
ООП сделано правильно, это прекрасная вещь. Это делает очень сложные проблемы легкими для решения, и для непосвященных (не пытающихся казаться напыщенными там), это может почти казаться волшебством. При этом ООП является лишь одним из инструментов в наборе методологий программирования. Это еще не конец всей методологии. Это просто хорошо подходит для больших бизнес-приложений.
Большинство разработчиков, которые работают на языках ООП, используют примеры ООП, сделанные прямо в рамках и типах, которые они используют ежедневно, но они просто не знают об этом. Вот несколько очень простых примеров: ADO.NET, Hibernate/NHibernate, Logging Frameworks, различные типы языковых коллекций, стек ASP.NET, стек JSP и т. Д.... Все это в значительной степени зависит от ООП в их кодовых базах.
Повторное использование не должно быть целью ООП - или любой другой парадигмы в этом отношении.
Повторное использование является побочным эффектом хорошего дизайна и надлежащего уровня абстракции. Код достигает повторного использования, делая что-то полезное, но не настолько, чтобы сделать его негибким. Неважно, является ли код ОО или нет - мы повторно используем то, что работает, и нетривиально делать это самим. Это прагматизм.
Мысль об ОО как о новом способе повторного использования посредством наследования в корне ошибочна. Как вы заметили, нарушений LSP предостаточно. Вместо этого ОО должным образом рассматривается как метод управления сложностью проблемной области. Цель - ремонтопригодность системы с течением времени. Основным инструментом для достижения этого является отделение открытого интерфейса от частного внедрения. Это позволяет нам иметь правила типа "Это должно быть изменено только с помощью...", применяемые компилятором, а не проверку кода.
Использование этого, я уверен, вы согласитесь, позволяет нам создавать и поддерживать чрезвычайно сложные системы. В этом есть большая ценность, и это не так просто сделать в других парадигмах.
На грани религиозного, но я бы сказал, что вы рисуете мрачную картину состояния современного ООП. Я бы сказал, что на самом деле это снизило затраты, сделало крупные программные проекты управляемыми и так далее. Это не означает, что это решило фундаментальную проблему программного беспорядка, и это не означает, что средний разработчик - эксперт ООП. Но модульность функций в объектные компоненты, безусловно, сократила количество спагетти-кода в мире.
Я могу подумать о десятках библиотек, которые прекрасно подходят для повторного использования и которые экономят время и деньги, которые никогда не могут быть рассчитаны.
Но в той степени, в которой ООП было пустой тратой времени, я бы сказал, что это связано с отсутствием подготовки программистов, что усугубляется крутой кривой обучения изучению отображения ООП для конкретного языка. Некоторые люди "получают" ООП, а другие никогда не будут.
Я думаю, что использование непрозрачных объектов контекста (HANDLE в Win32, FILE* в C, чтобы назвать два хорошо известных примера - черт, HANDLE живут по другую сторону барьера режима ядра, и это действительно не получает гораздо более инкапсулированный, чем это) также встречается в процедурном коде; Я изо всех сил пытаюсь понять, как это что-то особенное для ООП.
HANDLEs (и остальная часть WinAPI) - ООП! C не очень хорошо поддерживает ООП, поэтому специального синтаксиса нет, но это не значит, что он не использует те же понятия. WinAPI во всех смыслах этого слова - объектно-ориентированная структура.
Понимаете, в этом и заключается проблема с каждым отдельным обсуждением, связанным с ООП или альтернативными методами: никто не знает точно об определении, все говорят о чем-то другом, и, следовательно, консенсус не может быть достигнут. Похоже, трата времени для меня.
Это парадигма программирования. Созданная для того, чтобы нам, простым смертным, было проще разбить проблему на более мелкие, работоспособные части...
Если вы не находите это полезным. Не используйте его, не платите за обучение и будьте счастливы.
Я, с другой стороны, считаю это полезным, так что я буду:)
Относительно прямого процедурного программирования, первый фундаментальный принцип ООП - это понятие сокрытия информации и инкапсуляции. Эта идея приводит к понятию класса, который отделяет интерфейс от реализации. Это чрезвычайно важные концепции и основа для создания основы, позволяющей по-другому и лучше (я думаю) думать о разработке программ. Вы не можете спорить против этих свойств - здесь нет компромисса, и это всегда более чистый способ модулировать вещи.
Другие аспекты ООП, включая наследование и полиморфизм, также важны, но, как уже упоминали другие, они обычно используются чрезмерно. То есть: иногда люди используют наследование и / или полиморфизм, потому что они могут, а не потому, что они должны иметь. Они представляют собой мощные концепции и очень полезны, но их нужно использовать с умом, а не автоматические выигрышные преимущества ООП.
Относительно повторного использования. Я согласен, что повторное использование перепродано для ООП. Это возможный побочный эффект хорошо определенных объектов, обычно более примитивных / универсальных классов, и является прямым результатом концепции инкапсуляции и сокрытия информации. Потенциально легче использовать повторно, потому что интерфейсы четко определенных классов просто более понятны и несколько самодокументированы.
Проблема с ООП заключается в том, что она была перепродана.
По замыслу Алана Кея, это была отличная альтернатива предыдущей практике использования необработанных данных и общеглобальных процедур.
Затем некоторые типы консультантов по менеджменту ухватились за него и продали его как мессию программного обеспечения, и, подобно леммингу, академические круги и промышленность рухнули вслед за ним.
Теперь они похожи на лемминги после того, как другие хорошие идеи были перепроданы, такие как функциональное программирование.
Так что бы я сделал по-другому? Много, и я написал книгу об этом. (Это распечатано - я не получаю ни цента, но вы все равно можете получить копии.) Amazon
Мой конструктивный ответ - смотреть на программирование не как на способ моделирования вещей в реальном мире, а как на способ кодирования требований.
Это сильно отличается и основано на теории информации (на уровне, понятном любому). Это говорит о том, что программирование можно рассматривать как процесс определения языков, и навыки в этом очень важны для хорошего программирования.
Это повышает концепцию предметно-ориентированных языков (DSL). Это решительно согласуется с СУХОЙ (не повторяйте себя). Это дает большие возможности для генерации кода. Это приводит к программному обеспечению с массивно меньшей структурой данных, чем типично для современных приложений.
Он стремится оживить идею о том, что путь вперед лежит в изобретательности, и что даже хорошо принятые идеи должны подвергаться сомнению.
РУЧКИ (и остальная часть WinAPI) - ООП!
Хотя они? Они не наследуются, они, конечно, не заменяемы, им не хватает четко определенных классов... Я думаю, что они далеки от "ООП".
Вы когда-нибудь создавали окно, используя WinAPI? Тогда вы должны знать, что вы определяете класс (RegisterClass), создайте его экземпляр (CreateWindow), вызовите виртуальные методы (WndProc) и методы базового класса (DefWindowProc) и так далее. WinAPI даже берет номенклатуру из ООП SmallTalk, вызывая методы "сообщения" (Window Messages).
Дескрипторы не могут быть наследуемыми, но есть final на Яве. Им не хватает класса, они являются заполнителем для класса: вот что означает слово "ручка". Глядя на такие архитектуры, как MFC или.NET WinForms, сразу видно, что, кроме синтаксиса, ничто не отличается от WinAPI.
Да, ООП не решил всех наших проблем, извините за это. Однако мы работаем над SOA, которая решит все эти проблемы.
В моем опыте анализа кода и разработки проектов, через который я прошел, ценность ООП не полностью осознана, потому что многие разработчики должным образом не концептуализировали объектно-ориентированную модель в своих умах. Таким образом, они не программируют с ОО-дизайном, очень часто продолжают писать нисходящий процедурный код, что делает классы довольно плоскими. (если вы можете даже назвать это "дизайн" в первую очередь)
Довольно страшно наблюдать, как маленькие коллеги знают о том, что такое абстрактный класс или интерфейс, не говоря уже о том, чтобы правильно спроектировать иерархию наследования в соответствии с потребностями бизнеса.
Однако, когда присутствует хороший ОО-дизайн, просто радостно читать код и видеть, что код естественным образом превращается в интуитивные компоненты / классы. Я всегда воспринимал системную архитектуру и дизайн как проектирование различных отделов и рабочих мест в компании - все это для того, чтобы выполнить определенную часть работы в общей схеме вещей, испуская синергию, необходимую для продвижения организации / системы вперед.
Это, к сожалению, довольно редко. Как и соотношение красиво сконструированных и ужасно сконструированных физических объектов в мире, то же самое можно сказать о разработке программного обеспечения и проектировании. Наличие хороших инструментов в своем распоряжении не обязательно означает хорошие практики и результаты.
ООП хорошо подходит для программирования внутренних компьютерных структур, таких как "виджеты" GUI, где, например, SelectList и TextBox могут быть подтипами Item, которые имеют общие методы, такие как "перемещение" и "изменение размера".
Проблема в том, что 90% из нас работают в мире бизнеса, где мы работаем с такими бизнес-концепциями, как Счет, Сотрудник, Работа, Заказ. Они не очень хорошо подходят для ООП, потому что "объекты" более туманные, подверженные изменениям в соответствии с реинжинирингом бизнеса и так далее.
В худшем случае ОО с энтузиазмом применяется к базам данных, включая вопиющие "усовершенствования" ОО к базам данных SQL, которые по праву игнорируются, за исключением тех, кто использует базы данных, которые считают, что они должны быть правильным способом, потому что они новее.
Может быть, капот, колени или дерево не стул, но все они ISittable.
Я думаю, что эти вещи реального мира являются объектами
Ты сделаешь?
Какие методы есть в счете? Ой, подожди. Он не может заплатить сам, он не может отправить себя, он не может сравнивать себя с товарами, которые поставщик фактически поставил. У него нет никаких методов вообще; это абсолютно инертно и не функционально. Это тип записи (структура, если хотите), а не объект.
Точно так же и другие вещи, которые вы упоминаете.
То, что что-то реально, не делает его объектом в ОО-смысле этого слова. ОО-объекты - это своеобразная связь состояния и поведения, которая может действовать самостоятельно. Это не то, что в изобилии в реальном мире.
Во-первых, наблюдения несколько небрежны. У меня нет никаких данных о производительности программного обеспечения, и у меня нет веских оснований полагать, что она не будет расти. Кроме того, поскольку есть много людей, которые злоупотребляют ОО, правильное использование ОО не обязательно приведет к повышению производительности, даже если ОО было величайшей вещью после арахисового масла. В конце концов, некомпетентный мозговой хирург, вероятно, будет хуже, чем никто, но компетентный может быть неоценимым.
При этом ОО - это другой способ организации вещей, прикрепляющий процедурный код к данным вместо того, чтобы процедурный код работал с данными. Это должно быть как минимум небольшая победа сама по себе, поскольку в некоторых случаях ОО-подход более естественен. В конце концов, ничто не мешает писать процедурный API на C++, и поэтому возможность предоставления объектов вместо этого делает язык более универсальным.
Кроме того, есть кое-что, что ОО делает очень хорошо: он позволяет старому коду вызывать новый код автоматически, без изменений. Если у меня есть код, который управляет вещами процедурно, и я добавляю новый тип вещей, который похож, но не идентичен предыдущему, я должен изменить процедурный код. В ОО-системе я наследую функциональность, меняю то, что мне нравится, и новый код автоматически используется из-за полиморфизма. Это увеличивает локальность изменений, и это хорошо.
Недостатком является то, что хороший ОО не является бесплатным: для его правильного изучения требуются время и усилия. Так как это главное модное слово, есть много людей и продуктов, которые делают это плохо, просто ради этого. Нелегко спроектировать хороший интерфейс класса, чем хороший процедурный API, и есть все виды легко совершаемых ошибок (например, глубокая иерархия классов).
Думайте об этом как о другом инструменте, не обязательно лучше вообще. Молоток в дополнение к отвертке, скажем. Возможно, мы в конечном итоге выйдем из практики разработки программного обеспечения как зная, какой ключ использовать, чтобы вбить винт.
Я пишу ОО код за последние 9 лет или около того. Кроме использования сообщений, мне трудно представить другой подход. Основное преимущество, которое я вижу, полностью соответствует тому, что сказал CodingTheWheel: модульность. Естественно, OO побуждает меня создавать свои приложения из модульных компонентов, которые имеют чистые интерфейсы и четкие обязанности (то есть слабосвязанный, очень сплоченный код с четким разделением задач).
Я думаю, что ОО разрушается, когда люди создают глубоко вложенные классовые иерархии. Это может привести к сложности. Однако выделение общей финктальности в базовый класс, а затем повторное использование этого в других классах-потомках - вещь очень элегантная, ИМХО!
@Konrad
ООП может быть ошибочным, и это, конечно, не серебряная пуля, но это делает крупномасштабные приложения намного проще, потому что это отличный способ уменьшить зависимости
Это догма. Я не вижу, что делает ООП значительно лучше в этом отношении, чем процедурное программирование старого. Всякий раз, когда я делаю вызов процедуры, я изолирую себя от специфики реализации.
Для меня в самом синтаксисе ООП есть большая ценность. Использование объектов, которые пытаются представить реальные вещи или структуры данных, часто гораздо полезнее, чем пытаться использовать кучу разных плоских (или "плавающих") функций, чтобы делать то же самое с одними и теми же данными. Существует определенный естественный "поток" к вещам с хорошим ООП, который имеет больше смысла для чтения, записи и поддержания в долгосрочной перспективе.
Не обязательно имеет значение, что Счет-фактура на самом деле не является "объектом" с функциями, которые он может выполнять сам - экземпляр объекта может существовать просто для выполнения функций над данными, не зная, какой тип данных на самом деле существует. Функция "invoice.toJson()" может быть успешно вызвана без необходимости знать, какой тип "счета-фактуры" данных - результатом будет Json, независимо от того, поступит ли он из базы данных, XML, CSV или даже из другого объекта JSON, С процедурными функциями вы внезапно должны знать больше о ваших данных, и в конечном итоге вы получите такие функции, как "xmlToJson()", "csvToJson()", "dbToJson()" и т. Д. ОГРОМНАЯ головная боль, если вы когда-либо измените базовый тип данных.
Смысл ООП состоит в том, чтобы скрыть фактическую реализацию, абстрагируя ее. Для достижения этой цели вы должны создать публичный интерфейс. Чтобы упростить работу при создании этого общедоступного интерфейса и сохранить ее СУХОЙ, вы должны использовать такие понятия, как абстрактные классы, наследование, полиморфизм и шаблоны проектирования.
Поэтому для меня главная цель ООП состоит в том, чтобы облегчить будущее обслуживание кода и внесение изменений. Но даже помимо этого, он может действительно сильно упростить вещи, если все сделано правильно способами, которые процедурный код никогда не сможет. Неважно, не соответствует ли это "реальному миру" - программирование с кодом в любом случае не взаимодействует с объектами реального мира. ООП - это просто инструмент, который делает мою работу проще и быстрее - я пойду на это в любой день.
@Sean
Однако выделение общей финктальности в базовый класс, а затем повторное использование этого в других классах-потомках - вещь очень элегантная, ИМХО!
Но "процедурные" разработчики делали это десятилетиями. Синтаксис и терминология могут отличаться, но эффект идентичен. ООП - это больше, чем "повторное использование общей функциональности в базовом классе", и я мог бы даже пойти так далеко, чтобы сказать, что это вообще трудно описать как ООП; вызов одной и той же функции из разных битов кода - такая же старая техника, как и сама подпроцедура.
@CodingTheWheel
Но в той степени, в которой ООП было пустой тратой времени, я бы сказал, что это связано с отсутствием подготовки программистов, что усугубляется крутой кривой обучения изучению отображения ООП для конкретного языка. Некоторые люди "получают" ООП, а другие никогда не будут.
Я не знаю, если это действительно удивительно, хотя. Я думаю, что технически обоснованные подходы (LSP является очевидной вещью) усложняют использование, но если мы не используем такие подходы, это делает код хрупким и нерасширяемым в любом случае (потому что мы больше не можем рассуждать об этом). И я думаю, что противоречивые результаты, к которым нас приводит ООП, делают неудивительным, что люди не поднимают это.
Что еще более важно, поскольку программное обеспечение уже в принципе слишком сложно для нормальных людей, чтобы писать надежно и точно, должны ли мы превозносить технику, которая последовательно преподается плохо и кажется трудной для изучения? Если бы выгоды были четкими, то, возможно, стоило бы упорствовать, несмотря на трудности, но, похоже, это не так.
@Джефф
Относительно прямого процедурного программирования, первый фундаментальный принцип ООП - это понятие сокрытия информации и инкапсуляции. Эта идея приводит к понятию класса, который отделяет интерфейс от реализации.
Который имеет более скрытую реализацию: iostreams C++ или FILE*s C?
Я думаю, что использование непрозрачных объектов контекста (HANDLE в Win32, FILE* в C, чтобы назвать два хорошо известных примера - черт, HANDLE живут по другую сторону барьера режима ядра, и это действительно не получает гораздо более инкапсулированный, чем это) также встречается в процедурном коде; Я изо всех сил пытаюсь понять, как это что-то особенное для ООП.
Я полагаю, что это может быть отчасти из-за того, что я изо всех сил пытаюсь увидеть преимущества: части, которые явно хороши, не являются специфичными для ООП, тогда как части, которые являются специфическими для ООП, явно не хороши! (это не означает, что они обязательно плохие, скорее, я не видел доказательств того, что они широко применимы и неизменно полезны).
В единственном блоге разработчика, который я прочитал от этого парня из Joel-On-Software-Founder-of-SO, я давно читал, что OO не приводит к увеличению производительности. Автоматическое управление памятью делает. Здорово. Кто может отрицать данные?
Я все еще верю, что ОО - это не ОО, а программирование с помощью функций - это программирование всего встроенного.
(И я должен знать, как я начал с GWBasic.) Когда вы реорганизуете код для использования функций,variable2654 становится variable3 метода, в котором вы находитесь. Или, еще лучше, у него есть имя, которое вы можете понять, и если функция короткая, она называется value и этого достаточно для полного понимания.Когда код без функций становится кодом с методами, вы можете удалить мили кода.
Когда вы реорганизуете код, чтобы быть действительно ОО, b, c, q, а также Z становиться this, this, this а также this, И так как я не верю в использование this ключевое слово, вы можете удалить мили кода. На самом деле, вы можете сделать это, даже если вы используете this,
Я не думаю, что ОО является естественной метафорой.
Я не думаю, что язык является естественной метафорой, и при этом я не думаю, что "запахи" Фаулера лучше, чем сказать "этот код имеет плохой вкус". Тем не менее, я думаю, что ОО не о естественных метафорах, и люди, которые думают, что объекты просто появляются у вас, в основном упускают суть. Вы определяете объектную вселенную, и лучшие объектные юниверсы приводят к тому, что код становится короче, легче для понимания, работает лучше, или все это (и некоторые критерии, которые я забыл). Я думаю, что люди, которые используют природные объекты клиентов / домена в качестве объектов программирования, не имеют возможности переопределить вселенную.Например, когда вы используете систему бронирования авиабилетов, то, что вы называете резервированием, может вообще не соответствовать юридическому / деловому бронированию.
Некоторые из базовых концепций действительно крутые инструменты
Я думаю, что большинство людей преувеличивают с этим целое "когда у тебя молоток, они все гвозди". Я думаю, что другая сторона монеты / зеркала так же верна: когда у вас есть гаджет, такой как полиморфизм / наследование, вы начинаете находить применение там, где он подходит как перчатка / носок / контактная линза. Инструменты ОО очень мощные. Единственное наследование, я думаю, абсолютно необходимо для того, чтобы люди не увлекались, мое собственное программное обеспечение для множественного наследования не выдерживает.Какой смысл в ООП?
Я думаю, что это отличный способ справиться с абсолютно массивной кодовой базой. Я думаю, что он позволяет вам организовывать и реорганизовывать ваш код и дает вам язык для этого (помимо языка программирования, на котором вы работаете) и модульно кодирует код довольно естественным и простым для понимания способом.ООП суждено быть неправильно понятым большинством разработчиков
Это потому, что это процесс, который открывает глаза, как жизнь: вы все больше и больше понимаете ОО с опытом и начинаете избегать определенных шаблонов и нанимать других по мере того, как становитесь мудрее. Одним из лучших примеров является то, что вы перестаете использовать наследование для классов, которые вы не контролируете, и вместо этого предпочитаете шаблон Фасад.Относительно вашего мини-эссе / вопроса
Я хотел сказать, что ты прав. Многоразовость - несбыточная мечта, по большей части. Вот цитата от Андерса Хейлсберга на эту тему (блестящая) отсюда:
Если вы просите начинающих программистов написать элемент управления календаря, они часто думают: "О, я собираюсь написать лучший в мире элемент управления календаря! Он будет полиморфным по отношению к виду календаря. Он будет иметь средства отображения, и мунгеры, и то, и другое. Им нужно отправить заявку на календарь через два месяца. Они поместили всю эту инфраструктуру в систему управления, а затем потратили два дня на написание над ней дрянного приложения-календаря. Они подумают: "В следующей версии приложения я собираюсь сделать намного больше".
Однако, как только они начинают думать о том, как они на самом деле собираются реализовать все эти другие конкретизации своего абстрактного дизайна, оказывается, что их дизайн совершенно неправильный. И теперь они нарисовали себя в углу, и они должны выбросить все это. Я видел это снова и снова. Я твердо верю в минимализм. Если вы на самом деле не собираетесь решать общую проблему, не пытайтесь создать основу для решения конкретной проблемы, потому что вы не знаете, как должна выглядеть эта структура.
Я полностью согласен с ответом InSciTek Jeff, я просто добавлю следующие уточнения:
- Сокрытие информации и инкапсуляция: критически важны для любого поддерживаемого кода. Это можно сделать, проявив осторожность на любом языке программирования, не требуя OO-функций, но это сделает ваш код слегка OO-подобным.
- Наследование. Существует одна важная прикладная область, для которой все эти ОО -типа являются своего рода и содержат- идеально подходят: графические пользовательские интерфейсы. Если вы попытаетесь создать GUI без поддержки языка OO, вы все равно будете создавать OO-подобные функции, и это будет сложнее и более подвержено ошибкам без поддержки языка. Поляна (недавно) и X11 Xt (исторически) например.
Использование OO-функций (особенно глубоко вложенных абстрактных иерархий), когда нет смысла, бессмысленно. Но для некоторых доменов приложений здесь есть смысл.
Вы когда-нибудь создавали окно, используя WinAPI?
Больше раз, чем я хочу вспомнить.
Затем вы должны знать, что вы определяете класс (RegisterClass), создаете его экземпляр (CreateWindow), вызываете виртуальные методы (WndProc) и методы базового класса (DefWindowProc) и так далее. WinAPI даже берет номенклатуру из ООП SmallTalk, вызывая методы "сообщения" (Window Messages).
Тогда вы также узнаете, что он не отправляет сообщения самостоятельно, что является большой зияющей пустотой. У этого также есть дерьмовый подкласс.
Дескрипторы не могут быть наследуемыми, но в Java есть финал. Им не хватает класса, они являются заполнителем для класса: вот что означает слово "ручка". Глядя на такие архитектуры, как MFC или.NET WinForms, сразу видно, что, кроме синтаксиса, ничто не отличается от WinAPI.
Они не наследуются ни по интерфейсу, ни по реализации, минимально заменяемы, и они существенно не отличаются от того, что процедурные кодеры делали с незапамятных времен.
Это действительно так? Лучшие биты ООП - это просто... традиционный процедурный код? Это большое дело?
Я считаю, что наиболее выгодным качеством ООП является скрытие / управление данными. Тем не менее, существует множество примеров, когда ООП используется не по назначению, и я думаю, что именно здесь возникает путаница.
То, что вы можете превратить что-то в объект, не означает, что вы должны это делать Однако, если это сделает ваш код более организованным / более простым для чтения, тогда вам определенно следует это сделать.
Отличный практический пример, где ООП очень полезен, - это класс "product" и объекты, которые я использую на нашем веб-сайте. Поскольку каждая страница является продуктом, а каждый продукт имеет ссылки на другие продукты, может возникнуть путаница в отношении того, к какому продукту относятся ваши данные. Является ли эта переменная "strURL" ссылкой на текущую страницу, или домашнюю страницу, или страницу статистики? Конечно, вы можете создавать различные переменные, которые ссылаются на одну и ту же информацию, но proCurrentPage->strURL гораздо проще понять (для разработчика).
Кроме того, прикрепление функций к этим страницам намного чище. Я могу сделать proCurrentPage->CleanCache(); Вслед за proDisplayItem->RenderPromo(); Если бы я просто вызвал эти функции и предположил, что текущие данные доступны, кто знает, какое зло произойдет. Кроме того, если бы мне пришлось передать правильные переменные в эти функции, я бы вернулся к проблеме наличия всех видов переменных для различных продуктов, лежащих вокруг.
Вместо этого, используя объекты, все данные и функции моего продукта хороши, чисты и просты для понимания.
Тем не мение. Большая проблема с ООП - это когда кто-то считает, что ВСЕ должно быть ООП. Это создает много проблем. У меня есть 88 таблиц в моей базе данных. У меня всего около 6 классов, и, может быть, мне нужно около 10. Мне определенно не нужно 88 классов. В большинстве случаев прямой доступ к этим таблицам вполне понятен в тех обстоятельствах, в которых я его использую, и ООП фактически затруднит / утомителен, чтобы добраться до основной функциональности происходящего.
Я полагаю, что гибридная модель объектов полезна, а процедурная - где практичен, является наиболее эффективным методом кодирования. Обидно, что у нас есть все эти религиозные войны, когда люди выступают за использование одного метода за счет других. Они оба хороши, и у них обоих есть свое место. В большинстве случаев в обоих крупных проектах используются оба метода (в некоторых небольших проектах все, что вам нужно, - это один объект или несколько процедур).
Я не забочусь о повторном использовании столько, сколько я делаю для удобочитаемости. Последнее означает, что ваш код легче изменить. Одно это стоит золота в искусстве создания программного обеспечения.
А ОО - чертовски эффективный способ сделать ваши программы читабельными. Повторное использование или повторное использование.
Это единственная переносимая языком методология для хранения переменных, сгруппированных вместе с функциями / методами / подпрограммами, которые взаимодействуют с ними.
Смысл ООП состоит в том, чтобы дать программисту другое средство для описания и передачи решения проблемы в коде машинам и людям. Самая важная часть этого - общение с людьми. ООП позволяет программисту объявлять, что они означают в коде, с помощью правил, которые применяются на языке ОО.
Вопреки многим аргументам по этой теме, концепции ООП и ОО распространяются на весь код, включая код на языках не-ООП, таких как С. Многие опытные программисты, не-ОО, будут приближать возможности объектов даже на языках, не относящихся к ОО.
Внедрение ОО в язык просто дает программисту другое средство выражения.
Самая большая часть в написании кода - это не общение с машиной, эта часть проста, большая часть - это общение с программистами-людьми.