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

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

9
ポリモーフィズムは実際の世界でどのように使用されていますか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 昨年は閉店しました。 私は実際のプロジェクトで多態性がどのように使用されているかを理解しようとしていますAnimalが、method を持つ親クラスと、speak()このメソッドをオーバーライドする多くの子クラスを持つ古典的な例(またはそれに似たもの)しか見つけることができません次のように、speak()任意の子オブジェクトでメソッドを呼び出すことができます。 Animal animal; animal = dog; animal.speak(); animal = cat; animal.speak();

7
インスタンス作成がそのままなのはなぜですか?
私は過去6か月ほどの間にC#を学び、現在はJavaを掘り下げています。私の質問は、インスタンスの作成に関するものです(どちらの言語でも)、それはもっと多くのことです。この例を取ります Person Bob = new Person(); オブジェクトが2回指定されている理由はありますか?ありsomething_else Bob = new Person()ますか? 私が慣習に従っているなら、もっと似ているように思えます: int XIsAnInt; Person BobIsAPerson; または、おそらく次のいずれかです。 Person() Bob; new Person Bob; new Person() Bob; Bob = new Person(); 「それがまさに行われている方法」よりも良い答えがあるかどうか興味があります。

4
実装(HashMap)ではなくインターフェイス(Mapなど)を使用してJavaオブジェクトを定義する理由
ほとんどのJavaコードでは、次のようにJavaオブジェクトを宣言する人がいます。 Map<String, String> hashMap = new HashMap<>(); List<String> list = new ArrayList<>(); の代わりに: HashMap<String, String> hashMap = new HashMap<>(); ArrayList<String> list = new ArrayList<>(); 実際に使用される実装ではなく、インターフェースを使用してJavaオブジェクトを定義する設定があるのはなぜですか?

