Какой смысл ООП?

Ответ 1

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

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

Недостаточно просто применять методы OO и требовать от разработчиков использовать такие методы, поскольку это может отрицательно повлиять на производительность разработчиков, а также на качество разработанных систем.

Что из "Об удобстве использования представлений ОО" из сообщений ACM, октябрь 2000 года. Статьи в основном сравнивают OO с ориентированным на процесс подходом. Там много исследований о том, как люди, которые работают с методом ОО "думают" (Int. J. of Human-Computer Studies 2001, issue 54, или Human-Computer Interaction 1995, том 10, имеют целую тему в исследованиях OO), и из того, что я читал, нет ничего, что указывало бы на какую-то естественность подхода к ОО, что делает его более подходящим, чем более традиционный процедурный подход.

Ответ 2

Реальный мир не является "OO", и идея, подразумеваемая в OO, - что мы можем моделировать вещи с помощью некоторой таксономии классов - кажется мне очень фундаментально ошибочной.

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

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

Ответ 3

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

Ответ 4

Слишком часто используется класс просто для его синтаксического сахара; Это ставит функции для типа записи в свое собственное пространство имен.

Да, я считаю, что это слишком распространено. Это не объектно-ориентированное программирование. Это объектно-ориентированное программирование и ориентированное на данные программирование. За 10 лет работы с языками OO я вижу, что люди в основном выполняют объектно-ориентированное программирование. OBP очень быстро ломается ИМХО, так как вы по существу получаете наихудшее из обоих слов: 1) Процессуальное программирование без соблюдения проверенной методологии структурированного программирования и 2) ООП, не придерживаясь доказанной методологии ООП.

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

Большинство разработчиков, которые работают на языках ООП, используют примеры ООП, сделанные правильно в рамках и типах, которые они используют изо дня в день, но они просто не знают об этом. Вот несколько очень простых примеров: ADO.NET, Hibernate/NHibernate, платформы ведения журналов, различные типы набора языков, стек ASP.NET, стек JSP и т.д. Это все, что сильно зависит от ООП в своих кодовых базах.

Ответ 5

Повторное использование не должно быть целью ООП - или любой другой парадигмы в этом отношении.

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

Мысль о ОО как о новом способе повторного использования через наследование в корне ошибочна. Как вы заметили, нарушения LSP изобилуют. Вместо этого OO должным образом рассматривается как метод управления сложностью проблемной области. Целью является обеспечение работоспособности системы с течением времени. Основным инструментом для достижения этого является разделение публичного интерфейса с частной реализацией. Это позволяет нам иметь такие правила, как "Это должно быть изменено с помощью...", принудительно выполняемое компилятором, а не проверка кода.

Используя это, я уверен, вы согласитесь, позволяет нам создавать и поддерживать чрезвычайно сложные системы. В этом есть много ценности, и это нелегко сделать в других парадигмах.

Ответ 6

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

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

Но в той мере, в какой ООП была пустой тратой времени, я бы сказал это из-за отсутствия подготовки программистов, усугубляемой крутой кривой обучения для изучения языкового специфического картографирования ООП. Некоторые люди "получают" ООП, а другие никогда не будут.

Ответ 7

Я думаю, что использование непрозрачных объектов контекста (HANDLEs в Win32, FILE * s в C, чтобы назвать два известных примера - ад, HANDLE живут на другой стороне барьера в режиме ядра, и это действительно так 't получить гораздо больше инкапсулированных, чем это) также содержится в процедурный код; Я изо всех сил пытаюсь понять, как это что-то особенное для ООП.

HANDLE (а остальная часть WinAPI) - ООП! C не очень хорошо поддерживает ООП, поэтому нет специального синтаксиса, но это не значит, что он не использует одни и те же понятия. WinAPI во всех смыслах означает объектно-ориентированную инфраструктуру.

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

Ответ 8

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

Если вы не найдете его полезным. Не используйте его, не платите за обучение и не будете счастливы.

Я, с другой стороны, считаю это полезным, поэтому я:)

Ответ 9

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

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

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

Ответ 10

Проблема с ООП заключается в том, что она перепродана.

Как первоначально предполагал Алан Кей, это была отличная альтернатива предыдущей практике использования необработанных данных и общемировых подпрограмм.

Затем некоторые типы консультантов-консультантов заперли на нем и продали его как мессию программного обеспечения, а лемминг, наука и индустрия упали после него.

Теперь они становятся похожими на лемминг, когда другие хорошие идеи перепроданы, например, функциональное программирование.

Так что бы я сделал по-другому? Много, и я написал книгу об этом. (Это из печати - я не получаю ни цента, но вы все равно можете получить копии.) Amazon

Мой конструктивный ответ - смотреть на программирование не как способ моделирования вещей в реальном мире, а как способ кодирования требований.

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

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

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

Ответ 11

РУЧКИ (и остальная часть WinAPI) - ООП!

Тем не менее, они? Они не наследуются, они, безусловно, не подменяются, им не хватает четко определенных классов... Я думаю, что они значительно отстают от "ООП".

