class - クラスは、大規模なアプリケーションの管理にどのように役立ちますか?

Question

これは私がオンラインで行っていた会話の中で出てきましたが、これがどのように機能するのかまったくわからないことに気づきました: 非常に多くのプログラマーは、クラスが必要な言語であることは明らかです。巨大なソフトウェアプロジェクトを管理するための機能。

彼らがどのようにこれを行うかは私には明らかではありません。

あなたへの私の質問は、どのように知っていますか? クラスが生産性を向上させ、コードを再利用し、プログラムの作成の複雑さを軽減することを示す客観的な尺度は何ですか? クラスのどのような側面が、大規模なチームが共同作業を行うのに理想的であるか?

では、ちょっと言いにくい質問をさせてください。私がこれを誤解して、誰かを混乱させたり怒らせたりしてしまったら、ごめんなさい:

そもそもアプリケーションが大きくなる原因がクラスの使用ではないことを、客観的にどのように判断できるのでしょうか? つまり、他のコード再利用戦略を使用して、同等の機能を持つプログラムを、はるかに少ないコードで、それを「管理」するための特別な手段を必要としないほど小さく書くことができた可能性はありますか? (関数型プログラミングパラダイムやアスペクト指向プログラミングなど、選択肢はたくさんあります)。

その最後のビットは、Steve Yegge が彼のブログでほのめかしているものです。しかし、私は、誰からの確かなデータがまったくなく、自分で結論を出すのに十分な経験がないため、議論の両側に懐疑的です.

どう思いますか？

編集:特に、多くのプログラマーが、大規模なアプリケーションに関しては、プロトタイプのスタイルの継承が適切ではないと考えている理由に興味があります。この質問があいまいで申し訳ありません。これは、このトピックに関する私の理解不足の産物です。

edit2: 関数型プログラミングの意味について混乱があるようです。(VB のどのバージョンも機能していたとは思いません。確かに古いバージョンではありません)。ウィキペディアの記事を参照してください。 http://en.wikipedia.org/wiki/Functional_programming

edit3:そして、私が客観的手段を探していることを強調させてください。主観的な意見ではありません。

score 6 · Accepted Answer

これはとても良い質問です。コードをクラスに編成することは、開発チームが小さな再利用可能なモジュールを作成する 1 つの方法です。また、これらのモジュールには、クラスがどのように機能するかではなく、何ができるかのみを表現する表現力豊かで制限されたインターフェースがあります。各クラスは他のクラスと直交しているため、テストが容易で、エラーが発生した場合に備えてモジュール化されています。

今私が説明したのは、完璧な世界からの奇妙な光景です。しかし、OOP 作業を行っている優れた開発者は、このようなことを目指して努力する必要があります。

OOP は、私たち開発者は単なる人間であり、システム全体を一度に理解することはできないという認識です。そのため、システムを再利用可能な小さなパーツに分割し、それらに焦点を当てています。

例として、米国の 10 桁の電話番号を取り上げます。頭の中で 10 桁の数字を覚えるのは難しいので、心理学者が「チャンキング」と呼ぶことを行います。これは、私たちがよりよく覚えられるように、数字を精神的にチャンクに分解することを意味します。

と1234567890なり123-456-7890ます。私たちにとって幸いなことに、電話会社もこれらの数字を同じように分解し、チャンクに意味を割り当てています。 123は市外局番、456はプレフィックス、7890は回線番号です。これらのチャンクはそれぞれクラスのようなもので、それぞれに個別の責任、形式、および意味があります。

結論として、私が言える最善のことは、OOP を使用すると、集中化されカプセル化された機能を備えた大規模でスケーラブルなシステムを構築できるということです。これにより、常に全体像を見る必要がなくなり、1 つのことを適切に行うことに集中できるようになります。

score 2 · Accepted Answer

私は決してどのようなプログラミングパラダイムにも偏見を持っているわけではありませんが、しばらくの間オブジェクト指向のやり方で運用してきました。

個人的には「あはは！」が多かったです。クラスが、私が取り組んでいる分野をよりよく理解するのに直接役立った瞬間。

最も顕著なのは、システムが誤動作している理由や、システムが何をすべきかについて混乱がある場合、授業では、全体のこの個別の部分が何をすべきかを考えさせられることがよくあり、多くの場合、そうではありません。手元のクラス/メソッドをリファクタリングします。

要するに、カプセル化は本当に私を幸せな人にします. ;)

それが役立つことを願っています。

score 2 · Accepted Answer

カプセル化理論は、クラスがまったくないよりもクラスが優れている客観的な理由の 1 つを提供します。

国際標準化機構は、カプセル化を次のように定義しています。

したがって、一部の情報はこれらのインターフェイスを介してアクセスできるため、一部の情報はオブジェクト内で非表示にしてアクセスできないようにする必要があります。そのような情報が示す特性は情報隠蔽と呼ばれ、Parnas は、難しい決定と変更される可能性のある決定の両方を隠すようにモジュールを設計する必要があると主張して定義しました。

その言葉に注意してください：変更。情報隠蔽は、将来の困難な設計上の決定の変更など、潜在的なイベントに関係しています。

