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

55

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

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

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

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

эля
источник
3
Однако еще не все потеряно. Признать, что есть проблема, является первым шагом к ее исправлению :)
пожрал элизиум
37
Мне потребовалось несколько лет, чтобы понять, ПОЧЕМУ именно ОО является полезной концепцией. Я мог понять все технические детали, но не смог найти ничего полезного. Я полагаю, что многое из глупых примеров, которые мне показали, показывают, что собаки, расширяющие млекопитающих, расширяют животных ... Что открыло мне глаза, так это взгляд на паттерны ОО-дизайна, особенно паттерны Listener (aka Observer) и Strategy
Mchl
1
Да, это. Честно.
Quant_dev
6
Смотрите ответ Турбьёрна Равна Андерсена. Чтобы быть хорошим программистом, вам нужно знать модульность и дизайн API. Не все программисты в отрасли хороши, но большинство используют ООП. К сожалению, сочетание ООП и немодульного кода и плохих API приводит к некачественному программному обеспечению, и вы увидите много такого кода на работе. Если вы не пишете много кода в свободное время, вы, вероятно, мало что знаете о "реальной" ООП. Это нормально, вы не одиноки в этом положении.
Джох
1
Хо да, он может. И поверьте мне, если у вас такое же понимание ООП, которое у вас было, когда вы получили степень магистра, то вы, вероятно, ничего не знаете об ООП.
Deadalnix

Ответы:

84

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

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

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

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

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

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

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

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

deadalnix
источник
2
И да .. как я писал в предыдущем комментарии, я думаю, что мне нужно работать над большим проектом, чтобы оценить ООП :).
Эль
5
Вам не нужны vtables, чтобы быть ООП. просто используя structи функции, которые работают над этой структурой в C - это ООП.
edA-qa mort-ora-y
2
Структура @ edA-qa mort-ora-y не дает вам функциональности ООП. Полиморфизм? Наследование? Это что-то значит для вас? Итак, как вы реализуете виртуальные функции без vtable?
Deadalnix
2
@deadalnix: вы реализуете их так же, как .NET и Java выполняют множественное наследование. Вы должны знать, что первые компиляторы C ++ вообще не были компиляторами, они были трансляторами, которые взяли код C ++ и превратили его в код C, который был передан компилятору C. Google "CFront".
gbjbaanb
3
Java и; NET не делают множественное наследование. И да, C ++ автоматически переводится в C, но это совершенно не связано с проблемой использования vtable или нет. На самом деле вы должны: вы не можете реализовать виртуальные функции без vtable.
Deadalnix
38

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

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

Примеры:

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

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

оборота user1249
источник
7
Мне нравится, что вы сделали разницу между модульностью, API и ОО. Я думаю, что в индустрии программного обеспечения широко распространено заблуждение, что ОО означает все эти вещи.
Джо
3
Даже зная, что само ОО не является жестким требованием, в определенных областях достаточно процедурных и функциональных парадигм (C или Haskell). Вам все еще нужно изучить модульность и дизайн API.
Райнос
@Raynos, в C у вас есть указатели на функции, которые позволяют явно делать то, что OO делает по сути. Точно так же Haskell использует сопоставление с образцом, чтобы явно делать то, что делает компилятор, например, в Java.
@ThorbjornRavnAndersen это небольшая ниша для написания OO style C и Haskell. Я просто говорю, что повторное использование кода может быть сделано в процедурной и функциональной парадигме.
Райнос
3
@mathepic Я не говорю, что нужно писать OO haskell (или существует ли он вообще). Я говорил, что тебе не нужно знать ОО. Есть и другие способы справиться со сложностью (FP)
Райнос
14

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

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

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

