Действительно ли ОО-программирование так же важно, как это делают компании по найму? [закрыто]

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

ОО действительно так важно? У меня даже было собеседование на работу по программированию в Си, и половина интервью была ОО.

В реальном мире, при разработке реальных приложений, объектная ориентация почти всегда используется? Используются ли такие ключевые черты, как полиморфизм, МНОГО?

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

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

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

Вот почему люди хотят, чтобы вы знали ООП.

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

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

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

РЕДАКТИРОВАТЬ: ха, и я хотел бы добавить, что я уже написал код ООП на C, даже если это не самое распространенное использование C, это возможно с глубоким знанием. Вам просто нужно собрать vtables вручную.

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

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

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

Примеры:

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

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

Да, в первую очередь потому, что, возможно, две наиболее популярные платформы разработки, используемые в коммерческой разработке (Java и .NET), являются объектно-ориентированными, и это означает, что да, ОО часто используется (включая полиморфизм, наследование и все остальное).

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

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

Как и в реальной жизни, реальное программирование отличается от теоретического.

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

К сожалению, в реальном мире есть это:

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

В реальной работе вы должны работать с вышеуказанными проблемами. Это звучит деморализующе. Но, относитесь к этому как к руководству. Наемные компании при найме придают слишком большое значение OO. Легко понять почему. Единственный способ, которым они могут проверить кандидата, это спросить о понимании ОО. И, к сожалению, многие кандидаты просто уточняют эти вопросы, прежде чем явиться на собеседование.

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

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

Даже для некоторых работ в C вам может понадобиться знание объектно-ориентированного проектирования (и, вероятно, лучше, чем если бы ваш компилятор сделал это за вас), о чем свидетельствует недавняя серия статей об объектно-ориентированном проектировании в ядре Linux. ( Часть 1 , часть 2 )

GTK + также использует множество шаблонов объектно-ориентированного проектирования.

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

Чтобы дать мой ответ в виде аналогии, генералу нужны объекты, солдату нужны процедурные. Как только вы достаточно углубились в OO, вы найдете процедуры, и если это ваш опыт и вы достаточно хороши, не беспокойтесь о OO, потому что для кого-то достаточно просто написать этот код для игры в OO:

-findBestMove
-makeBestMove
-waitForPlayerInput

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

foreach $move (@moves){
    $bestMove = ($move > $bestMove ? $move : $bestMove)
}
return $bestMove

С другой стороны, если вы не знаете, как читать код OO, беспокойтесь. Потому что вы можете быть уверены (почти), что ваш код будет портиться с какими-то объектами. Если вы не работаете над наследием Fortran, состоящим из 12000 глобальных переменных и 1200 линейных «модулей», которые я сейчас поддерживаю.

Джон Хопкинс писал:

Да, в первую очередь потому, что, возможно, две наиболее популярные платформы разработки, используемые в коммерческой разработке (Java и .NET), являются объектно-ориентированными, и это означает, что да, ОО часто используется (включая полиморфизм, наследование и все остальное).

Это в значительной степени то, что я собирался сказать, но это не только Java и .Net, C ++ везде, Objective-C повсюду в OSX, все классные ребята делают Ruby или Python, и все эти вещи и многие другие больше сосредоточиться на ориентации объекта. Многие новые языки являются мультипарадигмальными, поэтому что-то вроде F # в основном функциональный язык, но также поддерживает объектную ориентацию. Это везде, и иметь хоть какое-то понимание очень полезно. Не беспокойтесь об этом, только что только что закончившие университетские курсы означает, что вы готовы начать изучать разработку кода в реальном мире :)

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

Кстати, C ++ сделал огромный и ужасный беспорядок OO, тогда как Objective C делает это правильно.

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

Тем не менее, в индустрии программного обеспечения сейчас работают огромные сумки, которые НИЧЕГО не знают и все же ожидают от потенциальных сотрудников мира.

Обучение ООП не так полезно, как обучение разработке программного обеспечения. Читайте код завершения 2 .

Конечно, это полезный инструмент, но сам ООП действительно маленький. В общем, когда компании и рекрутеры говорят «ООП», они имеют в виду «Разработка программного обеспечения». Он используется как общий термин.

Настоящие рекрутеры расскажут вам разницу между тем, как вы знаете, как разрабатывать программное обеспечение, и соответствием отметке «Имеет 3 года в ООП».

Ответ - да, как отметили несколько других.

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

РЕДАКТИРОВАТЬ: простите мой случай цинизма стрелка и чувство юмора. Как сказал Рейнос, просто потому, что что-то есть ОО, не значит, что это хорошо. Правильное применение ОО требует реальной работы и обдумывания; просто наличие его экземпляров не означает, что приложение хорошо сделано. И наоборот, я уверен, что там хорошо написан процедурный код. Мой опыт работы с корпоративными ИТ-магазинами в 90-х и 2000-х годах заключался в том, что много плохого кода написано и, вероятно, все еще существует. Но ближе к вопросу OP, я заметил, что более умные разработчики, когда есть возможность, переходят на большее количество OO-систем.

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

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

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

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

В настоящее время я работаю в компании, где никто из разработчиков никогда не пытался понять ОО. Трудно выразить, насколько это было крайне неприятно. Мне пришлось улучшить свои навыки Grep, на самом деле у меня есть макрос HotScripts, назначенный моей клавише F12, чтобы выполнить grep для выделенного текста. Я избавлю от других разочарований ...

Как только вы приобретете навыки ОО, у вас почти будет аллергия на спагетти! Однако во всех случаях, OO-или нет, будьте терпеливы и адаптироваться. Неохотно "выбросить его и начать все сначала". Ваш босс скорее выберет вас, когда дело доходит до выбрасывания. К сожалению, «делать деньги» важнее элегантного кода.

Извините за длинный ответ, но я постарался охватить большую часть вашего вопроса :-)

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

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

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

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

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

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

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

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

То, как ООП вписывается в языки, зависит от того, как разработчики языка интерпретируют принцип ООП в своей собственной конструкции.

Таким образом, «инкапсуляция» в C ++ становится «закрытыми членами» (а «капсула» становится классом), «подстановка» становится переопределением виртуальных функций или параметризацией / специализацией шаблона и т. Д., Тогда как в D «капсула» является «модулем» (и подстановка идет через классы и т. д.), таким образом, делая определенную парадигму или шаблон непосредственно доступными на данном языке, а не на другом и так далее.

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

Объектно-ориентированный язык помогает вам сохранить объектно-ориентированный дизайн в вашем коде, и это хорошо. Но также верно и то, что такой дизайн можно получить с любым другим языком парадигмы: причина популярности (особенно среди компаний) OO-языков, вероятно, кроется в коммерческом успехе java и c #.

Если бы мистер Гейтс основал свою компанию правильно, мы бы, вероятно, изучали SCHEME, прежде чем подать заявку на работу.

Краткий ответ да

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

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

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

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

Если наследование и полиморфизм не важны для компании, у вас все еще могут возникнуть вопросы по ОО, потому что:

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

Одним словом "да".

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