オブジェクト指向プログラミングは、雇用会社が配置するのと同じくらい重要ですか？[閉まっている]

私はちょうど（コンピューティングの）修士号を取得し、仕事に応募しています。多くの企業がオブジェクト指向の理解を特に求めていることに気付きました。人気のあるインタビューの質問は、継承、ポリモーフィズム、アクセサーなどに関するものです。

オブジェクト指向は本当に重要ですか？私はCでのプログラミングの仕事の面接さえ受けましたが、面接の半分はオブジェクト指向でした。

現実の世界では、実際のアプリケーションの開発において、ほとんど常にオブジェクト指向が使用されていますか？ポリモーフィズムのような主要な機能はLOTを使用していますか？

私の質問は私の弱点の一つから来ていると思います。私はオブジェクト指向について知っていますが、私はそれを私のプログラムに大いに組み込むことができないようです。

OOPは、維持/理解が不可能になることなくプログラムを成長させることができるパラダイムです。これは、学生が2週間からせいぜい2ヶ月まで続く小さなプロジェクトを行うだけなので、ほとんど得られない点です。

この短い期間は、特にプロジェクトの人々が初心者の場合、OOPの目的を明確にするのに十分ではありません。しかし、大規模なプロジェクトでは、モデル化に固執することが非常に重要です。つまり、50,000行を超えるコードです。OOPがそれに対する唯一のソリューションではありませんが、これは業界で最も広く使用されています。

これが、人々があなたにOOPを知って欲しい理由です。

経験から、ほとんどすべてのジュニアプログラマーがモデル化とOOPに重大な欠陥があることを付け加えます。彼らのほとんどは、クラスの書き方、クラスからの継承、およびそのような基本的なものを知っていますが、「OOP」を考えず、クラスを誤用することはありません。これが、真面目なリクルーターがあなたの能力がOOPドメインにあるものを常に見る理由です。

これらのことは学校では学ばないので、異なる候補者の間には知識の非常に大きなバリエーションがあります。正直なところ、OOPの知識が乏しい人が大規模なプロジェクトに取り組むことはできないと思います。単にコードを書くよりもリード開発者がこれらの人々を管理するのに時間がかかるからです。

「OOP」をまだ考えていないなら、それについての本をいくつか読んで、本当に大きなプロジェクトを持っていない会社に応募することをお勧めします。あなたの雇用主のために有用な仕事をし続けるOOPに慣れるために（そして彼/彼女があなたにあなたの給料を与えている限り、これはあなたにとっても役に立つでしょう）。

編集：ハ、そして私はすでにCでOOPコードを書いていることを付け加えます。たとえそれがCの最も一般的な使用法でなくても、これは強力な知識で可能です。vtableを手動で構築する必要があります。

そして、OOPテクニックの背後には、ソフトウェアデザインという隠されたものがあります。ソフトウェア設計は、他の言語と同様にCでも非常に役立ちます。多くの採用担当者がソフトウェア設計能力をテストしますが、OOPの質問はそのために適していますが、OOPはここでテストされている主なものではありません。これが、Cの仕事であってもこれらの質問がある理由です。

コンピュータプログラミングの圧倒的な問題は複雑さの処理であり、最新のプログラムは実際には非常に複雑になる可能性があり、これは増加しているように見えます。

自明ではないコンピュータープログラムのソフトウェアエンジニアリングで行われる作業の多くは、複雑さを抑えることに集中し、学習の生涯を最初に捧げることなく、できるだけ多くの人がアクセスできるようにします。

例：

• モジュール化：コードのモジュールを使用することにより、プログラムを概念的に単純化します。各モジュールは、他のモジュールについて少しだけ知っています（たとえば、ネットワークアイコンバッファーを直接操作できるルーティングを描画するマウスアイコン）。
• API：APIの背後にある複雑なプログラムへの簡単な使用パスを提供します。ファイルを開くとき、ネットワーク共有がUSBディスクとは異なる方法で処理されてもかまいません。APIは同じです。
• オブジェクトの向き。これにより、既存のコードを再利用し、追加する新しいコードで透過的に動作させることができますが、基礎となる複雑さはすべて隠されます。

