Мое личное мнение: context

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

Это помогает вам организовать код таким образом, чтобы его было легче понять, потому что реальный мир также объектно-ориентирован.

Это помогает вам организовать код таким образом, чтобы его было легче понять, потому что реальный мир также объектно-ориентирован.

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

Рассмотрим задачу вычисления площадей для произвольной и расширяющейся коллекции фигур. Любой программист может быстро написать функции для площади круга, квадрата, треугольника и т. Д. и храните их в библиотеке. Сложность возникает при попытке написать программу, которая определяет и вычисляет площадь произвольной формы. Каждый раз, когда вы добавляете новую форму, скажем, пятиугольник, вам нужно будет обновить и расширить что-то вроде структуры IF или CASE , чтобы ваша программа могла идентифицировать новую форму и вызывать правильную процедуру области из вашей «библиотеки функций». Через некоторое время затраты на обслуживание, связанные с этим подходом, начинают накапливаться.

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

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

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

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

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

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

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

На мой взгляд, мощь ООП не проявляется, пока вы не начнете говорить о наследовании и полиморфизме.

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

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

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

Полиморфизм очень удобен в случаях, когда Мне нужно добиться определенной функциональности от объекта, но такая же функциональность требуется и от похожих, но уникальных типов. Например, в Qt есть идея вставки элементов в модель, чтобы можно было отображать данные, и вы могли легко поддерживать метаданные для этого объекта. Без полиморфизма мне пришлось бы беспокоиться о гораздо более подробных деталях, чем сейчас (IE мне нужно было бы реализовать те же интерфейсы кода, которые выполняют ту же бизнес-логику, что и элемент, который изначально предназначался для использования в модели). Поскольку базовый класс моего объекта с привязкой к данным изначально взаимодействует с моделью, вместо этого я могу без проблем вставлять метаданные в эту модель. Я получаю от объекта то, что мне нужно, не беспокоясь о том, что нужно модели, и модель получает то, что ей нужно, не заботясь о том, что я добавил в класс.

Больше, чем просто заставить что-то работать - точка зрения вашего друга, хорошо продуманный объектно-ориентированный дизайн легче понять, следовать, расширять, расширять и внедрять. Гораздо проще, например, делегировать работу, которая категорически схожа, или хранить данные, которые должны оставаться вместе (да, даже структура C является объектом).

Примерно в 1994 году я одновременно пытался понять смысл ООП и C ++ и обнаружил, что разочарован, хотя в принципе мог понять, в чем ценность ООП. Я настолько привык иметь возможность вмешиваться в состояние любой части приложения на других языках (в основном, на базовом языке, ассемблере и языках семейства Pascal), что казалось, будто я отказывался от продуктивности в пользу некоторой академической абстракции. К сожалению, мои первые несколько встреч с объектно-ориентированными фреймворками, такими как MFC, упростили взлом, но не обязательно обеспечили многое на пути к просветлению.

Это произошло только благодаря комбинации настойчивости и взаимодействия с альтернативными (не-C ++) способы обращения с объектами, и тщательный анализ объектно-ориентированного кода, который 1) работал и 2) читался более связно и интуитивно, чем эквивалентный процедурный код, который я начал действительно понимать. И 15 лет спустя я регулярно удивляюсь новым (для меня) открытиям умных, но впечатляюще простых объектно-ориентированных решений, которые я не могу себе представить с такой аккуратностью в процедурном подходе.

Я прошел через то же самое. множество попыток разобраться в парадигме функционального программирования за последние пару лет. Перефразируя Пола Грэма, когда вы смотрите вниз на континуум власти, вы видите все, чего не хватает. Когда вы смотрите вверх по континууму власти, вы не видите мощи, вы просто видите странность.

Я думаю, чтобы сделать что-то по-другому, вы должны 1) увидеть, как кто-то, очевидно, более продуктивен с более мощными конструкциями и 2) приостановить недоверие, когда вы столкнетесь с препятствием. Вероятно, будет полезно иметь наставника, который хотя бы немного продвинулся в своем понимании новой парадигмы.

Если вы не хотите, чтобы кто-то быстро оценил ценность объектно-ориентированной модели, если не считать смекалки, необходимой, чтобы приостановить недоверие. , Я думаю, можно было бы сделать намного хуже, чем попросить кого-нибудь провести неделю с книгой прагматичных программистов по Rails. К сожалению, он не учитывает многие детали того, как работает магия, но это довольно хорошее введение в мощь системы объектно-ориентированных абстракций. Если, проработав эту книгу, ваш коллега по какой-то причине все еще не видит ценности объектно-ориентированного подхода, его / ее дело может быть безнадежным. Но если они Если вы готовы потратить немного времени на работу с подходом, который имеет строго самоуверенный объектно-ориентированный дизайн, который работает и выводит их с 0 до 60 гораздо быстрее, чем делать то же самое на процедурном языке, может быть просто надежда. Я думаю, что это правда, даже если ваша работа не связана с веб-разработкой.

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

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

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

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

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

