Чи OO-програмування дійсно так важливо, як наймають компанії? [зачинено]

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

Чи справді ОО є таким вирішальним? У мене навіть було співбесіду для роботи з програмування в C, а половина інтерв'ю була ОО.

У реальному світі, розробляючи реальні додатки, майже завжди використовується орієнтація на об'єкти? Чи використовуються ключові риси, такі як поліморфізм, ЛІТ?

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

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

Цього короткого періоду недостатньо для того, щоб зробити мету ООП зрозумілою, особливо якщо люди в проекті є початківцями. Але дотримання деякого моделювання має вирішальне значення для великих проектів, я б сказав> 50 000 рядків коду. OOP - не єдине рішення для цього, але це найбільш широко використовується в галузі.

Ось чому люди хочуть, щоб ви знали OOP.

Доречно, я зазначив, що майже всі молодші програмісти мають серйозні вади в моделюванні та OOP. Більшість з них знає, як писати заняття, успадковувати від них і такі основні речі, але вони не думають в "OOP" і в кінцевому підсумку зловживають цим. Ось чому будь-який серйозний рекрутер завжди буде виглядати, якими є ваші компетенції у сфері OOP.

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

Якщо ви ще не вважаєте "OOP", я б запропонував вам прочитати кілька книг про це і подати заявку в компанію, яка не має насправді великих проектів; звикнути до OOP, продовжуючи робити корисну роботу для свого роботодавця (і поки він / вона видасть вам вашу зарплату, це буде корисно і для вас).

EDIT: ha, і я додам, що я вже написав OOP-код на C, навіть якщо це не найпоширеніше використання C, це можливо з глибокими знаннями. Вам просто потрібно створити vtables вручну.

А за технікою OOP ховається щось: розробка програмного забезпечення. Дизайн програмного забезпечення справді корисний для C, як і для будь-яких інших мов. Багато рекрутерів перевірять ваші компетенції щодо розробки програмного забезпечення, і питання про ООП добре для цього, але OOP - це не головне, що тут перевіряється. Ось чому у вас є ці питання навіть для роботи на C.

Основна проблема комп’ютерного програмування полягає у складності управління, а сучасні програми справді можуть бути дуже складними, і це, здається, лише збільшується.

Значна частина роботи, проведеної в інженерії програмного забезпечення нетривіальних комп'ютерних програм, зосереджується на складності приручення і робить її доступною для якомога більшої кількості, не приділяючи спочатку життя навчанню.

Приклади:

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

Іншими словами, знати багато хитрощів необхідно, якщо ви хочете працювати над нетривіальними фрагментами програмного забезпечення, самостійно або (швидше за все) з іншими.

Так, насамперед тому, що, можливо, дві найпопулярніші платформи розвитку, що використовуються в комерційній розробці (Java та .NET), орієнтовані на об'єкт, і це означає, що OO використовується дуже багато (включаючи поліморфізм, успадкування та все інше).

Компанії особливо не переймаються орієнтацією на об'єкт як технологією - це не ідеологія, вони піклуються про людей, які можуть розробляти рішення своїх проблем способами, які відповідають їх ІТ-стратегії.

Але я б не переймався надто сильним почуттям слабкості. Не зважаючи на вашу освіту, більшість людей комерційного світу не бачать програмістів, які залишають університет (на будь-якому рівні), як закінчену статтю. У вас ще багато залишається вчитися, і це зрозуміло (можливо, компанії краще, ніж студентам).

Як і в реальному, програмування реального життя відрізняється від теоретичної.

Так, якщо ви зберігаєте відполіровану парадигму OO і завжди залишаєтеся в курсі душі, ви можете краще писати код, керований, зрозумілий і легко розширюваний.

На жаль, у реального світу є таке:

• тиск в часі проекту
• процедурно орієнтовані члени команди
• перехресно розташовані команди, декілька постачальників
• застарілий код не має жодної орієнтації
• доки це працює, кілька дбає про те, як пишеться код
• навіть якщо код не працює, мотивація - це виправити, а не "OO"
• модулі, обмеження платформи, рамки, які просто не дозволяють робити хороший ОО

