ООП злоупотребляет в университетах?

Ответ 1

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

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

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

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

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

Но OO не является целью. Хороший код - цель. Если процедурный подход работает и никогда не становится сложным, вы выигрываете!

Ответ 2

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

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

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

Ответ 3

ООП - это правильный подход, когда ваши данные могут быть хорошо структурированы в объекты.

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

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

В реальном мире чаще всего ваша проблема может быть ОЧЕНЬ хорошо описана в терминах объектов, хотя закон

Ответ 4

Мои 5 центов:

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

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

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

Ответ 5

• Нет... ООП не всегда лучший подход.

• (Истинный). Дизайн ООП - лучший подход, когда ваша проблема лучше всего смоделирована как набор объектов, которые могут достичь ваших целей, связывая/используя друг друга.

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

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

Ответ 6

Всегда ли OOP правильный подход?

Неа.

Когда лучше всего подходит ООП?

Когда это поможет вам.

Когда ООП является плохим подходом?

Когда это мешает вам.

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

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

Ответ 7

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

Ответ 8

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

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

ООП полезен --- в сочетании с другими подходами.

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

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

Поэтому я предпочитаю думать о функциях. Конечно, эти функции могут работать на объектах, но функции - это те, о которых идет моя программа. И они не должны "принадлежать" к какому-либо определенному классу.

Ответ 9

Как и большинство вопросов такого характера, ответ "это зависит".

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

Ответ 10

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

Ответ 11

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

Ответ 12

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

Обучение навыкам OOA, OOD и OOP принесет пользу большинству программистов, поэтому для университетов, безусловно, полезно научить его.

Ответ 13

Название задает один вопрос, а почта задает другой вопрос. Что вы хотите знать?

ООП - главная парадигма, и она получает большое внимание. Если метапрограммирование станет огромным, оно привлечет больше внимания. Java и С# являются двумя из наиболее часто используемых языков на данный момент (см. Теги SO по количеству использований). Я думаю, что невежественно заявить, что ООП - это великая/страшная парадигма.

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

Ответ 14

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

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

Ответ 15

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

Если мне нужно сделать серьезное планирование, я собираюсь использовать ООП. Если нет, я не буду.

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

Ответ 16

Мое мнение, свободно предлагаемое, стоит столько...

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

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