言い換えれば、重要なソフトウェアを単独で、または他の人と一緒に（たいていの場合）作業したい場合は、多くのトリックを知ることが必要です。

はい、主に商用開発で​​使用される最も人気のある2つの開発プラットフォーム（Javaと.NET）がオブジェクト指向であるため、主にOOが多く使用されます（多態性、継承、その他すべてを含む）。

企業は特にオブジェクト指向をテクノロジーとして気にしません。これはイデオロギーの問題ではありません。IT戦略に沿った方法で問題の解決策を開発できる人を気にします。

しかし、私はそれが弱点だと感じることをあまり心配しません。あなたの教育を軽視しない限り、商業の世界のほとんどの人は、プログラマーが大学を（どのレベルでも）完成した記事として見ることはありません。あなたはまだ学ぶべきことがたくさん残っており、それは理解されています（おそらく学生よりも企業のほうが良いでしょう）。

実生活と同様に、実生活プログラミングは理論とは異なります。

はい、オブジェクト指向のパラダイムを常に磨き続け、心の奥底に置いておけば、管理しやすく、理解しやすく、簡単に拡張可能なコードを書くことができます。

残念ながら、現実の世界にはこれがあります。

• プロジェクト時間のプレッシャー
• 手続き指向のチームメンバー
• クロスロケーションチーム、複数のベンダー
• オリエンテーションのないレガシーコード
• それが機能する限り、コードの記述方法に注意を払う必要があります
• コードが機能しない場合でも、動機は「OO」ではなく修正することです
• モジュール、プラットフォームの制限、フレームワークで、良いOOを実行できない

実際の仕事では、上記の問題に取り組む必要があります。これは意気消沈に聞こえます。しかし、これをヘッズアップとして扱います。雇用会社は、雇用中にオブジェクト指向を非常に重視します。理由は簡単にわかります。彼らが候補者をテストできる唯一の方法は、オブジェクト指向の理解について尋ねることです。そして残念なことに、多くの候補者は、面接に出る前にそれらの質問をブラッシュアップします。

実際のオブジェクト指向は遅くなります。読み続け、時間とともに改善し続けると役立ちます。

学士号を取得したときとまったく同じ感覚でした。また、OOPが実際のアプリケーションに関連する理由と方法を示した素晴らしい本は、Head First：Design Patternsです。覗いてみることを心からお勧めします。とても楽しく書かれており、絶えず変化する大規模システムで作業する場合にOOPアプローチが望ましい理由について多くの正当な点を示しています。

Cの一部のジョブについても、Linuxカーネルのオブジェクト指向設計に関する最近の一連の記事で証明されているように、オブジェクト指向設計を知っておく必要があるかもしれません（そしておそらくコンパイラーがそれを行った場合よりも優れているでしょう）。（パート1、パート2）

GTK +は、多くのオブジェクト指向のデザインパターンも使用します。

私はオブジェクト指向がすべてであるというこの概念に不一致を表明する必要があります-オブジェクト指向を使用すると都市を構築できますが、手続き型プログラムはレンガです。

アナロジーの形で私の答えを出すには、一般的なものはオブジェクトを必要とし、兵士は手続きを必要とします。OOを十分に掘り下げて手順を見つけると、それがあなたの専門知識で十分であれば、OOについて心配する必要はありません。誰かがこのOOチェスゲームコードを書くのは簡単です

-findBestMove
-makeBestMove
-waitForPlayerInput

しかし、だれかが-findBestMoveの背後にあるコードを記述する必要があり、それがこれだけではないことを確認できます。

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

一方、OOコードの読み方がわからない場合は、心配してください。なぜなら、あなたのコードが何らかのオブジェクトを乱していることを（ほぼ）確信できるからです。12000のグローバル変数と1200の行「モジュール」の旧来の巨人に取り組んでいない限り、私は現在維持しています。