У реальній роботі ви повинні працювати з вищезазначеними питаннями. Це звучить деморалізуючим. Але ставитесь до цього як до голови. Наймаючі компанії надають занадто велике значення OO під час найму. Неважко зрозуміти, чому. Єдиний спосіб, коли вони можуть перевірити кандидата, - це запитання про розуміння ОО. І на жаль, багато кандидатів просто вирішують ці питання, перш ніж звертатися на співбесіду.

OO в реальному житті відбувається повільно. Це допомагає, якщо ви продовжуєте читати і продовжуєте його вдосконалювати з часом.

У мене були такі ж почуття, коли закінчую ступінь бакалавра, і чудова книга, яка показала мені, чому і наскільки OOP є актуальною для реальних програм, - це Head First: Шаблони дизайну . Я щиро рекомендую вам заглянути, це написано по-справжньому цікавим чином і дає багато вагомих моментів, чому OOP-підхід є бажаним при роботі з масштабними системами, що постійно змінюються.

Навіть для деяких завдань в 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), орієнтовані на об'єкт, і це означає, що OO використовується дуже багато (включаючи поліморфізм, успадкування та все інше).

Що майже все, що я збирався сказати, але це не тільки Java і .Net, C ++ є скрізь, Objective-C - по всьому OSX, всі круті діти роблять Ruby або Python, і все це і багато іншого більше мають зосередженість на орієнтації на об'єкти. Багато новіших мов є багатопарадигмою, тому щось на зразок F # є насамперед функціональною мовою, але також підтримує орієнтацію на об'єкти. Він є скрізь, і мати принаймні трохи розуміння дуже корисно. Не переживайте з цього приводу, але закінчивши університетські курси означає, що ви готові почати дізнаватися про розробку коду в реальному світі :)

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

BTW, C ++ зробив величезний і некрасивий безлад OO, тоді як ціль C робить це правильно.

Щодо інтерв'ю, вони стали шоу жахів - з обох боків столу. Більшість опитаних дуже здивовані ними. Більшість менеджерів з найму дивуються тому, що багато людей не справляються навіть з найпростішими тестами програмування.

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

Навчання OOP не так корисно, як навчання розробці програмного забезпечення. Перейдіть до коду 2 .

Звичайно, це корисний інструмент, але сам OOP насправді малий. Загалом, коли компанії та рекрутери говорять про "OOP", вони означають "Розробка програмного забезпечення". Він використовується як загальний термін.

Справжні рекрутери скажуть різницю між вами, як знати, як розробити програмне забезпечення та відповідати прапорець "Має 3 роки в" OOP ".

Відповідь - так, як відзначили кілька інших.

Але, якщо ви хочете попрацювати над кодами процедурного коду спагетті, що не є OO, ви можете це знайти і там. Я думаю, ви віддасте перевагу роботі OO.

EDIT: Пробачте мій випадок цинізму зброї та почуття гумору. Як сказав Райнос, те, що щось є OO, не означає, що це добре. Правильне застосування ОО вимагає реальної роботи та думки; просто наявність його примірників не означає, що додаток добре зроблено. І навпаки, я впевнений, що там добре написаний процесуальний кодекс. Мій досвід роботи в корпоративних ІТ-магазинах протягом 90-х та 2000-х років полягав у тому, що було написано багато поганого коду та, мабуть, існує. Але ближче до питання ОП я помітив, що розумніші розробники, коли їм надається шанс, переходять до більшої кількості систем OO.

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

Як тільки ви отримаєте повісити його, ви ніколи не захочете обійтися без нього. Я не пурист, коли йдеться про капсулювання, візерунки, рамки чи інше. На роботі вам доведеться адаптуватися до різних поглядів та концепцій. Я перелічу кілька попередніх власних досвіду роботи:

В одній компанії мої колеги хотіли якомога більше лінивого завантаження (порожні конструктори, об'ємні властивості, яким довелося всюди перевіряти нульові значення). Вони будували веб-серверні об’єкти, які прожили коротке життя.

Наступна робота була зовсім протилежною. Об'єкти мешкали всередині настільного (на основі Excel) програми. Якнайбільше ініціалізації повинно бути в конструкторі (або одна з багатьох перевантажень конструктора). Порожні конструктори не були дозволені, оскільки порожні об'єкти не мали права існування (що зробило наполегливість досить складним завданням). Крім того, мені довелося адаптувати їхні "стилі кодування" (де відкрити дужки, додати пробіли після коментарів тощо ...), оскільки мій код не міг зареєструватися, якби він не потрапив через style-cop.

В даний час я працюю в компанії, де ніхто з розробників ніколи не намагався зрозуміти ОО. Важко виразити, наскільки надзвичайно фрустративно це було. Мені довелося вдосконалити свої навички Grep, адже у мене є макрос HotScripts, призначений моєму клавішу F12, щоб зробити греп для вибраного тексту. Я шкодую інших розчарувань ...

Отримавши навички OO, ви майже не будете алергічні на спагетті! Однак у всіх випадках, OO - чи ні, будьте терплячі та адаптуйтеся. Будьте неохоче "викиньте його і почніть спочатку". Ваш начальник скоріше обере вас, коли йдеться про викидання. На жаль, "робити моні" важливіше елегантного коду.

Вибачте за довгу відповідь, але я намагався охопити більшу частину сфери вашого питання :-)

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

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

Ці "інженерні концепції" намагалися втримати в розробці програмного забезпечення з того часу, коли сам програмний продукт став більшим, ніж "єдиний потенціал розробника", таким чином, потрібен спосіб змусити розробників працювати над незалежними фрагментами, і дозволити цим фрагментам взаємодіють разом.

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

OOP - це просто успішна спроба об'єднати ці речі, даючи цим загальним термінам (як модулі, інкапсуляція, підміна) більш точні визначення та детальну концептуалізацію тих визначень (шаблонів), які можуть вписатися в мови програмування.

Розгляньте спочатку OOP не як " мовну особливість ", а як " загальну лексику ", яка змушує інженерів-программістів підійти до розробки програмного забезпечення.

Те, що в даній мові є чи ні примітиви, які безпосередньо застосовують цю лексику, забезпечуючи, наприклад, що "капсула" не відкривається ненавмисно тим, хто цього не повинен робити, є вторинним аспектом розробки OOP. Ось чому навіть великий проект C часто "управляється" як "OOP", навіть якщо сама мова не пропонує прямої підтримки для цього.

Перевага всього того, що не впізнається, поки розмір проекту не перешкоджає єдиному розробнику в розумінні та відслідковуванні всього, що він робить (адже в таких ситуаціях це може бути сприйнято навіть як «накладні витрати») або в невелику групу, яка щось розвиває в короткий період. І це головна причина, коли юніори, які вивчали ООП у терміні "мовної особливості", часто неправильно трактують його, створюючи неправильно розроблений код.

Те, як OOP вписується в мови, залежить від того, як мовні дизайнери інтерпретують принцип ООП у власній конструкції.

Отже, "інкапсуляція" в C ++ стає "приватними членами" (а "капсула" стає класом), "підміна" стає віртуальними функціями, які замінюють параметризацію / спеціалізацію шаблону тощо, тоді як у D капсула - "модуль" (і заміна йде через класи тощо), роблячи таким чином певну парадигму чи візерунок безпосередньо доступною на даній мові, а не на іншій тощо.

Те, що рекрутери прагнуть задати питання щодо OOP, - це просто перевірити вашу здатність до абстрактного та придуманого дизайну програмного забезпечення для майбутніх великих проектів та розробок. OOP, для них це лише "словник", який вони, як ви думаєте, знаєте і ви, і вони знаєте, щоб ви могли поговорити про інші більш загальні речі або конкретизувати певну реалізацію.