クラス内に隠されている情報であるメソッド a() と、公開されているため他のクラスから直接アクセスできるメソッド b() の 2 つのメソッドを持つクラスを考えてみましょう。

メソッド a() への将来の変更により、他のクラスのメソッドの変更が必要になる可能性があります。メソッド b() への将来の変更により、他のクラスのメソッドの変更が必要になる可能性もあります。ただし、メソッド a() でこのようなリップルの変化が発生する確率は、通常、メソッド b() の場合よりも低くなります。これは、単にメソッド b() がより多くのクラスに依存している可能性があるためです。

この波及効果の確率の低下は、カプセル化の主な利点です。

どのプログラムでも、潜在的なソースコードの依存関係 (MPE - 頭字語はグラフ理論に由来) の最大数を考慮してください。上記の定義から推定すると、ユーザーに同じ機能を提供する 2 つのプログラムが与えられた場合、MPE が最も低いプログラムがより適切にカプセル化されており、統計的には、より適切にカプセル化されたプログラムの方が保守と開発が安価になると言えます。それに対する最大の潜在的な変更のは、あまりカプセル化されていないシステムに対する最大の潜在的な変更よりも低くなります。

さらに、メソッドだけでクラスがなく、したがってメソッドを互いに隠す情報手段がない言語を考えてみましょう。プログラムに 1000 個のメソッドがあるとします。このプログラムの MPE は何ですか?

カプセル化理論によると、n 個のパブリックノードのシステムが与えられた場合、このシステムの MPE は n(n-1) です。したがって、1000 個のパブリックメソッドの MPE は 999,000 です。

では、そのシステムを 2 つのクラスに分割してみましょう。それぞれに 500 のメソッドがあります。クラスができたので、いくつかのメソッドを公開し、いくつかのメソッドを非公開にすることを選択できます。これは、すべてのメソッドが実際に他のすべてのメソッドに依存している場合を除きます (これはありそうもないことです)。各クラスの 50 個のメソッドが公開されているとしましょう。システムの MPE はどうなりますか?

n((n/r) -1 + (r-1)p) ここで、r はクラスの数、p はクラスごとのパブリックメソッドの数です。これにより、2 クラスシステムの MPE は 499,000 になります。したがって、この 2 クラスシステムの変更の潜在的な最大コストは、カプセル化されていないシステムのコストよりも大幅に低くなります。

システムを 3 つのクラスに分割し、それぞれに 333 個のクラスがあり (1 つには 334 個あります)、それぞれに 50 個のパブリックメソッドがあるとします。MPEとは何ですか？上記の式を再度使用すると、MPE は約 482,000 になります。

システムがそれぞれ 250 メソッドの 4 つのクラスに分割される場合、MPE は 449,000 になります。

システム内のクラスの数を増やすと常に MPE が減少するように思われるかもしれませんが、そうではありません。カプセル化理論によると、MPE を最小化するためにシステムを分解する必要があるクラスの数は、r = sqrt(n/p) であり、このシステムでは実際には 4 です。たとえば、6 つのクラスを持つシステムには MPE があります。 465,666の。

score 2 · Accepted Answer

クラスはカテゴリ化の非常に一般的な認知概念に対応し、大規模なアプリケーションを自然に記述するのに役立つため、クラスが役立つと思います。

score 1 · Accepted Answer

私は、大きな問題を個々のユニットとしてテスト可能な扱いやすい部分に分割できるように、クラスを好みます。私見ですが、コードの再利用は過大評価されています。私にとって、優れた OO から最も得られるのは優れたテスト容易性です。

もう 1 つの極端な方法は、一連のグローバル変数を使用してすべてのロジックをpublic static void main(またはPage_LoadASP.NET に) 詰め込み、他の静的メソッドを呼び出す静的メソッドを呼び出すことです... (最後の文の終わりでめまいがしました.)

オブジェクト指向の考え方を崩す唯一のことは、純粋な関数型言語を使用していた場合です。これは、残念ながら大学時代から考えていませんでした。

score 1 · Accepted Answer

単純な問題を不必要に複雑にすることで、単純な問題を過剰に設計する可能性があります (完全にオブジェクト指向)。ただし、十分に大きな問題については、OO パラダイムがそもそも問題を大きくした原因である可能性は低いと思います。オペレーティングシステムを例にとると、オブジェクト指向の方法で書かれていなければ、(コード的に) 保守が容易であるとは想像しがたいです。

score 1 · Accepted Answer

大規模なアプリケーションに「裸の」関数がたくさんある場合、それらの関数を変更するのは困難です。

誰が関数を使用しているかを確認するのが難しくなります (「これを変更すると、誰に影響がありますか?」)
他の人のコードを壊さずに関数を変更することは困難です。

関数をクラスにまとめると、コードの範囲を分離するのに役立ちます。魔法の弾丸ではありませんが、役に立ちます。

score 0 · Accepted Answer

2つのこと。

