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

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

4
それでは、「オブジェクト指向」という用語でアランケイが本当に意味したことは何ですか？
伝えられるところによれば、アラン・ケイは「オブジェクト指向」という用語の発明者です。そして彼はしばしば、今日私たちがOOと呼ぶものは彼が意味するものではないと言ったと引用されています。 たとえば、Googleでこれを見つけました。 「オブジェクト指向」という用語を作成しましたが、C ++を念頭に置いていなかったことがわかります。 -アラン・ケイ、OOPSLA '97 私は彼が何をしたかについてかなり洞察に満ちた何かを聞いたことを漠然と覚えています。「メッセージの受け渡し」に沿った何か。 彼の意味を知っていますか？彼が何を意味し、今日の一般的なオブジェクト指向とどのように異なるのか、詳細を記入できますか？参照がある場合は共有してください。 ありがとう。
10
OOPのゼロ動作オブジェクト-私の設計のジレンマ
OOPの背後にある基本的な考え方は、データと動作（そのデータに基づく）は不可分であり、クラスのオブジェクトの考え方によって結合されるということです。オブジェクトには、それ（およびその他のデータ）で機能するデータとメソッドがあります。明らかに、OOPの原則により、単なるデータであるオブジェクト（C構造体など）はアンチパターンと見なされます。 ここまでは順調ですね。 問題は、私のコードが最近このアンチパターンの方向にますます進んでいるように見えることに気づいたことです。クラスと疎結合設計の間の情報隠蔽を達成しようとすればするほど、私のクラスは、動作クラスのない純粋なデータとデータクラスのないすべての動作の混合になります。 私は通常、他のクラスの存在に対する認識を最小限に抑え、他のクラスのインターフェイスに関する知識を最小限に抑える方法でクラスを設計します。特にトップダウン方式でこれを実施します。低レベルのクラスは高レベルのクラスについては知りません。例えば： 一般的なカードゲームAPIがあるとします。あなたにはクラスがありCardます。ここで、このCardクラスはプレーヤーの可視性を決定する必要があります。 1つの方法はboolean isVisible(Player p)、Cardクラスに参加することです。 もう1つはboolean isVisible(Card c)、Playerクラスに参加することです。 特に、最初のアプローチは嫌いです。なぜなら、より高いレベルのPlayerクラスに関する知識をより低いレベルのCardクラスに与えるからです。 代わりに、3番目のオプションを選択しました。このViewportクラスでは、指定Playerされたカードとカードのリストによって、どのカードが表示されるかが決まります。 ただし、このアプローチは、可能なメンバー関数の両方CardとPlayerクラスを奪います。カードの可視性以外のものに対してこれを行うとCard、Playerすべての機能が他のクラスで実装されているため、純粋にデータを含むクラスが残りますViewport。 これは、OOPの基本的な考え方に明らかに反しています。 正しい方法はどれですか？クラスの相互依存関係を最小化し、想定される知識と結合を最小化するが、すべての低レベルクラスにデータのみが含まれ、高レベルクラスにすべてのメソッドが含まれるという奇妙なデザインに巻き込まれないようにするにはどうすればよいですか？全体の問題を回避するクラス設計に関する3番目の解決策や視点はありますか？ PS別の例を示します。 DocumentId不変で、単一のBigDecimal idメンバーとこのメンバーのゲッターのみを持つクラスがあるとします。ここで、データベースからこのidをDocumentId返すメソッドをどこかに持つ必要がありDocumentます。 あなたは： クラスにDocument getDocument(SqlSession)メソッドを追加しDocumentId、永続性に関する知識（"we're using a database and this query is used to retrieve document by id"）、DBへのアクセスに使用されるAPI などを突然導入します。また、このクラスでは、コンパイルするために永続性JARファイルが必要になりました。 この方法でいくつかの他のクラスを追加しDocument getDocument(DocumentId id)たまま、DocumentId死んだ、いや行動、構造体のようなクラスとしてクラスを。
12
Cが「オブジェクト指向」言語と見なされないのはなぜですか？
Cには、オブジェクトと見なすことができる「構造」などの独自の準オブジェクトがあるようです（通常は高レベルの方法で考えられます）。 また、Cファイル自体は基本的に別個の「モジュール」ですよね？モジュールも「オブジェクト」のようなものではありませんか？C ++に非常に似ているCが、C ++が高レベルの「オブジェクト指向」である低レベルの「手続き型」言語と見なされる理由について混乱しています *編集：（説明）なぜ、どこで、「オブジェクト」が何のために、そして何のために線が引かれているのか？
22
OOPが難しいのはなぜですか？[閉まっている]
オブジェクト指向言語（Java）を使い始めたとき、私はほとんど「クール」になり、コーディングを始めました。OOPについて多くの質問を読んだ後、つい最近まで本当に考えたことはありませんでした。私が得る一般的な印象は、人々がそれに苦しんでいることです。私はそれを一生懸命だとは思っていないし、天才だとは言わないので、何かを見逃したか、誤解したに違いないと思っています。 OOPの理解が難しいのはなぜですか？理解するのは難しいですか？
15
OOPの時代にCがこれほど人気が​​あるのはなぜですか？[閉まっている]
私はCとC ++の両方で多くのコードを記述しましたが、CがJavaにやや遅れて2番目に人気のある言語になるとは思いませんでした。 TIOBEプログラミングコミュニティインデックス 私は、OOPのこの時代に、Cがまだとても人気がある理由について興味がありますか？人気のあるプログラミング言語の上位5つのうち4つは、「現代の」オブジェクト指向対応言語です。 さて、CでOOPをある程度使用できることに同意しますが、それはある種の苦痛で洗練されていません（少なくともC ++とはかなり違います）。それでは、何がCをそんなに人気にしているのでしょうか？効率ですか？低レベルである; すでに存在するライブラリの大部分または他の何か？
22
OOPは自然ではないので難しいですか？
多くの場合、OOPは自然に人々が世界について考える方法に対応していると聞きます。しかし、私はこの声明に強く反対します：私たち（または少なくとも私は）遭遇するものの間の関係の観点から世界を概念化しますが、OOPの焦点は個々のクラスとその階層を設計することです。 日常生活では、OOPの無関係なクラスのインスタンスになるはずのオブジェクト間に、ほとんどの関係とアクションが存在することに注意してください。このような関係の例は次のとおりです。「私の画面はテーブルの上にあります」。「私（人間）は椅子に座っています」; 「車が道路にあります」; 「キーボードで入力しています」。「コーヒーマシンは水を沸かす」、「テキストはターミナルウィンドウに表示される」。 動詞が2つのオブジェクトに作用して何らかの結果/アクションを生成するアクション（関係）である2価（たとえば、「私はあなたに花を贈った」など）の動詞の観点で考えます。フォーカスがアクションであり、2つ（または3つ）の文法上の】オブジェクトが等しく重要です。 それとは対照的に、最初に1つのオブジェクト（名詞）を見つけて、別のオブジェクトに対して何らかのアクションを実行するように指示する必要があるOOPとは対照的です。考え方は、名詞で動作するアクション/動詞から名詞で動作する名詞にシフトします。これは、すべてが受動的または再帰的な音声で言われているようです。たとえば、「テキストはターミナルウィンドウで表示されています」。または、「テキストは端末ウィンドウに表示されます」。 焦点が名詞にシフトされるだけでなく、名詞の1つ（文法主題と呼びましょう）には、他の名詞（文法オブジェクト）よりも高い「重要性」が与えられます。したがって、terminalWindow.show（someText）とsomeText.show（terminalWindow）のどちらを言うかを決定する必要があります。しかし、実際にshow（terminalWindow、someText）を意味するのに、操作に影響を与えることなく、このような些細な決定を人々に負わせるのはなぜですか？[結果は操作上重要ではありません。どちらの場合もテキストはターミナルウィンドウに表示されますが、クラス階層の設計において非常に深刻な場合があり、「間違った」選択は複雑で保守が難しいコードになります。 したがって、OOP（クラスベース、シングルディスパッチ）を行う主流の方法は難しく、それは非自然的であり、人間の世界に対する考え方に対応していないためです。CLOSの汎用メソッドは私の考え方に近いものですが、残念ながら、これは一般的なアプローチではありません。 これらの問題を考えると、OOPを行う現在の主流の方法が非常に一般的になったのはどうしてですか。そして、もしあれば、それを退位させるために何ができるでしょうか？
10
ゲッターとセッターをどのように回避しますか？
私は、オブジェクト指向の方法でクラスを設計するのに苦労しています。オブジェクトは、データではなく動作を公開することを読みました。したがって、ゲッター/セッターを使用してデータを変更するのではなく、特定のクラスのメソッドは「動詞」またはオブジェクトで動作するアクションでなければなりません。たとえば、「Account」オブジェクトには、etcなどWithdraw()でDeposit()はなくメソッドなどがありますsetAmount()。ゲッターメソッドとセッターメソッドが悪である理由を参照してください。 たとえば、Name、DOB、Tel、Addressなど、顧客に関する多くの情報を保持するCustomerクラスがある場合、これらすべての属性を取得および設定するゲッター/セッターを回避するにはどうすればよいでしょうか？すべてのデータを取り込むためにどのような「動作」タイプのメソッドを記述できますか？
4
リッチドメインモデル—正確に、動作はどのように適合しますか？
リッチドメインモデルと貧血ドメインモデルの議論では、インターネットは哲学的なアドバイスに満ちていますが、権威のある例は不足しています。この質問の目的は、適切なドメイン駆動設計モデルの決定的なガイドラインと具体例を見つけることです。（理想的にはC＃で。） 実際の例では、このDDDの実装は間違っているようです。 以下のWorkItemドメインモデルは、Entity Frameworkがコードファーストデータベースに使用するプロパティバッグに他なりません。ファウラーごとに、それは貧血です。 WorkItemService層は、明らかにドメインサービスの一般的な誤解です。WorkItemのすべての動作/ビジネスロジックが含まれています。イェメリャノフなどによると、手続き型です。（ページ6） 以下が間違っている場合、どうすれば正しくできますか？AddStatusUpdateまたはCheckoutなど の動作はWorkItemクラスに属している必要がありますか？ WorkItemモデルにはどのような依存関係が必要ですか？ public class WorkItemService : IWorkItemService { private IUnitOfWorkFactory _unitOfWorkFactory; //using Unity for dependency injection public WorkItemService(IUnitOfWorkFactory unitOfWorkFactory) { _unitOfWorkFactory = unitOfWorkFactory; } public void AddStatusUpdate(int workItemId, int statusId) { using (var unitOfWork = _unitOfWorkFactory.GetUnitOfWork<IWorkItemUnitOfWork>()) { var workItemRepo = unitOfWork.WorkItemRepository; var workItemStatusRepo = …
13
OOPのオブジェクトはエンティティを表す必要がありますか？
オブジェクトはエンティティを表す必要がありますか？ エンティティ私のような何かを意味Product、Motor、ParkingLotなど、物理的、あるいは明確な非物理的な概念オブジェクト-だけでなく、いくつかのコアデータは明らかにオブジェクトに属していると、定義されているもの、およびいくつかの関数/メソッドコアデータを明確に操作します。 たとえば、aのオブジェクトDemon、それ自体のエンティティ、想像上のオブジェクト、おそらく物理的ではなくエンティティを持つことができます オブジェクトは、メソッドのコレクション、共通の目標に結び付く共通のプロシージャセットになりますか？ 例：クラスを呼び出すことができるMotorOperationsか、MotorActionsそこには実体ではありませんが、クラス内のメソッドは次のようなことを行う場合には、 getMotorDataFromHTMLForm（） getMotorManufacturers（） selectMotorFromUserRequirements（$ requirements） canMotorCanHandleOperatingConditions（$ conditions） computePowerConsumptionForMotor（$ id） クラスは通常、オブジェクトの中心となるデータ+データの操作として定義されます。そのため、Motorモーターの仕様に関連するいくつかのモーター変数があり、それらのデータを組み合わせて何かを生成する操作があります。 私の場合、データを操作するクラスとクラスを通過するデータを持っているようなもので、一時的なクラススルーデータ以外に「モーター操作」を中心としたデータはありません。 質問 クラスはエンティティのないオブジェクトを表すことができますか？そうでない場合、なぜそれらは悪い/不完全/非OOP中心ですか？OOPに合わせて概念的に変更/改善する必要がある方法はありますか？
2
Javascriptに実際に適用可能なオブジェクト指向の原則はありますか？
Javascriptはプロトタイプベースのオブジェクト指向言語ですが、次のいずれかの方法により、さまざまな方法でクラスベースになります。 自分でクラスとして使用する関数を書く フレームワークで気の利いたクラスシステムを使用する（mootools Class.Classなど） Coffeescriptから生成する 最初はJavascriptでクラスベースのコードを書く傾向があり、それに大きく依存していました。しかし最近、私はJavascriptフレームワークとNodeJSを使用していますが、これらはクラスの概念から離れ、次のようなコードの動的な性質により依存しています。 非同期プログラミング、コールバック/イベントを使用するコードの作成と使用 RequireJSを使用したモジュールのロード（グローバルネームスペースにリークしないようにするため） リスト内包表記（マップ、フィルターなど）などの関数型プログラミングの概念 とりわけ これまでに収集したことは、私が読んだほとんどのオブジェクト指向の原則とパターン（SOLIDやGoFパターンなど）は、SmalltalkやC ++のようなクラスベースのオブジェクト指向言語向けに書かれたものです。しかし、Javascriptなどのプロトタイプベースの言語に適用可能なものはありますか？ Javascriptに固有の原則やパターンはありますか？コールバックの地獄、悪の評価、またはその他のアンチパターンなどを避けるための原則
12
手続き型プログラミングに対するオブジェクト指向プログラミングの利点は何ですか？
Cのような手続き型言語とC ++のようなオブジェクト指向言語の違いを理解しようとしています。私はC ++を使用したことはありませんが、2つを区別する方法について友人と話し合ってきました。 C ++には変数を定義するためのパブリックモードとプライベートモードだけでなく、オブジェクト指向の概念もあると言われています。Cにはないものです。Visual Basic.NETでプログラムを開発する際にこれらを使用する必要はありませんでした。これらの利点は何ですか？ また、変数がパブリックであればどこからでもアクセスできると言われましたが、Cのような言語のグローバル変数とどのように異なるのかは明確ではありません。プライベート変数がローカル変数とどのように異なるのかも明確ではありません。 私が聞いたもう一つのことは、セキュリティ上の理由から、関数にアクセスする必要がある場合、最初に関数を継承する必要があるということです。ユースケースは、管理者がすべてではなく必要なだけの権限を持っている必要があることですが、条件付きでもうまくいくようです： if ( login == "admin") { // invoke the function } なぜこれが理想的ではないのですか？ オブジェクト指向のすべてを行うための手続き的な方法があるように思えるのに、なぜオブジェクト指向のプログラミングを気にしなければならないのですか？
11
C ++ですべてのオブジェクトに対応するベースが推奨されない理由
Stroustrup氏は、「すべてのクラス（Objectクラス）に一意のベースをすぐに発明しないでください。通常、多くの/ほとんどのクラスでそれを使用せずに改善できます。」（C ++プログラミング言語Fourth Edition、Sec 1.3.4） 一般に、すべてを対象とする基本クラスが悪い考えであるのはなぜですか？また、いつ作成するのが理にかなっていますか？
4
多くのソフトウェア開発者がなぜオープン/クローズド原則に違反するのですか？
多くのソフトウェア開発者が、アップグレード後にアプリケーションを破壊する関数の名前を変更するなど、多くのことを変更することにより、オープン/クローズの原則に違反するのはなぜですか？ この質問は、Reactライブラリの高速バージョンと継続バージョンの後に私の頭に飛びつきます。 短い期間ごとに、構文、コンポーネント名などに多くの変更があります。 Reactの今後のバージョンの例： 新しい非推奨の警告 最大の変更点は、React.PropTypesとReact.createClassを独自のパッケージに抽出したことです。どちらもメインのReactオブジェクトを介して引き続きアクセスできますが、いずれかを使用すると、開発モードのときに1回限りの非推奨警告がコンソールに記録されます。これにより、将来のコードサイズの最適化が可能になります。 これらの警告は、アプリケーションの動作には影響しません。ただし、特にconsole.errorを失敗として扱うテストフレームワークを使用している場合、フラストレーションが発生する可能性があることを認識しています。 これらの変更はその原則の違反と見なされますか？ Reactのようなものの初心者として、ライブラリ内のこれらの高速な変更でどのようにそれを学ぶのですか（とてもイライラします）？
7
プライベート静的メソッドがあるのはなぜですか？
質問を解決したかっただけです。プライベートな可視性を持つ通常のメソッドとは対照的に、プライベートな静的メソッドを持つことのポイントは何ですか？ 静的メソッドを持つことの利点は、クラスのインスタンスなしで呼び出すことができることだと思っていましたが、そのプライベートは静的であるというポイントさえありますか？ 私が考えることができる唯一の理由は、オブジェクトレベルではなく、クラスレベルでメソッドを概念的に理解するのに役立つということです。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.