ジョン・ホプキンスはこう書いた：

はい、主に商用開発で​​使用される最も人気のある2つの開発プラットフォーム（Javaと.NET）がオブジェクト指向であるため、主にOOが多く使用されます（多態性、継承、その他すべてを含む）。

これは私が言っていたこととほぼ同じですが、Javaと.Netだけではなく、C ++はどこにでもあり、Objective-CはOSX全体に、クールな子供たちはすべてRubyまたはPythonを、そしてこれらのすべてと多くの多くのことをしていますより多くのオブジェクト指向に焦点を当てています。新しい言語の多くはマルチパラダイムであるため、F＃のようなものは主に関数型言語ですが、オブジェクト指向もサポートしています。それはどこにでもあり、少なくともある程度の理解があれば非常に便利です。ただし、大学のコースを修了したということは、現実の世界でコードの開発について学び始める準備ができていることを意味します。

私は長い間プログラミングを行ってきましたが、Cでプログラミングする場合でもOOの概念は有用であることがわかりました-テストされたとしても、それらの概念を細かく説明することはおそらくできないでしょうが。ある時点で、概念を理解し、新しい角度からオブジェクト指向の楽しみを見つけるために、初歩的な言語ではあるがオブジェクト指向言語を作成しました。

ところで、Objective Cはそれを正しく行いますが、C ++はOOの巨大で見苦しい混乱をもたらしました。

インタビューについては、テーブルの両側からホラーショーになっています。ほとんどのインタビュー対象者は、彼らに非常に驚いています。ほとんどの採用マネージャーは、非常に基本的なプログラミングテストでさえ失敗する人が多いことに驚いています。

そうは言っても、ソフトウェア業界では現在、何も知らないが、将来の従業員に世界を期待する巨大な潅水袋がいくつかあります。

OOPの学習は、ソフトウェア開発の学習ほど有用ではありません。Code Complete 2を読んでください。

確かに便利なツールですが、OOP自体は本当に小さいです。一般に、企業やリクルーターが「OOP」と言うとき、それらは「ソフトウェア開発」を意味します。これは一般的な用語として使用されています。

実際の採用担当者は、ソフトウェアの開発方法を知っていることと、「OOPで3年を過ごしています」のチェックボックスを一致させることの違いを教えてくれます。

他のいくつかの人が指摘しているように、答えはイエスです。

ただし、非OO手続き型スパゲッティコードの山で作業したい場合は、そこにも見つけることができます。オブジェクト指向の作業を好むと思います。

編集：ガンスリンガーの皮肉とユーモアのセンスの私のケースを許してください。Raynosが言ったように、何かがオブジェクト指向だからといって、それが良いことを意味するわけではありません。オブジェクト指向を適切に適用するには、実際の作業と思考が必要です。それのインスタンスを持っているだけでは、自動的にアプリがうまくいくというわけではありません。そして逆に、よく書かれた手順コードがそこにあると確信しています。90年代から2000年代にかけての企業ITショップでの私の経験では、多くの悪いコードが書かれていて、おそらくまだ存在しています。しかし、OPの質問に近いと思いますが、より賢い開発者は、機会があれば、より多くのOOシステムに移行していることに気付きました。

オブジェクト指向は、他の手法が構築される基本的な基盤です。重要な点は、最初に型（クラス）とその型のインスタンスの違いを完全に理解することです。それを完全に理解せずに読み進めないでください（後でそれが明らかになると思います）。ビジョンをつかんだら、残りをもう一度読む必要があります。

一度それを理解したら、それなしではやりたくなくなるでしょう。カプセル化、パターン、フレームワークなど、私は純粋主義者ではありません。仕事では、さまざまなビューや概念に適応する必要があります。私自身の過去の職歴をいくつかリストします。

ある会社では、私の仲間はできるだけ多くの遅延読み込み（空のコンストラクター、どこでもnull値をチェックする必要があるかさばるプロパティ）を望んでいました。彼らは、短命であったWebベースのサーバー側オブジェクトを構築していました。

