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

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

• Сокрытие информации и инкапсуляция: Очень важный для любого удобного в сопровождении кода. Может быть сделан, будучи осторожным на любом языке программирования, не требует функций OO, но выполнение его сделает Ваш код немного подобным OO.
• Наследование: существует один домен важного приложения, для которого все они OO is-a-kind-of и содержит-a , отношения являются идеальным соответствием: Графические интерфейсы пользователя. При попытке создать графический интерфейсы пользователя без поддержки языка OO, то Вы закончите тем, что создали подобные OO функции так или иначе, и это более твердо и более подвержено ошибкам без поддержки языка. Поляна (недавно) и X11 Xt (исторически), например.

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

Вы когда-либо создавали использование окна WinAPI?

[еще 115] времена, чем я хочу помнить.

Затем необходимо знать, что Вы определяете класс (RegisterClass), создаете экземпляр его (CreateWindow), назовите виртуальные методы (WndProc) и методы базового класса (DefWindowProc) и так далее. WinAPI даже берет номенклатуру от ООП SmallTalk, называя методы “messages” (сообщения Окна).

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

Дескрипторы не могут быть наследуемыми, но затем, в Java существует финал. Они не испытывают недостаток в классе, они - заполнитель для класса: это - то, что означает слово “handle”. Смотря на архитектуру как MFC или.NET WinForms, сразу очевидно, что за исключением синтаксиса, ничего особенного не отличается от WinAPI.

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

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

В единственном dev ведут блог, я читал, тем, который парня Joel-On-Software-Founder-of-SO, я считал давным-давно, который OO не приводит к увеличениям производительности. Автоматическое управление памятью делает.Круто. Кто может отклонить данные?

я все еще полагаю, что OO к неOO, что программирование с функциями к программированию, все встраивает.

(И я должен знать, поскольку я запустил с GWBasic.), Когда Вы осуществляете рефакторинг код для использования функций, variable2654, становится variable3 из метода, в котором Вы находитесь. Или еще лучше это имеет имя, которое можно понять, и если функция коротка, это звонило value, и это достаточно для полного понимания.

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

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

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

я не думаю, что язык является естественной метафорой также, и при этом я не думаю, что "запахи" Fowler лучше, чем высказывание "этого кода имеет неприятный вкус". Тем не менее я думаю, что OO не о естественных метафорах и людях, которые думают , объекты, просто всплывающие в Вас , в основном упускают суть. Вы определяете объектную вселенную, и лучший объектный результат вселенных в коде, который короче, легче понять, работы лучше или все они (и некоторые критерии я забываю). Я думаю, что люди, которые используют клиентов/домен естественные объекты в качестве программирующих объектов, пропускают питание переопределить вселенную.

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

Некоторые фундаментальные понятия являются действительно классными инструментами

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

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

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

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

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

Относительно Вашего мини-эссе/вопроса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

я думаю использование непрозрачных объектов контекста (ДЕСКРИПТОРЫ в Win32, FILE*s в C, для именования двух известных примеров - черт, ДЕСКРИПТОРЫ живой с другой стороны барьера привилегированного режима, и это действительно не становится намного более инкапсулированным, чем это), найден в процессуальном кодексе также; я изо всех сил пытаюсь видеть, как это - что-то конкретное к ООП.

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

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

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

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

я, с другой стороны, нахожу это полезным, таким образом, я буду :)

Проблема с ООП состоит в том, что это было перепродано.

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

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

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

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

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

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

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

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

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

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

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

ДЕСКРИПТОРЫ (и остальная часть WinAPI) ООП!

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

Вы когда-либо создавали использование окна WinAPI? Затем необходимо знать, что Вы определяете класс (RegisterClass), создаете экземпляр его (CreateWindow), назовите виртуальные методы (WndProc) и методы базового класса (DefWindowProc) и так далее. WinAPI даже берет номенклатуру от ООП SmallTalk, называя методы “messages” (сообщения Окна).

Дескрипторы не могут быть наследуемыми, но затем, существует final в Java. Они не испытывают недостаток в классе, они заполнитель для класса: это - то, что означает слово “handle”. Смотря на архитектуру как MFC или.NET WinForms, сразу очевидно, что за исключением синтаксиса, ничего особенного не отличается от WinAPI.

@Jeff

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

, Который имеет более скрытую реализацию: iostreams C++ или FILE*s C?

я думаю использование непрозрачных объектов контекста (ДЕСКРИПТОРЫ в Win32, FILE*s в C, для именования двух известных примеров - черт, ДЕСКРИПТОРЫ живой с другой стороны барьера привилегированного режима, и это действительно не становится намного более инкапсулированным, чем это), найден в процессуальном кодексе также; я изо всех сил пытаюсь видеть, как это - что-то конкретное к ООП.

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

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

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

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

Возможно, шляпа, полировка или дерево не являются стулом, но они все - ISittable.

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

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

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

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

я думаю, что теми вещами реального мира являются объекты

, Вы делаете?

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

Аналогично другие вещи Вы упоминаете.

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

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

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

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

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

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

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

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

ООП @Konrad

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

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

@Sean

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

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

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

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

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

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

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

@CodingTheWheel

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

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

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

реальным миром не является "OO" и идея, неявная в OO - что мы можем смоделировать, вещи с некоторой таксономией класса - кажется мне, очень существенно испортился

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

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

Я полагаю, что самое выгодное качество ООП является сокрытием/управлением данных. Однако существует МНОГО примеров, где ООП неправильно используется, и я думаю, что это - то, где беспорядок входит.

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

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

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

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

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

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

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

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

"Реальным миром не является "OO"",

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

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

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

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

Встраивающее OO на язык просто дает программисту другое средство выражения.

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