это правда, даже если ваша работа не связана с веб-разработкой.

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

Это правда, даже если ваша работа не связана с веб-разработкой.

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

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

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

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

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

В книге «Inside COM» рассказывается о назначении COM, используя аналогию из детской игры по идентификации животных с помощью вопросов.

Дизайн превосходит технологию и методологию. Хороший дизайн, как правило, включает универсальные принципы управления сложностью, такие как закон деметры, который лежит в основе того, что функции языка OO стремятся кодифицировать.

Хороший дизайн не зависит от использования конкретных языковых функций OO, хотя обычно он в них в интересах их использования.

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

• ООП позволяет лучше инкапсулировать
• ООП позволяет программисту мыслить более логично, упрощая разработку и понимание программных проектов (если они хорошо спроектированы)
• ООП позволяет сэкономить время. Например, посмотрите, что вы можете делать с строковым объектом C ++, векторами и т. Д. Все эти функции (и многое другое) предоставляются «бесплатно». Теперь это действительно особенности библиотек классов, а не само ООП, но почти все реализации ООП идут с хорошими библиотеками классов. Можете ли вы реализовать все это на C (или большей части)? Конечно. Но зачем писать это самому?

Посмотрите на использование шаблонов проектирования, и вы увидите полезность ООП. Дело не только в инкапсуляции и повторном использовании, но и в расширяемости и ремонтопригодности. Именно интерфейсы делают вещи мощными.

Несколько примеров:

• Реализация потока (шаблон декоратора) без объектов затруднена

• Добавление новой операции к существующей системе, такой как новый тип шифрования (шаблон стратегии) может быть сложно без объектов.

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

Список можно продолжить.

Все парадигмы программирования преследуют одну и ту же цель: скрыть ненужную сложность.

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

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

Ваш коллега, кажется, застрял в одной парадигме. Удачи.

Есть много других парадигм . Основные из них (логическое программирование, функциональное программирование и императивное программирование) эквивалентны друг другу; Объектно-ориентированное программирование обычно рассматривается как расширение императивного программирования.

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

Ваш коллега, похоже, застрял в одной парадигме. Удачи.

Есть много других парадигм . Основные из них (логическое программирование, функциональное программирование и императивное программирование) эквивалентны друг другу; объектно-ориентированное программирование обычно рассматривается как расширение императивного программирования.

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

Ваш коллега, кажется, застрял в одной парадигме. Удачи.

Объектно-ориентированное программирование обычно рассматривается как расширение императивного программирования.

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

Ваш коллега, кажется, застрял в одной парадигме. Удачи.

объектно-ориентированное программирование обычно рассматривается как расширение императивного программирования.

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

Ваш коллега, похоже, застрял в одной парадигме. Удачи.

Удачи.

Удачи.

Это не только делает

• программирование более легким / более удобным для обслуживания в текущей ситуации для других людей (и вас самих).
• Это уже упрощает CRUD базы данных (создание, обновление, удаление ) операции.

Вы можете найти дополнительную информацию об этом, посмотрев: - Java: спящий режим - Dot Net: Entity Framework

Посмотрите, как LINQ (Visual Studio) может НАМНОГО упростить вашу жизнь программирования.

• Кроме того, вы можете начать использовать шаблоны проектирования для решения реальных проблем (шаблоны проектирования - это объектно-ориентированный подход)

Возможно, это даже забавно продемонстрировать с помощью небольшой демонстрации:

• Допустим, вам нужно аналогичным образом хранить сотрудников, учетные записи, участников, книги в текстовом файле.

.PS. Я пробовал написать это способом PSEUDO :)

способом OO

Код, который вы вызываете: io.file.save (objectsCollection.ourFunctionForSaving ())

класс objectsCollection

функция ourFunctionForSaving () As String

String _Objects

   for each _Object in objectsCollection
         Objects &= _Object & "-"
   end for

return _Objects end method

NON-OO Way

Я не думаю, что запишу не-oo код. Но подумайте об этом :)

ТЕПЕРЬ ДАВАЙТЕ

ОО. Вышеупомянутый класс является родительским классом для всех методов сохранения книг, сотрудников, членов, учетных записей, ... Что произойдет, если мы захотим изменить способ сохранения в текстовый файл? Например, чтобы сделать его совместимым с текущим стандартом (.CVS).

И допустим, мы хотели бы добавить функцию загрузки, сколько кода вам нужно написать? В OO-способе вам нужно только добавить метод New Sub, который может разделить все данные на параметры (это происходит один раз).

Пусть ваш коллега подумает об этом :)

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

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

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