次の仕事はまったく逆でした。オブジェクトはデスクトップ（Excelベース）アプリケーション内に存在していました。コンストラクター（または多くのコンストラクターオーバーロードの1つ）で可能な限り多くの初期化を行う必要があります。空のオブジェクトには存在権がないため、空のコンストラクターは許可されませんでした（永続性が非常に困難になりました）。加えて、スタイルコーディングを通過しなかった場合、コードをチェックインできなかったため、「コーディングスタイル標準」（括弧を開く場所、コメントの後に空白を追加する場所など）に適応する必要がありました。

現在、私は開発者の誰もオブジェクト指向を理解しようとしたことのない会社で働いています。それがどれほど苛立たしいのかを表現するのは難しい。Grepのスキルを向上させる必要がありました。実際、選択したテキストに対してgrepを実行するために、F12キーにHotScriptsマクロが割り当てられています。私は他の欲求不満をspareしまない...

オブジェクト指向のスキルを習得すると、スパゲッティにほとんどアレルギーになります！しかし、すべての場合において、オブジェクト指向であろうとなかろうと、忍耐強く適応してください。「捨ててやり直す」ことには消極的です。あなたの上司は、捨てることに関してはむしろあなたを選ぶでしょう。残念ながら、エレガントなコードよりも「お金を稼ぐ」ことが重要です。

長い回答で申し訳ありませんが、私はあなたの質問のほとんどの範囲をカバーしようとしました:-)

OOPはそれ自体では重要ではありませんが、OOPに必要なもののために重要です。抽象化して分離し、グループ化する機能を扱うものは、相互作用するために必要な部分のみを公開します。

これは、「モジュール化」と呼ばれる一般的なエンジニアリング手法であり、複雑なシステムを単純なシステムの集合体として作成できます。高レベルですべての詳細を処理する必要はなく、同じ。

これらの「エンジニアリングコンセプト」は、ソフトウェア製品自体が「単一の開発者の能力」よりも大きくなった時点からソフトウェア開発に取り入れることを試みたため、開発者が独立した部分で作業し、それらの部分を一緒に交流します。

とはいえ、これらの原理は必ずしもOOPでのみ見つかるわけではありません（計算理論が有効であり、それらの結果に到達する無限の可能な方法があります）。

OOPは、単にそれらの定義（パターン）のより正確な定義と精巧な概念化（モジュール化、カプセル化、置換のような）これらの一般的な用語に与えて、一緒にそれらのものを置くために成功した試みであることができ、プログラミング言語に収まります。

OOPは、最初に「言語機能」としてではなく、ソフトウェアエンジニアにソフトウェア設計にアプローチさせる「一般的な用語集」として考えてください。

特定の言語に、そのカプセル化を直接実施するプリミティブがあるかどうかという事実-たとえば-「カプセル」が意図していない人によって誤って開かれないことは、OOP設計の二次的な側面です。そのため、言語自体が直接的なサポートを提供していない場合でも、大規模なCプロジェクトでもOOPとして「管理」されることがよくあります。

すべての利点は、プロジェクトの規模が、開発者が行うすべてのことを理解し追跡する単一の開発者の能力（実際、そのような状況では「オーバーヘッド」と見られることもあります）に留まるか、何かを開発する小さなグループになるまで認識できない短い期間。そして、それが、「言語機能」の観点からOOPを研究した後輩が、誤った設計コードの生成を誤解することが多い主な理由です。

OOPが言語にどのように適合するかは、言語設計者が独自の構成でOOP原則をどのように解釈するかに依存します。

したがって、C ++の「カプセル化」は「プライベートメンバー」（および「カプセル」はクラスになります）、「置換」は仮想関数のオーバーライドまたはテンプレートのパラメーター化/特殊化などになり、Dではカプセルは「モジュール」になりますつまり、特定のパラダイムやパターンを特定の言語で直接利用できるようにし、他の言語では利用できないようにします。