Вы когда-нибудь создавали окно с помощью WinAPI? Затем вы должны знать, что вы определяете класс (RegisterClass), создаете его экземпляр (CreateWindow), вызываете виртуальные методы (WndProc) и методы базового класса (DefWindowProc) и т.д. WinAPI даже берет номенклатуру от SmallTalk OOP, вызывая методы "сообщения" (сообщения Window).

Ручки могут быть не наследуемыми, но затем там final в Java. У них не хватает класса, они являются заполнитель для класса: это то, что означает слово "ручка". Глядя на такие архитектуры, как MFC или .NET WinForms, сразу видно, что, за исключением синтаксиса, ничего не отличается от WinAPI.

Ответ 12

Да ООП не решила всех наших проблем, извините. Мы, однако, работаем над SOA, которая решит все эти проблемы.

Ответ 13

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

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

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

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

Ответ 14

OOP хорошо подходит для программирования внутренних компьютерных структур, таких как "виджеты" графического интерфейса, где, например, SelectList и TextBox могут быть подтипами Item, которые имеют общие методы, такие как "перемещение" и "изменение размера".

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

В худшем случае OO с энтузиазмом применяется к базам данных, включая вопиющие "улучшения" OO для SQL-баз данных, которые по праву игнорируются, за исключением базы данных noob, которые предполагают, что они должны быть правильным способом делать что-то, потому что они новее.

Ответ 15

Может быть, капот, круг или дерево не стул, но все они ISittable.

Ответ 16

Я думаю, что эти вещи в реальном мире - это объекты

Вы делаете?

Какие методы имеет счет? Подожди. Он не может оплатить себя, он не может отправить себя, он не может сравниться с позициями, которые поставщик фактически предоставил. У него вообще нет методов; он полностью инертен и нефункциональен. Это тип записи (структура, если вы предпочитаете), а не объект.

Аналогично тому, что вы упомянули.

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

Ответ 17

Я писал код OO в течение последних 9 лет или около того. Помимо использования обмена сообщениями, мне трудно представить другой подход. Главное преимущество, которое я вижу полностью в соответствии с тем, что CodingTheWheel сказал: модуляция. OO, естественно, приводит меня к созданию моих приложений из модульных компонентов, которые имеют чистые интерфейсы и четкие обязанности (т.е. Слабосвязанный, очень когезионный код с четким разделением проблем).

Я думаю, где OO ломается, когда люди создают глубоко вложенные классовые иерархии. Это может привести к сложности. Однако, разлагая общую фиктивность в базовый класс, повторное использование этого в других классах потомков является очень элегантной вещью, ИМХО!

Ответ 18

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

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

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

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

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

Ответ 19

@Sean

Однако, разлагая общую финментальность в базовый класс, повторное использование этого в других классах потомков является очень элегантной вещью, IMHO!

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

Ответ 20

@Konrad

OOP может быть ошибочным, и это, конечно же, не серебряная пуля, но делает значительно более крупные приложения, потому что это отличный способ уменьшить зависимости

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

Ответ 21

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

Не обязательно, чтобы Счет-фактура не был действительно "объектом" с функциями, которые он может выполнять сам - экземпляр объекта может существовать только для выполнения функций по данным, не зная, какой тип данных фактически там. Функция "invoice.toJson()" может быть вызвана успешно, не зная, какой тип данных "счет-фактура" - результатом будет Json, независимо от того, исходит ли он из базы данных, XML, CSV или даже другого объекта JSON, С процедурными функциями вы все должны знать больше о своих данных и в конечном итоге выполнять такие функции, как "xmlToJson()", "csvToJson()", "dbToJson()" и т.д. В конечном итоге это становится полным беспорядком и ОГРОМНАЯ головная боль, если вы когда-либо измените базовый тип данных.

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

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

Ответ 22

@CodingTheWheel

Но в той мере, в какой ООП была пустой тратой времени, я бы сказал это из-за отсутствия подготовки программистов, усугубляемой крутой кривой обучения для изучения языкового специфического картографирования ООП. Некоторые люди "получают" ООП, а другие никогда не будут.

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

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

Ответ 23

@Jeff

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

Какая более скрытая реализация: С++ iostreams или C FILE * s?

