OOプログラミングは、採用企業が配置するのと同じくらい重要ですか？
私は修士号（コンピューティング）を修了し、仕事に応募しています。私は、多くの企業がオブジェクト指向の理解を特に求めていることに気づきました。よくあるインタビューの質問は、継承、ポリモーフィズム、アクセサーなどに関するものです。
OO本当に重要なのですか？）Cでプログラミングの仕事の面接を受けたことがあり、面接の半分はOOでした。
実際のアプリケーションを開発している現実の世界では、オブジェクト指向はほとんど常に使用されていますか？ポリモーフィズムのような主要な機能は、LOTで使用されますか？
私の質問は私の弱点の1つから来ていると思います。 OOについては知っていますが、OOをプログラムにうまく組み込むことができないようです。
OOPは、維持/理解できなくなることなくプログラムを成長させるパラダイムです。これは、学生が2週間から最長2か月間しか続かない小さなプロジェクトを行うため、学生がほとんど得ることができない点です。
この短い期間は、OOPの目的を明確にするのに十分ではありません。特に、プロジェクトの人々が初心者の場合はそうです。しかし、大規模なプロジェクトでは、モデル化に固執することが重要です。 。OOPはそれに対する唯一の解決策ではありませんが、これは業界で最も広く使用されています。
これが、人々があなたにOOPを知ってもらいたい理由です。
経験から言うと、ほとんどすべてのジュニアプログラマーには、モデル化とOOPに深刻な欠陥があります。彼らのほとんどは、クラスの記述方法、クラスからの継承方法、およびそのような基本的なものを知っていますが、「OOP」を考えず、誤用することはありません。これが、真面目な採用担当者が常にOOPドメインのコンピテンシーを調べます。
これらのことは学校では学ばないため、候補者によって知識が大きく異なるだけです。正直に言いましょう：OOPの知識が不足している人が大きなプロジェクトに取り組む可能性があるとは思いません。単に、リード開発者がこれらの人々を管理するために、単に自分でコーディングします。
「OOP」をまだ考えていない場合は、それについていくつかの本を読んで、あまり大きなプロジェクトがない会社に応募することをお勧めします。 OOP）に慣れるために雇用主のために有益な仕事を続けます（そして、彼/彼女があなたに給与を与えている限り、これもあなたにとって有用です）。
編集：ハ、そして私はすでにCでOOPコードを書いたことを追加します、それがCの最も一般的な使用法ではない場合でも、これは強力な知識で可能です。vtableをビルドするだけです手動で。
そしてOOPテクニックの背後には、何かが隠されています：ソフトウェア設計。ソフトウェア設計は、他の言語と同様にCでも非常に役立ちます。多くの採用担当者がソフトウェア設計の能力をテストします。OOPの質問はそのために適していますが、OOPはここでテストされている主なものではありません。これが、Cの仕事でもこれらの質問がある理由です。
コンピュータプログラミングの圧倒的な問題は処理の複雑さであり、現代のプログラムは実際には非常に複雑になる可能性があり、これは増加するように思われます。
自明ではないコンピュータープログラムのソフトウェアエンジニアリングで行われる作業の多くは、複雑さを軽減することに集中しており、最初に学習の生涯を費やすことなく、できるだけ多くの人がアクセスできるようにします。
例：
- モジュール化：コードのモジュールを使用することで、プログラムを概念的に単純化します。各モジュールは、他のモジュールについて少ししか知りません（たとえば、ネットワークアイコンバッファーを直接操作できるマウスアイコン描画ルーティングではありません）。
- API：APIの背後にある複雑なプログラムへの簡単な使用方法を提供します。ファイルを開くときに、ネットワーク共有がUSBディスクとは異なる方法で処理されることは問題ではありません。 APIは同じです。
- オブジェクトの向き。これにより、既存のコードを再利用し、追加した新しいコードで透過的に機能させることができますが、根本的な複雑さはすべて隠されます。
言い換えると、重要なソフトウェアを単独で、または（おそらく）他のソフトウェアと共同で作業する場合は、多くのトリックを知る必要があります。
はい、主に商用開発（Javaと.NET）で使用されている最も人気のある2つの開発プラットフォームはオブジェクト指向であるため、OOが多型、継承などすべて使用されますそうしないと）。
企業はオブジェクト指向をテクノロジーとして特に気にしません。これはイデオロギーの問題ではありません。IT戦略に沿った方法で問題の解決策を開発できる人を気にします。
しかし、それが弱点であると感じてもあまり心配しません。あなたの教育を軽視しない限り、商業の世界のほとんどの人は、プログラマーが大学を（どんなレベルでも）卒業するのを完成した記事と見なしません。あなたはまだ学ぶべきことがたくさんあります、そしてそれは理解されています（おそらく学生よりも会社によってより良いです）。
現実と同様に、現実のプログラミングも理論とは異なります。
はい、OOパラダイムを洗練された状態に保ち、常に心の奥に置いておくと、管理しやすく、理解しやすく、拡張が容易なコードをより上手に書くことができます。
残念ながら、現実の世界にはこれがあります：
- プロジェクト時間のプレッシャー
- 手続き指向のチームメンバー
- クロスロケーションのチーム、複数のベンダー
- いかなる方向性も持たないレガシーコード
- それが機能する限り、コードがどのように書かれるかについていくつかの注意が必要です
- コードが機能しない場合でも、動機はそれを修正することであり、「OO」するのではありません
- モジュール、プラットフォームの制限、フレームワークは、優れたオブジェクト指向を実行することを単に許可しません
実際の仕事では、上記の問題に取り組む必要があります。これは意気消沈したようです。ただし、これはヘッドアップとして扱います。採用企業は、OOを採用する際に重視しすぎます。理由は簡単にわかります。候補者をテストする唯一の方法は、OOの理解について尋ねることです。そして、残念ながら、多くの候補者はただブラッシュアップします面接の前にそれらの質問について。
現実の生活OO遅くなります。時間をかけて読み続け、改善し続けると役に立ちます。
学士号を取得したときもまったく同じ気持ちでした。なぜOOPが実際のアプリケーションに関連するのかという理由と方法はまず、デザインパターンのぞくことをお勧めします。これは非常に楽しい方法で記述されており、大規模で作業するときにOOPアプローチが望ましい理由について多くの有効なポイントを示しています。絶えず変化するシステム。
OOがすべてである-OOで都市を構築することができますが、手続き型プログラムはレンガです。
アナロジーの形で私の答えを与えるために、一般はオブジェクトを必要とし、兵士は手続きを必要とします。 OOで十分にドリルダウンしたら、手順を見つけます。それがあなたの専門知識で十分である場合は、OOについて心配する必要はありません。誰かがこれを書くのは簡単です。 OOチェスのゲームコード：
-findBestMove
-makeBestMove
-waitForPlayerInput
しかし、誰かが-findBestMoveの背後にあるコードを記述する必要があり、これがこれだけではないことを確認できます。
foreach $move (@moves){
$bestMove = ($move > $bestMove ? $move : $bestMove)
}
return $bestMove
一方、OOコードの読み方がわからない場合は、心配してください。コードがなんらかのオブジェクトに干渉していることが（ほぼ）確認できるためです。）現在維持している12000のグローバル変数と1200行の「モジュール」のFortranレガシーベヒーモスに取り組んでいます。
ジョン・ホプキンスは書いている：
はい、主に商用開発（Javaと.NET）で使用されている最も人気のある2つの開発プラットフォームはオブジェクト指向であるため、OOが多型、継承などすべて使用されますそうしないと）。
これは私が言おうとしていることのほとんどですが、Javaと.Netだけではありません。C++は至る所にあります。Objective-CはOSX全体にあり、すべてのクールな子供たちがしていますRubyまたはPython、およびこれらすべて、そして多くのものがオブジェクト指向に焦点を当てています。新しい言語の多くはマルチパラダイムであるため、F＃のようなものは主に関数型言語ですが、オブジェクト指向もサポートしています。それは至る所にあり、少なくともある程度の理解があれば非常に役立ちますが、あまり心配しないでください。大学のコースを修了したばかりであれば、現実の世界でコードの開発について学ぶ準備ができています。
私は長い間プログラミングをしてきましたが、OOの概念は、Cでプログラミングする場合にも役立ちます-テストしたとしても、すべての小さな概念でそれらの概念を説明できなかったとしても詳細。ある時点で、私はOO言語を初歩的なものではあるが作成し、概念を理解し、OO新しい角度。
ところで、C++はOOの巨大で醜い混乱をもたらしましたが、Objective Cはそれを正しく行います。
インタビューについては、テーブルの両側から、ホラーショーになっています。ほとんどのインタビュー対象者は、彼らにすごくびびっています。ほとんどの採用マネージャーは、非常に基本的なプログラミングテストでさえ、どれだけの人が不合格であるかに驚いています。
とはいえ、ソフトウェア業界では、何も知らないにもかかわらず、将来の従業員に世界を期待している巨大なバッグが現在存在しています。
学習OOPは、ソフトウェア開発の学習ほど有用ではありません。読んでください Code Complete 2 。
確かにそれは便利なツールですが、OOP自体は本当に小さいです。一般に、企業や採用担当者が「OOP」と言うとき、 「ソフトウェア開発」を意味し、一般的な用語として使用されています。
実際の採用担当者は、ソフトウェアの開発方法を知っていることと、「3年間は「OOP」を持っている」というチェックボックスを照合することの違いを教えてくれます。
OOP自体は重要ではありませんが、OOPに必要なものがあるためです。抽象化して分離し、グループ化する機能を扱うものは、相互作用するために必要な部分のみを公開します。
これは、「モジュール化」と呼ばれる一般的なエンジニアリング手法であり、複雑なシステムを単純なものの集合体として作成し、詳細をすべて高レベルで処理する必要がなく、コンポーネントを交換可能にする必要があります。同じ。
これらの「エンジニアリングの概念」は、ソフトウェア製品自体が「単一の開発者の能力」よりも大きくなったときから開発者が独立した部分で作業し、それらの部分を一緒に相互作用します。
とは言っても、それらの原則は必ずしもOOPだけにあるわけではありません（計算理論が有効である場合、それらの結果を得る方法は無限にあります）。
OOPは、これらのことをまとめる成功した試みであり、一般的な用語（モジュール、カプセル化、置換など）に、より正確な定義と、canがプログラミング言語に適合する定義（パターン）についての詳細な概念を与えます。
最初にOOPを "言語機能"ではなく、ソフトウェアエンジニアがソフトウェア設計にアプローチするようにする "common Lexicon"と考えてください。
特定の言語に、レキシコンに直接適用するプリミティブがあるかどうかという事実-たとえば-「カプセル」が意図せず開かれていないことを保証することは、OOP設計の2次的な側面です。 。そのため、言語自体が直接のサポートを提供していなくても、大規模なCプロジェクトでもOOPとして「管理」されることがよくあります。
プロジェクトの規模が、開発者が行うすべてのことを理解して追跡する（実際には、このような状況では "オーバーヘッド"と見なされることもある）か、または何かを開発している小さなグループに入るまで、プロジェクトサイズが1つの開発者の能力にとどまるまで認識できないすべての利点短い期間。そして、それがOOPを「言語機能」の観点から研究した後輩がしばしばそれを誤って解釈して悪い設計コードを生成する主な理由です。
OOPがどのように言語に適合するかは、言語設計者が独自の構成要素でOOPの原則をどのように解釈するかによって異なります。
したがって、C++の「カプセル化」は「プライベートメンバー」になり（「カプセル」はクラスになります）、「置換」は仮想関数のオーバーライドやテンプレートのパラメータ化/特殊化などになりますが、Dではカプセルは「モジュール」になります（そして置換はクラスなどを通じて）、特定のパラダイムやパターンを特定の言語で直接利用できるようにし、別の言語では利用できないようにします。
採用担当者がOOPの質問をする際に求めているのは、将来の大規模なプロジェクトと開発のためにソフトウェア設計を抽象化して考案する能力を確認することです。 OOP、彼らはあなたと彼らの両方が知っているはずの「辞書」にすぎないので、あなたは他のより一般的なことについて話したり、特定の実装に具体化したりできます。
他のいくつかの人が指摘しているように、答えはイエスです。
しかし、OO以外の手続き型スパゲッティコードの山に取り組みたい場合は、そこにもそれがあります。 OO仕事を好むと思います。
編集：銃殺者の皮肉とユーモアのセンスの私のケースを許してください。レイノスが言ったように、何かがOOであってもそれが良いことを意味するわけではありません。OOの適切な適用は、実際の作業と思考を必要とします。アプリが適切に作成されていることを自動的に意味するわけではありません。逆に、きちんと記述された手続き型コードがあるはずです。90年代と2000年代の企業ITショップでの私の経験では、多くの不正なコードが記述され、おそらくまだ存在しています。しかし、OPの質問に近づくと、より賢い開発者は、機会が与えられたときに、より多くのOOシステムに移行することに気づきました。
OOは、他の技術が構築される基礎となります。重要なポイントは、まず型（クラス）とその型のインスタンスの違いを完全に理解することです。それを完全に理解せずに読み進めないでください（後で明らかになると思います）。ビジョンを見つけたら、残りをもう一度読み直す必要があるためです。
一度コツをつかめば、それなしではやりたくないでしょう。カプセル化、パターン、フレームワークなどに関しては、私は純粋主義者ではありません。仕事では、さまざまな見方や概念に適応する必要があります。私自身の過去の職歴をいくつか挙げます。
ある会社では、私の同僚は可能な限り遅延読み込み（空のコンストラクター、どこでもnull値をチェックする必要があるかさばるプロパティ）を望んでいました。彼らは短命だったWebベースのサーバー側オブジェクトを構築していました。
次の仕事は完全に反対でした。オブジェクトは、デスクトップ（Excelベース）アプリケーション内にありました。できるだけ多くの初期化をコンストラクター（または多くのコンストラクターオーバーロードの1つ）で行う必要があります。空のオブジェクトには存在する権利がないため、空のコンストラクターは許可されませんでした（永続化を非常に困難にしました）。さらに、「コードスタイルの標準」（括弧を開く場所、コメントの後に空白を追加する場所など）に適応する必要がありました。これは、style-copを通過しないとコードをチェックインできなかったためです。
現在私は、開発者の誰もOOを理解しようと試みたことのない会社で働いています。それがいかに非常に苛立たせているかを表現するのは難しい。私は自分のGrepスキルを向上させる必要がありました。実際、選択したテキストでgrepを実行するために、F12キーにHotScriptsマクロが割り当てられています。他のフラストレーションを惜しまない...
OOスキルを習得したら、スパゲッティにほとんどアレルギーになります！しかし、すべての場合において、OOであろうとなかろうと、辛抱強く適応します。「捨ててやり直す」ことに消極的になります。 。投げ捨てに関しては、上司があなたを選ぶでしょう残念ながら、エレガントなコードよりも「稼ぐ」ことが重要です。
長い答えで申し訳ありませんが、私はあなたの質問のほとんどの範囲をカバーしようとしました:-)
短い答えはイエスです
なぜそれが重要であると感じるか、またはジレンマに陥っているより長いバージョンは、何らかの目的に役立つプロジェクトまたは実装に取り組んでいないという事実にのみ起因します。教室で自動車の例を持っていることは完全に有効で、次に車、トラックに拡張されますが、ソフトウェア開発に飛び込むとき、いくつかのタスクを容易にすることを目的としたソリューションです。 OOがなければ、 コードベース全体で同様のコードを書いている全員、または ホイールを毎日再発明。何かを修正するためにそのようなコードベースに飛び込んだとしたら、どうなるか想像してみてください。教室の例は、漠然とした定義またはそれがどのように/なぜ行われたかを表すためのものです。実際のテストは、アプリの作成を開始した時点で行われています。間違いなく、アプリがひどく使用される可能性があることは間違いありませんが、その明確で簡潔な使用法により、正気をはるかに上回っています。したがって、これらの弱い領域での作業を開始するには、悪夢のコードを作成する必要がほとんどありません。
場合によります。 OOは、プログラミングの世界の共通語であるため、知っておく必要がある1つの理由です。別の回答が指摘するように、ほぼすべての主要言語は何らかの方法でOOです。つまり、基本的に、あなたを雇う可能性のあるすべての会社がOO言語を使用しています。 OCamlプログラマーを雇うことを試みたことはありますか？それは不可能だ;人材プールが小さすぎます。 OCamlを使用して会社を始め、会社が成功した場合、プログラマーを十分に早く雇うことができず、あなたは廃業するでしょう。したがって、3人以上のプログラマーがいるほぼすべての企業はOO言語を使用しており、同僚と通信してプラットフォームのライブラリを使用するには、OOについて理解している必要があります。
会社が使用している特定の言語に応じて、継承とポリモーフィズムは非常に重要であるか、適度に適切です。 Javaでは、10個のGoF設計パターンと依存性注入フレームワークを無効にしないと何もできません。 Javaは最も広く使用されている言語の1つであるため、Javaを使用する多くの企業にとってOOの原則は非常に重要です。
会社がScalaやC＃などのラムダと関数ポインターを備えた最新のハイブリッドOO /関数型言語を使用している場合、非常に単純なことの多くを処理する高次関数があるため、継承は突然重要性を失うそうでなければ、多くの儀式が必要になります。ただし、使用するほとんどのライブラリはOOの方法で記述されるため、OOを使用できるようにする必要があります。
継承と多態性ではない会社にとって重要な場合でも、次の理由によりOOの質問を受け取る可能性があります。
- あなたは、プログラミングについて何も知らず、チェックリストから質問をしている人事担当者からインタビューを受けました。 Xは3年間ですか、マルチタスクですか
- あなたは岩の下に住んでいないことを確認したいエンジニアからインタビューを受けました。 OOはリングアフランカなので、それについておおざっぱな質問をされます。
- あなたは面接にあまり熟達していないエンジニアから面接を受けました。一般に、エンジニアは雑学と複雑さを愛しているので、ポリモーフィズム、継承、およびGoFのデザインパターンについて多くの質問を受けることになります。
オブジェクト指向言語は、オブジェクト指向の設計をコードに保持するのに役立ちます。しかし、そのようなデザインが他のパラダイム言語で取得できることも真実です。OO言語の人気（特に企業間）の理由は、おそらくJavaおよびc＃の商業的成功にあります。 。
ゲイツ氏が会社を正しい方法で始めたとしたら、就職前にスキームを勉強することになるでしょう。