5
インターフェイスを使用する場合(ユニットテスト、IoC?)
私はここで男子学生の間違いを犯したのではないかと疑い、明確化を求めています。私のソリューションの多くのクラス(C#)-あえて過半数を言う-私は対応するインターフェースを書くことになりました。たとえば、「ICalculator」インターフェースと、それを実装する「Calculator」クラス。ただし、その計算機を別の実装に置き換えることは決してないでしょう。また、これらのクラスのほとんどは、依存関係と同じプロジェクトに存在します。実際に必要なのはinternal、必要なだけですが、publicそれぞれのインターフェイスを実装する副作用として存在することになりました。 すべてのインターフェイスを作成するこのプラクティスは、いくつかの偽りに起因すると思います。 1)元々、ユニットテストモックを作成するにはインターフェイスが必要だと思っていました(私はMoqを使用しています)が、その後、そのメンバーがvirtualであり、パラメーターのないコンストラクターがある場合、クラスをモックできることがわかりました(私が間違っている)。 2)IoCフレームワーク(Castle Windsor)にクラスを登録するにはインターフェースが必要だと当初考えていました。例えば Container.Register(Component.For<ICalculator>().ImplementedBy<Calculator>()... 実際、私はそれ自体に対して具体的な型を登録することができました: Container.Register(Component.For<Calculator>().ImplementedBy<Calculator>()... 3)依存性注入のコンストラクタパラメーターなどのインターフェイスを使用すると、「疎結合」になります。 それで、私はインターフェースに夢中になりましたか?!私は、あなたが「通常」インターフェースを使用するシナリオを知っています。例えば、パブリックAPIを公開したり、「プラグイン可能な」機能のようなもののために。私のソリューションには、そのようなユースケースに適合する少数のクラスがありますが、他のすべてのインターフェースは不要であり、削除する必要があるのでしょうか?上記の3)に関して、これを行う場合、「疎結合」に違反しませんか? 編集:-Moqで遊んでいるだけであり、それらをモックできるようにするには、メソッドがパブリックで仮想であり、パブリックのパラメータレスコンストラクターを必要とするようです。それで、私は内部クラスを持つことができないように見えますか?

6
アヒルは多型のサブセットを入力しています
WIkipediaの多態性から コンピュータサイエンスでは、ポリモーフィズムはプログラミング言語の機能であり、さまざまなデータ型の値を統一されたインターフェイスを使用して処理できます。 ウィキペディアのカモタイピングから オブジェクト指向プログラミング言語を使用したコンピュータープログラミングでは、ダックタイピングは、特定のクラスまたは特定のインターフェイスの実装からの継承ではなく、オブジェクトの現在のメソッドとプロパティのセットが有効なセマンティクスを決定する動的なタイピングのスタイルです。 私の解釈では、アヒルのタイピングに基づいて、オブジェクトのメソッド/プロパティが有効なセマンティクスを決定します。オブジェクトの現在の形状が、保持するインターフェースを決定することを意味します。 ポリモーフィズムから、インターフェイスを維持している限り、複数の異なるデータ型を受け入れる場合、関数はポリモーフィックであると言えます。 したがって、関数が型をダッキングできる場合、複数の異なるデータ型を受け入れ、それらのデータ型に正しいメソッド/プロパティがあり、インターフェースを維持している限り、それらを操作できます。 (インターフェースという用語の使用は、コード構成ではなく、記述的で文書化された構成としての意味です) ダックタイピングとポリモーフィズムの正しい関係は何ですか? 言語がタイプをダッキングできる場合、それは多態性を実行できることを意味しますか?

5
SRP(単一責任原則)は客観的ですか?
「ユーザーにとって魅力的な」デザインをデザインしたい2人のUIデザイナーを考えてみましょう。「ユーザーの魅力」は、客観的ではなく、デザイナーの心の中にのみ存在する概念です。したがって、デザイナーAはたとえば赤を選択し、デザイナーBは青を選択できます。デザイナーAは、デザイナーBとはまったく異なるレイアウトを作成します。 SRP(Single Responsibility Principle)について読みましたが、私が理解したのは、OOデザイナーから別のOOデザイナーまでさまざまな主観的な分析または責任の内訳です。私は正しいですか?言い換えれば、SRPプリンシパルに基づいて1つのシステムに対して2つの異なる設計を思いつく2つの優れたオブジェクト指向アナライザーとデザイナーを使用することは可能ですか?

5
経験豊富なC ++エンジニアのチームにOOP / OODを「導入」する最良の方法
私は、OOPの概念を既存のチームメンバーに紹介するための、efficient辱としても抜け落ちない効率的な方法を探していますか?私のチームメイトはオブジェクト指向言語に慣れていません。私たちは長い間C ++ / C#を行ってきたので、テクノロジー自体はよく知られています。 しかし、私は周りを見回し、努力の大きな注入なしで(主にコードレビューの形で)、私たちが作り出しているのはクラス内にあるCコードです。いくつか例を挙げると、単一の責任原則、抽象化、結合を最小限に抑える試みはほとんど使用されていません。コンストラクターはないが、インスタンス化されるたびにmemsetを0にするクラスを見てきました。 しかし、私がOOPを立ち上げるたびに、誰もがうなずき、私が話していることを正確に知っているように見えます。概念を知ることは良いことですが、実際の作業の提供に関しては、私たち(他の人よりも)を適用するのは非常に困難です。 コードレビューは非常に役立ちましたが、コードレビューの問題は、事実の後にのみ発生することです。そのため、一部の人にとっては、書き直されたコード(ほとんどはリファクタリングですが、多くの時間がかかります)になります。また、コードレビューは、チーム全体ではなく、個々のエンジニアにのみフィードバックを提供します。 私は、プレゼンテーション(またはシリーズ)を行うというアイデアをいじり、OOPを、より良く記述でき、リファクタリングできる既存のコードの例とともに再び表示しようとしています。誰ももう所有していないいくつかの本当に古いプロジェクトを使うことができたので、少なくともその部分は微妙な問題ではないはずです。ただし、これは機能しますか?私が言ったように、ほとんどの人は長い間C ++をやっているので、a)彼らはそこに座って、なぜ彼らがすでに知っていることを言っているのかを考えているか、b)彼らは実際にそれをin辱として取るかもしれません数十年ではないとしても、長年やってきた仕事をどうやってやるのかわからないと伝えます。 コードレビューよりも幅広い聴衆に到達するが、同時に罰の講義のように感じない別のアプローチはありますか? 私は、完全に設計されたコードの理想的な理想を持っている大学の新鮮な子供ではありません。誰にも期待していません。私がこれを書いている理由は、紙の上にまともな高レベルのデザインを実際に持っている人のレビューをしたからです。ただし、クラスを想像する場合:A-> B-> C-> D、コードB、CおよびDはすべてほぼ同じパブリックインターフェイスを実装し、B / Cには1つのライナー関数があるため、最上位のクラスAは絶対に実行します主に4つのmongoメソッドでのすべての作業(メモリ管理、文字列解析、セットアップネゴシエーションなど)、およびすべての意図と目的のために、ほとんど直接Dを呼び出します。 更新:私は技術リーダー(この役職で6か月)であり、グループマネージャーを完全にサポートしています。私たちは非常に成熟した製品に取り組んでおり、メンテナンスコストは間違いなく知られています。

6
メソッド連鎖とカプセル化
メソッドチェーンと「単一アクセスポイント」メソッドの古典的なOOP問題があります。 main.getA().getB().getC().transmogrify(x, y) 対 main.getA().transmogrifyMyC(x, y) 最初の方法には、各クラスがより小さな操作セットのみを担当し、すべてをよりモジュール化するという利点があるようです-Cにメソッドを追加しても、A、B、またはCでそれを公開する労力は必要ありません。 もちろん、欠点はカプセル化が弱いことです。これは2番目のコードで解決されます。これで、Aはそれを通過するすべてのメソッドを制御し、必要に応じてフィールドに委任できます。 単一の解決策はなく、もちろんコンテキストに依存することはわかっていますが、2つのスタイルのその他の重要な違いについて、またどのような状況でどちらを好むべきかについて、いくつかの意見を聞きたいと思います。いくつかのコードを設計するために、引数を使用してどちらかの方法を決定していないように感じます。

11
オブジェクト指向プログラミングが成功した理由は何ですか?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 オブジェクト指向プログラミングをこれほど成功させたあなたによると、その機能は何ですか? メッセージの受け渡し 継承 多型 カプセル化 または紹介したい他の機能。 また、抽象データ型とオブジェクト指向プログラミングの関係は何ですか?


6
列挙型はコードの匂いではありませんか?
ジレンマ オブジェクト指向の実践に関するベストプラクティスの本をたくさん読んでいますが、読んだ本のほとんどすべてに、enumはコードの匂いだと言う部分がありました。列挙型が有効な場合に説明する部分を見逃したと思います。 そのように、私を探していますガイドラインおよび/またはユースケースの列挙型がありませ有効な構文コードのにおいと、実際に。 ソース: 「警告経験則として、列挙型はコードの匂いであり、多態性クラスにリファクタリングする必要があります。[8]」Seemann、Mark 、. 342 [8] Martin Fowler et al。、Refactoring:Improving the Design of Existing Code(New York:Addison-Wesley、1999)、82。 環境 私のジレンマの原因は取引APIです。このメソッドを介して送信することにより、Tickデータのストリームを提供します。 void TickPrice(TickType tickType, double value) どこ enum TickType { BuyPrice, BuyQuantity, LastPrice, LastQuantity, ... } 変更を壊すことがこのAPIの生き方であるため、このAPIのラッパーを作成しようとしました。ラッパーで最後に受信した各ティックタイプの値を追跡したいので、ダニタイプのディクショナリを使用してそれを行いました。 Dictionary<TickType,double> LastValues 私には、キーとして使用される場合、これは列挙型の適切な使用のように思えました。しかし、私はこのコレクションに基づいて意思決定を行う場所があり、switchステートメントを排除する方法を考えることができないため、工場を使用できますが、その工場にはまだどこかにswitchステートメント。私はただ物事を動かしているように見えましたが、まだ匂いがします。 列挙型のDO N'Tを見つけるのは簡単ですが、DOはそれほど簡単ではありません。人々が自分の専門知識、長所と短所を共有できるなら、私はそれを感謝します。 考え直し 一部の決定とアクションはこれらに基づいておりTickType、enum / switchステートメントを削除する方法を考えることはできないようです。私が考えることができる最もクリーンなソリューションは、ファクトリを使用し、に基づいて実装を返すことTickTypeです。それでも、インターフェイスの実装を返すswitchステートメントがあります。 以下は、間違った列挙型を使用しているのではないかと疑っているサンプルクラスの1つです。 public class ExecutionSimulator { …

4
共通フィールドを基本クラスに移動するタイミングは?
現在、2つの派生クラスがAあり、B、両方に共通のフィールドがあり、基本クラスに入れるかどうかを判断しようとしています。 基本クラスから参照されることはありません。また、道路のある時点で別のクラスが派生した場合C、を持たない場合、_field1「最低特権」(または何か)のプリンシパルは違反されませんだった? public abstract class Base { // Should _field1 be brought up to Base? //protected int Field1 { get; set; } } public class A : Base { private int _field1; } public class B : Base { private int _field1; } public class C : Base { // …

2
シリアル化と逆シリアル化は、シリアル化されるクラスの責任ですか?
現在、C#.NETアプリケーションのいくつかのモデルクラスの(再)設計段階にいます。(MVCのMのようなモデル)。モデルクラスには、適切に設計されたデータ、動作、および相互関係が十分にあります。モデルをPythonからC#に書き換えています。 古いPythonモデルでは、いぼが見えると思います。各モデルはそれ自体をシリアル化する方法を知っており、シリアル化ロジックはクラスの残りの動作とは関係ありません。たとえば、想像してみてください: Image.toJPG(String filePath) .fromJPG(String filePath)メソッドを持つクラス ImageMetaData.toString()and .fromString(String serialized)メソッドを持つクラス。 これらのシリアル化メソッドがクラスの他の部分と密接に結びついていないことを想像できますが、クラスだけがそれ自体をシリアル化するのに十分なデータを知っていることが保証されます。 クラスが自分自身をシリアル化および逆シリアル化する方法を知ることは一般的な習慣ですか?または、一般的なパターンが欠落していますか?

5
インターフェイス(OOP)のセマンティックコントラクトは、関数シグネチャ(FP)よりも有益ですか?
いくつかのことで言われて、あなたはそれらの極端にSOLID原則を取る場合、あなたは関数型プログラミングで終わります。この記事に同意しますが、インターフェイス/オブジェクトから関数/クロージャへの移行でいくつかのセマンティクスが失われると思うので、関数型プログラミングがどのように損失を軽減できるかを知りたいと思います。 記事から: さらに、インターフェイス分離の原則(ISP)を厳密に適用すると、ヘッダーインターフェイスよりもロールインターフェイスを優先する必要があることを理解できます。 デザインをどんどん小さなインターフェースに向けていくと、最終的には究極のロールインターフェース、つまり単一のメソッドを持つインターフェースに到達します。これは私によく起こります。以下に例を示します。 public interface IMessageQuery { string Read(int id); } に依存する場合IMessageQuery、暗黙の契約の一部は、呼び出しRead(id)が特定のIDのメッセージを検索して返すことです。 これを、同等の機能シグネチャである依存関係と比較してください int -> string。追加の手がかりがなければ、この関数は単純なものになりToString()ます。を実装IMessageQuery.Read(int id)したToString()場合、意図的に破壊されたと非難する可能性があります! それでは、機能的なプログラマは、名前の良いインターフェイスのセマンティクスを保持するために何ができるでしょうか?たとえば、単一のメンバーでレコードタイプを作成することは一般的ですか? type MessageQuery = { Read: int -> string }

2
継承、カプセル化、多型がOOPの柱ではないのはなぜですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 ある日、私はStack Overflowチャットに行って、継承、カプセル化、およびポリモーフィズムがOOPの柱であることを示すフレーズを見ました(それらは基本的なものであり、構築の唯一の意味です)。 また、大学の試験や就職の面接で頻繁に尋ねられる同様の質問があり、正しい答えは常に質問のタイトルで発音された声明でした(「はい、継承、カプセル化、多型はOOPの柱です)。 しかし、Stack Overflowチャットで私はひどく笑され、参加者はそのような声明に強く反対しました。それで、この声明の何が問題になっていますか? プログラマーはソビエト連邦後の大学とアメリカの大学で異なることを訓練されているように見えますか? 継承、カプセル化、およびポリモーフィズムは、US / UKプログラマーによるOOPの柱と見なされていませんか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.