Я думаю, что использование непрозрачных объектов контекста (HANDLEs в Win32, FILE * s в C, чтобы назвать два известных примера - ад, HANDLE живут на другой стороне барьера в режиме ядра, и это действительно так 't получить гораздо больше инкапсулированных, чем это) также содержится в процедурный код; Я изо всех сил пытаюсь понять, как это что-то особенное для ООП.

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

Ответ 24

В единственном блоге Dev, который я прочитал, этим Джоэл-На-Software-Основатель-SO-парень, я давно прочитал, что OO не приводит к увеличению производительности. Автоматическое управление памятью. Круто. Кто может отрицать данные?

Я по-прежнему считаю, что OO не для OO, что программирование с функциями - это программирование всего встроенного.

Когда код без функций становится кодом с методами, вы можете удалить мили кода.

Когда код рефакторинга будет действительно OO, b, c, q и Z станут this, this, this и this. И поскольку я не верю в использование ключевого слова this, вы можете удалить мили кода. Фактически, вы это сделаете, даже если используете this.

Я не думаю, что OO - естественная метафора.

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

Некоторые из основных понятий - это действительно классные инструменты.

Какая точка OOP?

ООП суждено быть недопонятым большинством разработчиков

Что касается вашего мини-эссе/вопроса

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

Если вы попросите начинающих программистов писать календарный контроль, они часто подумайте сами: "О, я собираюсь написать лучший мировой календарь контроль! Это будет полиморфный в отношении вида календаря. У него будут показщики, и плуги, и это, и то, и другое". Они необходимо отправить приложение календаря в два месяца. Они положили все это инфраструктуры в контроль, а затем провести два дня написание сумасшедшего приложения для календаря Сверху. Они подумают: "В следующая версия приложения, я будет делать гораздо больше".

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

Ответ 25

Вы когда-нибудь создавали окно с помощью WinAPI?

Больше раз, чем я помню.

Затем вы должны знать, что вы определяете класс (RegisterClass), создаете его экземпляр (CreateWindow), вызываете виртуальные методы (WndProc) и методы базового класса (DefWindowProc) и т.д. WinAPI даже берет номенклатуру от SmallTalk OOP, вызывая методы "сообщения" (сообщения Window).

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

Ручки не могут быть наследуемыми, но затем, наконец, на Java. У них не хватает класса, они являются заполнитель для класса: это то, что означает слово "ручка". Глядя на такие архитектуры, как MFC или .NET WinForms, сразу видно, что, за исключением синтаксиса, ничего не отличается от WinAPI.

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

Это действительно так? Лучшие бит ООП - это просто... традиционный процедурный код? Это большая сделка?

Ответ 26

Я полностью согласен с ответом InSciTek Jeff, я просто добавлю следующие уточнения:

• Информационное скрытие и инкапсуляция: критический для любого поддерживаемого кода. Это можно сделать, соблюдая осторожность на любом языке программирования, не требуя функций OO, но это сделает ваш код немного похожим на OO.
• Наследование. Существует один важный прикладной домен, для которого все эти OO - это своего рода и содержит - отношения идеально подходят: графические пользовательские интерфейсы. Если вы попытаетесь создать графические интерфейсы без поддержки языка OO, вы все равно закончите создание OO-подобных функций, и это будет сложнее и подвержено ошибкам без языковой поддержки. Glade (недавно) и X11 Xt (исторически), например.

Использование функций OO (особенно глубоко вложенных абстрактных иерархий), когда нет смысла, бессмысленно. Но для некоторых доменов приложений действительно есть точка.

Ответ 27

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

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

Большой практический пример, в котором ООП очень полезен, - это класс продукта и объекты, которые я использую на нашем веб-сайте. Поскольку каждая страница является продуктом, и каждый продукт имеет ссылки на другие продукты, он может очень запутываться в отношении того, к какому продукту относятся данные, на которые вы ссылаетесь. Является ли эта переменная "strURL" ссылкой на текущую страницу или на домашнюю страницу или на страницу статистики? Уверен, что вы можете сделать все виды разных переменных, которые относятся к одной и той же информации, но proCurrentPage- > strURL, гораздо проще понять (для разработчика).

Кроме того, добавление функций к этим страницам намного чище. Я могу сделать proCurrentPage- > CleanCache(); Вслед за proDisplayItem- > RenderPromo(); Если бы я просто назвал эти функции и предположил, что имеющиеся данные доступны, кто знает, какое зло будет происходить. Кроме того, если бы мне пришлось передать правильные переменные в эти функции, я вернусь к проблеме наличия всех видов переменных для разных продуктов, лежащих вокруг.

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

Однако. Большая проблема с ООП заключается в том, что кто-то считает, что ВСЁ должно быть ООП. Это создает массу проблем. У меня есть 88 таблиц в моей базе данных. У меня всего около 6 классов, и, может быть, мне должно быть около 10. Мне определенно не нужно 88 классов. В большинстве случаев прямой доступ к этим таблицам совершенно понятен в тех случаях, когда я его использую, и ООП на самом деле затрудняет/утомительно использовать основные функции происходящего.

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

Ответ 28

Я не забочусь о повторном использовании так же, как и для читаемости. Последнее означает, что ваш код легче изменить. Это само по себе стоит золота в ремесле программного обеспечения для строительства.

И OO - довольно эффективный способ сделать ваши программы доступными для чтения. Повторное использование или повторное использование.

Ответ 29

"Реальный мир не" OO ","

Действительно? Мой мир полон объектов. Сейчас я использую его. Я думаю, что наличие программных "объектов" модели реальных объектов может быть не такой уж плохой.

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

Ответ 30

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

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

Наличие OO, встроенного в язык, просто дает программисту еще одно средство выражения.

Самая большая часть написания кода - это не общение с машиной, эта часть проста, самая большая часть - общение с человеческими программистами.