採用担当者がOOPの質問に求めるのは、将来の大規模なプロジェクトおよび開発のためにソフトウェア設計を抽象化および実現する能力をチェックするだけです。OOP、彼らはあなたと彼らの両方が知っていると仮定した単なる「辞書」であり、他のより一般的なことについて話したり、具体的な実装に具体化することができます。

オブジェクト指向言語は、コード内でオブジェクト指向の設計を維持するのに役立ちます。これは良いことです。しかし、そのようなデザインが他のパラダイム言語でも取得できることも事実です。OO言語の人気（特に企業間）の理由は、おそらくjavaとc＃の商業的成功にあります。

ゲイツ氏が彼の会社を正しい方法で始めていたら、就職する前にSCHEMEを勉強していたでしょう。

短い答えははいです

あなたが感じる理由またはジレンマの中でなぜそれが重要であるかについての長いバージョンは、何らかの目的に役立つプロジェクトまたは実装に取り​​組んでいないという事実のみによるものです。教室で自動車に例があり、その後自動車、トラックに拡張されることは教室で完全に有効です... もしそうでなければ、コードベース全体で誰もが同じようなコードを書いOOてもらうか、車輪を毎日再発明します。何かを修正するためにそのようなコードベースに飛び込むとしたら、それはどんな混乱になるか想像してみてください。教室の例は、漠然とした定義またはそれが行われる方法/理由の表現のためのものです。実際のテストは、アプリの構築を開始したときに行われます。間違いなくひどく使用される可能性がありますが、明確で簡潔な使用法のため、健全性よりもはるかに重要です。悪夢のようなコードを解き放ち、少なくともこれらの弱い領域での作業を開始することをお勧めします。

場合によります。プログラミング言語の共通語であるため、オブジェクト指向を知る必要がある理由の1つです。別の答えが指摘するように、ほぼすべての主要言語は何らかの形でオブジェクト指向です。つまり、基本的にあなたを雇うかもしれない会社はオブジェクト指向言語を使用しているということです。OCamlプログラマーを雇ってみませんか？それは不可能だ; 人材プールが小さすぎます。OCamlを使用して会社を設立し、会社が成功した場合、プログラマーを十分な速さで雇うことができなくなり、廃業します。したがって、3人以上のプログラマーを持つほぼすべての企業がオブジェクト指向言語を使用します。同僚と通信し、プラットフォームのライブラリを使用するには、オブジェクト指向を理解する必要があります。

会社が使用している特定の言語に応じて、継承とポリモーフィズムは非常に重要であるか、中程度に関連しています。10個のGoF設計パターンと依存性注入フレームワークを無効にしないと、Javaで何もできません。Javaは最も広く使用されている言語の1つであるため、Javaを使用する多くの企業にとってオブジェクト指向の原則は本当に重要です。

会社がScalaやC＃などのラムダと関数ポインターを備えた最新のハイブリッドOO /関数型言語を使用している場合、そうでなければ多くの場合に必要な多くの非常に単純なことを処理する高階関数があるため、継承は突然重要性が低くなります儀式。ただし、使用するほとんどのライブラリはオブジェクト指向で作成されるため、オブジェクト指向で作業できる必要があります。

会社にとって継承とポリモーフィズムが重要でない場合でも、オブジェクト指向の質問を受け取る可能性があります。理由は次のとおりです。

• あなたは、プログラミングについて何も知らず、チェックリストから質問をしている人事担当者からインタビューを受けています。3年のXがありますか、マルチタスクはありますか。
• あなたは岩の下に住んでいないことを確認したいエンジニアによってインタビューされています。OOは共通語なので、いくつかの大まかな質問があります。
• 面接があまり得意ではないエンジニアから面接を受けます。一般に、エンジニアは雑学や複雑さを好むため、ポリモーフィズム、継承、GoFのデザインパターンに関する多くの質問を受け取るのは、これらのことは面接する人にとって興味深いからです。

一言で「はい」。

あなたは理論を知っていると思うかもしれませんが、いくつかのコードを書いて実践する必要があります。文字通り何千もの例と演習がオンラインで利用可能です。