Джон Хопкинс
источник
2
Приходится звонить вам о компаниях, «не заботящихся» об ОО - хорошие компании заботятся о многоразовых / поддерживаемых кодовых базах, и шаблоны ОО являются признанным способом сделать это.
HorusKol
1
@HorusKol - Да, но несмотря на это, Perl, Cobol и Visual Basic были коммерчески успешными, а Smalltalk - нет. Вы подходите компаниям, которым нравится обслуживаемый код, но это не является абсолютным требованием, они будут сопоставлять его с другими факторами.
Джон Хопкинс
Ну, Кобол был около ОО. Я не могу комментировать Smalltalk, но я предполагаю, что, возможно, были проблемы с ним, если он не был поднят.
HorusKol
1
@HorusKol - На самом деле Cobol и OO появились примерно в одно и то же время (в конце 50-х годов), но даже если мы предположим, что OO на самом деле не начали распространяться до 70-х или даже 80-х годов (если вы ждете C ++), если это ТАК большая сделка для компаний, почему она не завоевала популярность до конца 90-х годов (с Java). Ответ заключается в том, что существуют и другие способы обеспечения поддерживаемой кодовой базы, кроме ОО - компании заботятся о поддерживаемом коде, но существует более одного способа защитить кошку, и ОО - не единственное решение.
Джон Хопкинс
Странно называть сами платформы платформой OO. Clojure не ОО. Я предполагаю, что в Scala есть несколько ОО-элементов, но лучше всего их использовать функционально. F # отчасти то же самое. писать ОО-код на F # просто грязно.
Сара
7

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

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

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

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

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

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

Amol
источник
6

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

Дэвид Хаас
источник
Рад, что я не единственный! Спасибо .. Я посмотрю на эту книгу :).
эль
6

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

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

Кен Блум
источник
4

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

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

-findBestMove
-makeBestMove
-waitForPlayerInput

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

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

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

Alex
источник
4

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

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

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

eviltobz
источник
3

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

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

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

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

Понк
источник
C ++ является мультипарадигмальным языком, но хорошо обрабатывает OO .. нет?
Никко
1
Я бы сказал, что C ++ дает вам возможность создавать ужасный беспорядок. Если все сделано правильно, его красота заключается в его простоте.
Мартин Йорк
Пропуск основ всегда дает огромный беспорядок. C ++ просто имеет большое количество основ, которые вам нужно понять. Вот почему можно использовать C ++ для больших программ. Это необходимо.
tp1
@Ponk: Кстати, C ++ сделал огромный и ужасный беспорядок OO, в то время как Objective C делает это правильно. - Я не пробовал Цель C, поэтому у меня нет оснований сомневаться в вас, но где я могу найти более тщательный и убедительный аргумент для этого?
Джим Г.
3

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

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

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

Raynos
источник
Да, в этом контексте ООП аналогичен GUI, так как «вам необходим 5-летний опыт работы с GUI для этой роли».
gbjbaanb
1

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

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

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

Бернард Ди
источник
3
-1 для обозначения не-OO-кода - это спагетти. и что ОО делает хорошее "не спагетти" черной магией.
Райнос
@Raynos Это справедливо. И только то, что что-то не использует ОО, не означает, что это плохо. Я буду редактировать.
Бернард Ди
Это также не только процедурный против процедурного / ООП, есть также функциональные парадигмы.
альтернатива
Я работал над необслуживаемыми ОО-приложениями, где объекты разбросаны, как конфетти. ООП - это не волшебная палочка, это просто более определенный способ организации вашего кода.
gbjbaanb
2
Да, да, тысячу раз да! Пожалуйста, смотрите редактирование. Мой комментарий на самом деле был скорее бредом в многочисленных случаях плохого унаследованного кода, над которым я имел удовольствие работать, чем в какой-то особенной процедурной или OO. Но если бы у меня был выбор, я бы предпочел работать с хорошо разработанной ОО-системой, а не с хорошо разработанной процедурной системой; и хорошо спроектированная система по сравнению с плохо спроектированной в любой день.
Бернард Ди
1

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

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

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

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

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

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

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

Луи Сомерс
источник
Большое спасибо за ваши истории. Мне понравилось их читать! В настоящее время я работаю над проектом C ++ и использую эту возможность, чтобы подумать о возможных способах использования ОО-технологий. Сейчас все идет хорошо :). +1 за твой ответ. Спасибо.
Эль
1

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

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

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

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

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

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

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

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

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

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

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

Эмилио Гаравалья
источник
0

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

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

Лоренцо Стелла
источник
Схема появилась в том же году, что и Microsoft (хотя до этого были и другие LISP). Кроме того, Java и C # во многом обязаны своим успехом Alan Kay, в частности Smalltalk и Simula, а также успеху C ++.
JasonTrue
0

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

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

V4Vendetta
источник
0

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

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

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

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

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

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

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

Бинарный Беспорядок
источник