Об'єктно-орієнтована мова допомагає зберегти в коді об'єктно-орієнтований дизайн, що добре. Але також правда, що такий дизайн можна отримати з будь-якою іншою мовою парадигми: причина популярності (особливо серед компаній) OO-мов полягає, ймовірно, у комерційному успіху java та c #.

Якби містер Гейтс почав свою компанію правильним шляхом, ми, ймовірно, вивчали СХЕМУ, перш ніж подавати заявку на роботу.

Коротка відповідь - так

Більш довга версія, чому ви вважаєте, або ви перебуваєте перед дилемою, чому її важливо лише через те, що ви не працювали над жодними проектами чи реалізаціями, які слугують певній меті. Його ідеально підходить в аудиторіях, щоб мати приклади на Automobile, а потім поширити на автомобілі, вантажні автомобілі ... але коли ви переходите до розробки програмного забезпечення, це рішення, спрямоване на полегшення деяких завдань. Якщо б цього не було, у OOнас би всі писали подібні коди через кодову базу абовинаходити колеса щодня. Уявіть, який би це безлад, якби зануритися в таку базу коду, щоб щось виправити. Приклади в класі - це розпливчасте визначення або подання про те, як / чому це робиться. Справжнє випробування виходить, коли ви починаєте створювати додаток, без сумніву, оскільки все це може бути жахливо використане, але воно значно важить розумність завдяки чіткому та стислому використанню. Тож краще почати працювати над цією слабкою областю, щонайменше ви не будете виконувати коди кошмарів.

Це залежить. Однією з причин ви повинні знати ОО, оскільки це lingua franca світу програмування. Як вказується інша відповідь, майже кожна основна мова певним чином є ОО, а це означає, що в основному будь-яка компанія, яка може вас найняти, використовує мову ОО. Ви намагалися найняти програмістів OCaml? Це неможливо; пул талантів занадто малий. Якщо ви створили свою компанію за допомогою OCaml, і ваша компанія стане успішною, ви не зможете найняти програмістів досить швидко, і ви перестанете працювати. Тому майже кожна компанія з більш ніж 3-ма програмістами використовує мову ОО, і для того, щоб спілкуватися зі своїми колегами та використовувати бібліотеки вашої платформи, вам потрібно мати розуміння ОО.

Залежно від конкретної мови, якою користується компанія, успадкування та поліморфізм є надзвичайно важливими або просто помірно актуальними. У Java нічого не можна зробити, не вибухнувши 10 моделей дизайну GoF та рамки введення залежності. Java - одна з найпоширеніших мов, тому принципи ОО є дійсно важливими для багатьох компаній, що використовують Java.

Якщо компанія використовує сучасний гібридний OO / функціональну мову, який має лямбди та функціональні вказівники, як Scala або C #, то успадкування раптом стає менш важливим, оскільки у вас є функції вищого порядку для обробки багатьох дійсно простих речей, які в іншому випадку вимагають багато церемонія. Однак ви все ще повинні мати можливість працювати з матеріалами OO, оскільки більшість бібліотек, які ви використовуєте, будуть написані у вигляді OO.

Якщо успадкування та поліморфізм не є важливими для компанії, ви все одно можете отримати питання OO через:

• З вами беруть участь співбесідники з персоналу, який нічого не знає про програмування і не задає питань із контрольного списку. У вас 3 роки X, чи багатозадачність і т.д.
• З вами опитується інженер, який хоче переконатися, що ви не жили під скелею. OO - це lingua franca, тому вам будуть задані побічні запитання щодо цього.
• Вас беруть інтерв'ю з інженером, який не дуже вмілий в інтерв'ю. Загалом, інженери люблять дрібниці та складність, тому у вас виникне багато питань щодо поліморфізму, успадкування та моделей дизайну GoF лише тому, що ці речі цікаві особі, яка опитує вас.

Словом "Так".

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