タグ付けされた質問 「object-oriented」

システムを、モジュール方式で制御および操作できるオブジェクトのセットとしてモデル化できるようにする方法論

6
「インターフェースへのプログラミング」を理解する
「実装ではなくインターフェースへのプログラミング」という用語に頻繁に出くわしましたが、それが何を意味するのか理解していると思います。しかし、私はそれが利点であり、可能な実装であることを確実に理解したいと思っています。 「インターフェースへのプログラミング」とは、可能な場合、具体的な実装を参照するのではなく、クラスのより抽象的なレベル（インターフェース、抽象クラス、またはある種のスーパークラス）を参照する必要があることを意味します。 Javaの一般的な例は、次を使用することです。 List myList = new ArrayList();の代わりにArrayList myList = new ArrayList();。 これに関して2つの質問があります。 このアプローチの主な利点を確実に理解したいと思います。利点は主に柔軟性だと思います。具体的な実装ではなく、より高レベルの参照としてオブジェクトを宣言すると、開発サイクル全体およびコード全体で柔軟性と保守性が向上します。これは正しいです？柔軟性が主な利点ですか？ 「インターフェースへのプログラミング」の方法は他にありますか？または、「具体的な実装ではなく、インターフェイスとして変数を宣言する」がこの概念の唯一の実装ですか？ 私はJavaコンストラクトInterfaceについて話しているのではありません。オブジェクト指向の原則「実装ではなく、インターフェイスへのプログラミング」について話しています。この原則では、世界の「インターフェース」とは、クラスの任意の「スーパータイプ」を指します。インターフェース、抽象クラス、またはより具体的なサブクラスよりも抽象的で具体的ではない単純なスーパークラスです。
9
ほとんどの「よく知られた」命令型/オブジェクト指向言語が、「何もない」値を表すことができる型への未チェックのアクセスを許可するのはなぜですか？
null（たとえば）の代わりに持つことの（不）利便性について読んでいMaybeます。この記事を読んだ後、私はそれを使用する方がはるかに良いと確信していますMaybe（または同様のもの）。しかし、すべての「よく知られた」命令型またはオブジェクト指向プログラミング言語がまだ使用しておりnull（「何もしない」値を表すことができる型への未チェックのアクセスを許可します）、そしてMaybeほとんどが関数型プログラミング言語で使用されていることに驚いています。 例として、次のC＃コードを見てください。 void doSomething(string username) { // Check that username is not null // Do something } ここで何か悪臭がします...引数がnullかどうかを確認する必要があるのはなぜですか？すべての変数にオブジェクトへの参照が含まれると仮定すべきではありませんか？ご覧のとおり、問題は、定義上、ほとんどすべての変数にnull参照が含まれている可能性があることです。どの変数が「null可能」で、どれがそうでないかを判断できたらどうでしょうか。これにより、デバッグと「NullReferenceException」の検索中に多くの労力を節約できます。デフォルトでは、null参照を含むことができる型はないことを想像してください。その代わりに、本当に必要な場合にのみ、変数にnull参照を含めることができると明示的に述べます。それが多分背後にある考え方です。場合によっては失敗する関数（ゼロ除算など）がある場合は、Maybe<int>、結果がintである可能性があることを明示的に示しますが、何もありません！これは、nullではなくMaybeを好む理由の1つです。他の例に興味がある場合は、この記事を読むことをお勧めします。 事実は、ほとんどの型をデフォルトでNULL可能にするという欠点にもかかわらず、ほとんどのオブジェクト指向プログラミング言語は実際にそれをNULL可能にします。それが私が疑問に思う理由です： nullプログラミング言語ではなく、どのような引数を実装する必要がありMaybeますか？理由はありますか、それとも単に「歴史的な荷物」ですか？ この質問に答える前に、nullとMaybeの違いを理解してください。
7
「データ隠蔽」と「カプセル化」の違いは何ですか？
「実際のJava同時実行性」を読んでいます。「幸いなことに、カプセル化やデータ隠蔽など、よく組織化された保守可能なクラスを作成するのに役立つオブジェクト指向の手法は、スレッドセーフの作成にも役立ちますクラス。" 問題＃1-データの隠蔽について聞いたことがなく、それが何であるかわかりません。 問題＃2-カプセル化はプライベート対パブリックを使用しており、実際にはデータが隠れていると常に考えていました。 データ隠蔽とは何か、カプセル化とどのように異なるのか説明していただけますか？
12
クラスが「抽象」または「最終/封印」以外のものである必要があるのはなぜですか？
10年以上のjava / c＃プログラミングの後、次のいずれかを作成しています。 抽象クラス：そのままインスタンス化されることを意図していないコントラクト。 final / sealedクラス：実装は、他の何かの基本クラスとして機能することを意図していません。 単純な「クラス」（つまり、抽象的でもファイナル/シールドでもない）が「賢明なプログラミング」になる状況は考えられません。 クラスが「抽象」または「最終/封印」以外のものである必要があるのはなぜですか？ 編集 このすばらしい記事は、私の懸念を、私ができる以上によく説明しています。
12
クラスの大きさはどれくらいですか？
私は長年の開発者です（49歳）が、オブジェクト指向開発は初めてです。私はBertrand Meyer's Eiffel以来オブジェクト指向について読んでいますが、オブジェクト指向プログラミングはほとんどしていません。 ポイントは、オブジェクト指向設計に関するすべての本は、ボート、車、または私たちが頻繁に使用する一般的なオブジェクトの例から始まり、属性とメソッドを追加し、オブジェクトの状態をモデル化する方法と何ができるかを説明し始めることですそれ。 そのため、通常、「モデルが優れているほど、アプリケーション内のオブジェクトをより適切に表し、すべてがより優れている」というようなものになります。 これまでのところ非常に良いですが、一方で、「クラスは単一のページに収まる必要があります」などのレシピを提供する複数の著者を見つけました（「どのモニターサイズで？」コードを印刷します！）。 たとえば、PurchaseOrder動作を制御する有限状態マシンとのコレクションを持つクラスを考えてみましょう。PurchaseOrderItemここでの作業の引数の1つは、PurchaseOrderいくつかのメソッド（データクラス以上）を持つ単純なクラスを使用することです。PurchaseOrderFSM「エキスパートクラス」のためのハンドル有限状態マシンというPurchaseOrder。 これは、コーディング・ホラーに関するJeff AtwoodのCode Smells投稿の「Feature Envy」または「Inappropriate Intimacy」分類に該当すると言えます。私はそれを常識と呼んでいます。実際の注文書を発行、承認、またはキャンセルできる場合、PurchaseOrderクラスにはissuePO、approvePOおよびcancelPOメソッドが必要です。 それは、私がオブジェクト指向の基礎として理解している「凝集を最大化する」と「結合を最小化する」という古くからの原則とは関係ないのでしょうか？ それに、それはクラスの保守性に役立ちませんか？
6
関数型言語を学ぶことは、より良いOOPプログラマーになりますか？[閉まっている]
Java / C＃/ C ++プログラマーとして、関数型言語について多くの話を聞いていますが、関数型言語を学ぶ必要はありません。関数型言語で導入されたより高いレベルの思考が、より優れたOOP /手続き型言語のプログラマーになると聞いたことがあります。 誰でもこれを確認できますか？どのような点でプログラミングスキルが向上しますか？ それほど洗練されていない言語でスキルを向上させることを目標に学習する言語の適切な選択は何ですか？
6
基本型（intなど）をクラスとして実装する場合の注意点は何ですか？
オブジェクト指向プログラミング言語を設計し、implentingすると、いくつかの点で1が基本型（のような実装の選択をする必要がありint、float、doubleクラスまたは何か他のものとして、または同等の）。明らかに、Cファミリーの言語はそれらをクラスとして定義しない傾向があります（Javaには特別なプリミティブ型があり、C＃はそれらを不変の構造体として実装します）。 基本型が（統一された階層を持つ型システムで）クラスとして実装される場合、非常に重要な利点を考えることができます。これらの型は、ルート型の適切なLiskovサブタイプになります。したがって、ボクシング/アンボクシング（明示的または暗黙的）、ラッパータイプ、特別な分散ルール、特別な動作などで言語を複雑にすることは避けます。 もちろん、言語デザイナーがその方法を決定する理由を部分的に理解することができます：クラスインスタンスは、空間のオーバーヘッドを持っている傾向がある（インスタンスのメモリレイアウトにvtableまたはその他のメタデータが含まれている可能性があるため） have（言語がそれらの継承を許可しない場合） 基本型がクラスではないことが多いのは、空間効率（および特に大きな配列での空間的局所性の向上）だけですか？ 私は一般的に答えがイエスであると仮定しましたが、コンパイラにはエスケープ分析アルゴリズムがあり、インスタンス（基本タイプだけでなく任意のインスタンス）が厳密に証明されたときに空間的オーバーヘッドを（選択的に）省略できるかどうかを推測できます地元。 上記は間違っていますか、それとも私が見逃しているものがありますか？
7
関数型プログラミングは、「システムをモジュールに分解する際に使用される基準について」（データの隠蔽）から得られる利点を無視しますか？
「システムをモジュールに分解する際に使用する基準について」という古典的な記事がありますが、これは初めて読んだばかりです。それは私にとって完全に理にかなっており、おそらくOOPのベースとなった記事の1つです。その結論： これらの例により、フローチャートに基づいてシステムのモジュールへの分解を開始することはほとんど常に間違っていることを実証しようとしました。...各モジュールは、そのような決定を他のモジュールから隠すように設計されています 私の無学で経験の浅い意見では、関数型プログラミングはこの記事の正反対のアドバイスを取ります。私の理解では、関数型プログラミングはデータフローを慣用的にします。データは関数から関数に渡され、各関数はデータを密接に認識し、途中で「変更」します。そして、データの隠蔽が過大評価されているか、不必要であるか、または何かについて話しているリッチヒッキーのトークを見たことがあると思いますが、確かに思い出せません。 まず、私の評価が正しいかどうか知りたいです。FPパラダイムとこの記事は哲学的に同意しませんか？ 彼らが同意しないと仮定すると、FPはデータ隠蔽の欠如をどのように「補償」しますか？おそらく、データ隠蔽を犠牲にしてX、Y、およびZを獲得する可能性があります。X、Y、およびZがデータ隠蔽よりも有益である理由を知りたいのです。 または、両者が同意しないと仮定すると、FPはデータの非表示が悪いと感じるかもしれません。もしそうなら、なぜデータ隠蔽が悪いと思うのですか？ 彼らが同意すると仮定して、FPがデータ隠蔽の実装とは何かを知りたいです。OOPでこれを見るのは明らかです。privateクラス外の誰もアクセスできないフィールドを持つことができます。FPの場合、これについての明らかな類推はありません。 質問すべき他の質問もあると思いますが、質問すべきかはわかりません。それらにも自由に答えてください。 更新 このNeal Fordの講演には、非常に関連性の高いスライドが含まれています。ここにスクリーンショットを埋め込みます。
9
リスコフの代替原則に違反した場合、何が問題になる可能性がありますか？
私は、リスコフ代替原理の違反の可能性について、この非常に投票された質問に従っていました。Liskov Substitutionの原則が何であるかは知っていますが、開発者としてオブジェクト指向コードを書いている間にこの原則を考えないと、何が間違っているのかが私の心ではまだはっきりしていません。
12
ソリッドと早すぎる抽象化の回避
SOLIDが何を達成することになっているのかを理解し、モジュール性が重要であり、その目標が明らかに役立つ状況で定期的に使用します。ただし、次の2つの理由により、コードベース全体に一貫して適用できません。 時期尚早な抽象化を避けたい。私の経験では、具体的なユースケース（現在または近い将来に存在する種類）なしで抽象化ラインを描画すると、間違った場所に描画されます。このようなコードを変更しようとすると、抽象化ラインが助けになるのではなく邪魔になります。したがって、どこに有用なのかがよくわかるまで、抽象化ラインを描画しないという側面を誤解する傾向があります。 私のコードをより冗長にし、理解しにくくするなど、重複を排除しない場合、モジュール性を高めることを正当化するのは難しいと思います。フローが単純で線形であるため、非常に適切にファクタリングされたラビオリコードよりも、シンプルで密結合された手続き型またはGodオブジェクトコードの方が理解しやすい場合があります。書くのもずっと簡単です。 一方、この考え方はしばしば神の対象につながります。私は通常、これらを控えめにリファクタリングし、明確なパターンが出現する場合にのみ明確な抽象化ラインを追加します。明らかにモジュール性を必要とせず、大幅な重複がなく、コードが読み取り可能な場合、Godオブジェクトと密結合コードで何か問題があるとしたらどうでしょうか。 編集：個々のSOLID原則に関しては、Liskov Substitutionは常識の形式化であり、どこにでも適用されるべきであると強調するつもりでした。また、すべてのクラスは、何らかの抽象化レベルで単一の責任を負う必要がありますが、実装の詳細がすべて1つの巨大な2,000行クラスに詰め込まれた非常に高いレベルかもしれません。基本的に、抽象化は、抽象化を選択した場所で意味をなす必要があります。モジュール性が明確に役に立たない場合に私が疑問に思う原則は、オープンクローズ、インターフェース分離、特に依存関係の逆転です。これらは抽象化が意味をなさないだけでなく、モジュール性に関するものだからです。
14
大規模な非OOコードベースはどのくらい管理されますか？
抽象化は、コードベースを管理するためにオブジェクト指向が提供する非常に便利な機能であるといつも思っています。しかし、大規模な非OOコードベースはどのように管理されていますか？または、それらは最終的に「泥の大玉」になりますか？ 更新： 「抽象化」は単なるモジュール化またはデータ隠蔽であると誰もが考えているようです。しかし、私見、それはまた、依存関係の注入とテストのために必須である「抽象クラス」または「インターフェース」の使用を意味します。非OOコードベースはこれをどのように管理しますか？また、抽象化以外に、カプセル化は、データと関数の間の関係を定義および制限するため、大規模なコードベースの管理にも役立ちます。 Cでは、疑似OOコードを書くことが非常に可能です。他の非OO言語についてはあまり知りません。だから、それは大規模なCコードベースを管理する方法ですか？
8
SOLID原則の一部またはすべてがコードをきれいにするのに相反するOOPのフレーバーはありますか？
私は最近、ビデオゲーム開発におけるOOPについて友人と議論しました。 友人の驚いたことに、多くの小さなクラスといくつかの抽象化レイヤーを含むゲームのアーキテクチャを説明していました。これは、すべてに単一の責任を与え、コンポーネント間の結合を緩めることに集中した結果だと主張しました。 彼の懸念は、多数のクラスがメンテナンスの悪夢につながることでした。私の見解では、それはまったく逆の効果をもたらすだろうということでした。何世紀にもわたって思われたものについてこれについて議論を続け、最終的には同意しないことに同意し、SOLID原則と適切なOOPが実際にうまく混合されない場合があったと考えています。 SOLID原則に関するWikipediaのエントリでさえ、それらは保守可能なコードの作成を支援するガイドラインであり、アジャイルおよび適応プログラミングの全体的な戦略の一部であると述べています。 だから、私の質問は： OOPで、SOLID原則の一部またはすべてがコードのクリーン化に役立たない場合はありますか？ Liskov Substitution Principleが安全な継承の別のフレーバーと競合する可能性があることはすぐに想像できます。つまり、誰かが継承を通じて実装された別の有用なパターンを考案した場合、LSPがそれと直接競合する可能性が非常に高いです。 他にありますか？おそらく、特定のタイプのプロジェクトまたは特定のターゲットプラットフォームは、より少ないソリッドアプローチでより適切に機能しますか？ 編集： 私は自分のコードを改善する方法を尋ねていないことを指定したいだけです;）私がこの質問でプロジェクトに言及した唯一の理由は、少しコンテキストを与えることでした。私の質問は、一般的に OOPと設計原則についてです。 あなたは私のプロジェクトについて興味している場合は、参照これを。 編集2： この質問には、次の3つの方法のいずれかで答えると思いました。 はい、SOLIDと部分的に競合するOOP設計原則が存在します はい、SOLIDと完全に競合するOOP設計原則が存在します いいえ、SOLIDはミツバチのひざであり、OOPは永遠に優れています。しかし、すべてと同様に、万能薬ではありません。責任を持って飲んでください。 オプション1と2は、長くて興味深い回答を生成する可能性があります。一方、オプション3は、短くて面白くないが、全体的に安心できる答えです。 オプション3に収束しているようです。
6
関数型プログラミングはオブジェクト指向のスーパーセットですか？
私がより機能的なプログラミングをすればするほど、タマネギのレイヤーが以前のレイヤーをすべて包含しているように見える、抽象化のレイヤーが追加されたように感じます。 私はこれが本当かどうかわからないので、私が長年取り組んできたOOP原則から外れると、誰もそれらがどれほど正確に機能するかを説明できます：カプセル化、抽象化、継承、多態性 私たちは皆、タプルを介してカプセル化されていると言うことができると思いますか、タプルは技術的に「関数型プログラミング」の事実としてカウントされますか、それとも単に言語のユーティリティですか？ Haskellが「インターフェース」の要件を満たすことができることは知っていますが、メソッドが機能するかどうかは確かではありませんか？ファンクターが数学的な基礎を持っているという事実は、おそらく機能的な期待に基づいて構築されていると思いますか？ 機能的にOOPの4つの原則を満たしている、または満たしていないと思う方法を詳しく説明してください。 編集：私は機能的パラダイムとオブジェクト指向パラダイムの違いをうまく理解しており、最近では両方を実行できるマルチパラダイム言語がたくさんあることを認識しています。私は本当に、完全なfp（haskellのような純粋主義者と考えてください）がリストされた4つのことのどれを行うことができるか、またはなぜそれらのいずれもできないのかの定義を探しています。すなわち、「カプセル化はクロージャを使用して行うことができます」（またはこの信念に誤りがある場合は、理由を述べてください）。
5
オブジェクト指向プログラムを機能的なものにリファクタリングする方法は？
機能的なスタイルでプログラムを作成する方法に関するリソースを見つけるのが困難です。オンラインで議論された最も高度なトピックは、構造型付けを使用してクラス階層を削減することでした。ほとんどはmap / fold / reduce / etcを使用して命令型ループを置き換える方法を扱っています。 私が本当に見つけたいのは、自明ではないプログラムのOOP実装、その制限、およびそれを機能的なスタイルにリファクタリングする方法についての詳細な議論です。アルゴリズムやデータ構造だけでなく、いくつかの異なる役割と側面を持つもの-ビデオゲームかもしれません。ちなみに、私はTomas PetricekによるReal-World Functional Programmingを読みましたが、もっと欲しいと思っています。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.