1 つ目は、クラスが不透明なドメインエンティティであるという考えです。オブジェクト指向プログラムが正しく行われると、抽象化のレイヤーが導入されます。次の最上位のレイヤーでは、詳細を処理するのではなく、オブジェクトをマーシャリングして、必要なことを実行します。オブジェクトとクラスがどのように機能するかを知る必要はありません。それらが何をするかだけを知ってください。これは一種の情報隠蔽であり、チームが作業中に頭の中で維持しなければならない複雑さを軽減します。

2 つ目は、OO プログラミングではある種のコードの再利用が可能になることです。他のクラスの特定の動作をオーバーライドするクラスを定義したり (継承)、インスタンスが他のクラスのインスタンスを含むクラスを定義したり、それらを使用して目的を達成したりできます (カプセル化と合成)。 .

OO 手法を正しく使用すると、管理する必要があるコードの量を削減でき、システムの作業や保守を行う際に留意する必要のある事項の数を減らすことができます。実際には、このアプローチが常に機能するとは限りません。

score 0 · Accepted Answer

そもそもアプリケーションが大きくなる原因がクラスの使用ではないことを、客観的にどのように判断できるのでしょうか?

オブジェクト指向言語 (C、COBOL、プレーン SQL など) で書かれていない大規模なプログラム/アプリケーションを例にとると、コードサイズが言語パラダイムに直接起因するものではないことがわかります。適切に設計され、高度に洗練された、再利用可能な C# または Java コンポーネントの数ごとに、適切に設計され、高度に洗練された、再利用可能な C DLL も同じ数存在します。逆に、恐ろしく肥大化したコードも同数あります。

要点は、優れたプログラマーは、言語/プラットフォームに関係なく、システム設計を改良できるということです。

OOPに関しては、少なくとも私にとっては、「可能性」、つまりプログラミングの世界を私たちの現実の世界に少し近づける可能性をもたらします。私たちは皆、私たちの世界とこの物質の宇宙が、より小さなオブジェクトで構成されたオブジェクトでいっぱいであることを知っています。銀河系の星系から分子、原子、亜原子粒子に至るまでズームインし続けると、同じ小さな粒子がさまざまなパターンで組み合わされて、非常に異なる物質が作られていることに本当に驚かされます。私たち自身の生物学を見てみても、私たちの体の 60% が実際には水であると考えると気が遠くなることがあります。それでも、私たちを動かし、生かし続けるために化学物質で燃えているさまざまなシステムと臓器をすべて見てください.

日常の自然に見られる現実世界のシステムを形成する構成要素の単純さを理解することを学ぶとき (ああ、本当に... ハハ)、非常に複雑または洗練された設計と構築が必要であることを理解できるはずです。システムは、それ自体ではほとんど機能しない小さなコンポーネントから始める必要があります。そして、それらをゆっくりと組み合わせてより大きなコンポーネントにメッシュ化することで、より多くの機能と能力を得ることができます. 思い描いた理想のシステムにたどり着くまで。

クラスの (適切な) 使用とは、システムをその最高のものに分解することです。できるだけ。一度に何かを見て、特定のレベルの抽象化を行い、現在の関心領域を扱っていない目的や論理に圧倒されないようにするためです。システムを設計するときはいつでも、自分自身の構造を考えてください。人体をどのように設計するかを考えてください。システムを設計するときはいつでも、新しい会社を始めることを考えてください。主要な部門、ビジネスを運営するために必要な部門は何ですか。それらの部門を運営するために必要なスタッフのタイプは誰ですか。仕事を遂行するために使用し、対話する必要があるさまざまな機器。業務をよりよく理解できるように、どのように業務を細分化しますか?

いくつかのオブジェクトは単純に小さなオブジェクトで構成されているという基本原理を理解すると、高度に再利用可能な細胞または分子を作成できるようになります。

score 0 · Accepted Answer

クラスは、複雑なプロジェクトの 1 つの小さな側面に一度に取り組むことができるという点で、私にとって最も役に立ちました。大規模なプロジェクトからコードの 1 つの側面を分離できることは、圧倒されないように非常に役立ちます。最終的に、これらのクラス間の結束により、内部を扱うことなく、プログラムがどのように機能するかを簡単に概観することができます。

保守性に関して言えば、関数のリストを見るよりも、UML クラス図を見てすべてがどのように配置されているかを理解する方がはるかに簡単だと思います。

score 0 · Accepted Answer

クラスと言うのは、オブジェクトを意味するべきだと思います。クラスは、オブジェクトを配置できる場所に他なりません。OOP パラダイムが非常に成功しているのには理由があります。その「あはは！」を持ったら。OOP の概念をようやく理解したと思った瞬間に、より体系的な方法でプログラミングを開始できます。

私は長い間 Visual Basic 3 でプログラミングを行ってきたので、関数型プログラミングの経験が豊富でした。その後、VB5 に来てオブジェクトを発見すると、実世界のエンティティを自分のコードに関連付けることができたので、非常に安心しました。多くの。

コード内で現実世界のエンティティを再作成することが、その要点です。何かを手に取って何かをしたり、何かをしたりできるので、読書や作業が簡単になります。

class - クラスは、大規模なアプリケーションの管理にどのように役立ちますか?

11 に答える 11

Related

Reference