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

本日、上級開発者から「ちなみに、switchステートメントを使用して関数をディスパッチすることに対するあなたの反対は何か」というコードレビューを受け取りました。私は、メソッドを呼び出してスイッチを介して引数をポンピングすることは悪いOOPであり、拡張性などではないことについて多くの場所で読んでいます。これを自分自身で解決したいと思います。 競合するコードの提案を次に示します（phpは例として使用されていますが、より普遍的に適用できます）。 class Switch { public function go($arg) { switch ($arg) { case "one": echo "one\n"; break; case "two": echo "two\n"; break; case "three": echo "three\n"; break; default: throw new Exception("Unknown call: $arg"); break; } } } class Oop { public function go_one() { echo "one\n"; } public function go_two() …

12 php  object-oriented 

私はかなり長い間手続き言語でプログラミングしてきましたが、問題に対する私の最初の反応は、存在するさまざまなエンティティ（オブジェクト）とそれらの関係を考慮するのではなく、実行するタスクに分解することです。 私はOOPで大学のコースを受講し、カプセル化、データ抽象化、多態性、モジュール性、継承の基礎を理解しています。 私が読ん/programming/2688910/learning-to-think-in-the-object-oriented-wayと/programming/1157847/learning-object-oriented-thinking、そして、それらの答えで指摘されている本のいくつかを見ていきます。 中規模から大規模のプロジェクトのいくつかは、OOPの効果的な使用から恩恵を受けると思いますが、初心者として、時間のかかる一般的なエラーを避けたいと思います。 あなたの経験に基づいて、これらの落とし穴は何ですか、そしてそれらの周りの合理的な方法は何ですか？それらが落とし穴である理由、およびあなたの提案が問題に対処するのにどのように効果的であるかを説明できれば、それは高く評価されるでしょう。 「かなりの数のオブザーバーとモディファイヤメソッドを持ち、プライベート変数を使用するのは一般的ですか、それともそれらを統合/削減する技術はありますか？」 メソッドを混在させる正当な理由がある場合、純粋なオブジェクト指向言語としてC ++を使用することは心配していません。（控えめではありますが、GOTOを使用する理由を連想させます。） ありがとうございました！

12 c++  object-oriented 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 C ++はオブジェクト指向プログラミングに適していないことを、ここでの質問に対する回答の1つで（どこにあるか覚えていない）読みました。あなたはその機能またはそのようなものを利用できるが、純粋にOOPの意味ではないという言及がありました（私は実際にその人の意味を本当に理解していませんでした）。 これにはいくつかの真実があります。もしそうなら、なぜですか？

12 c++  object-oriented 

私はプログラミングを始めたばかりで、さまざまなソースのさまざまな慣習を読んだり聞いたりすることから少し混乱しています。 オブジェクト指向プログラミングには4つまたは5つの概念がありますか？ 新参者として、私はこれらが5つの概念であることを理解しています： 抽象化 継承 カプセル化 多型 モジュール性 では、どうして「厳密な」定義が見つからず、これらの概念のいくつかのアレンジがそこにあるように思えますか？

12 object-oriented 

似たような質問がたくさんあります 1、2、3、4、ただし、この質問ではnonは当てはまらないようであり、解は最適とは思われません。 これは一般的なOOPの質問であり、多態性、ジェネリック、およびミックスインが利用可能であると仮定しています。実際に使用される言語はOOP Javascript（Typescript）ですが、JavaまたはC ++でも同じ問題です。 並列クラス階層があり、同じ動作（インターフェイスと実装）を共有することもありますが、それぞれに独自の「保護された」動作があります。次のように説明します。 これは、説明のみを目的としています。実際のクラス図ではありません。それを読むには： 共通階層（中心）のすべては、Canvas（左）階層とSVG（右）階層の両方で共有されます。シェアとは、インターフェースと実装の両方を意味します。 左または右の列にのみあるものは、その階層に固有の動作（メソッドとメンバー）を意味します。例えば： 左右の階層は、まったく同じ検証メカニズムを使用しViewee.validate()ます。これは、共通の階層で単一のメソッド（）として示されています。 キャンバス階層のみにメソッドがありpaint()ます。このメソッドは、すべての子に対してpaintメソッドを呼び出します。 SVG階層はのaddChild()メソッドをオーバーライドする必要がありますCompositeが、キャンバス階層の場合はそうではありません。 両側の階層の構造を混在させることはできません。工場はそれを保証します。 解決策I-継承を離れる Fowler's Tease Apart Inheritanceは、2つの類似点の間に矛盾があるため、ここでは役に立たないようです。 解決策II-ミックスイン これは私が現在考えることができる唯一のものです。2つの階層は別々に開発されますが、各レベルでクラスはクラス階層の一部ではない共通クラスに混在します。structuralフォークを省略すると、次のようになります。 各列は独自の名前空間にあるため、クラス名は競合しません。 質問 誰でもこのアプローチで障害を見ることができますか？誰もがより良い解決策を考えることができますか？ 補遺 これがどのように使用されるかを示すサンプルコードを次に示します。名前空間svgは次のように置き換えられますcanvas： var iView = document.getElementById( 'view' ), iKandinsky = new svg.Kandinsky(), iEpigone = new svg.Epigone(), iTonyBlair = new svg.TonyBlair( iView, iKandinsky ), iLayer = new svg.Layer(), …

12 design-patterns  object-oriented  inheritance  multiple-inheritance  mixins 

Dependency Inversion Principleが「実装ではなくインターフェイスへのプログラム」原則とどのように異なるかを理解しようとしています。 「実装ではなく、インターフェイスへのプログラム」の意味を理解しています。また、より柔軟で保守可能な設計を可能にする方法も理解しています。 しかし、依存関係反転の原則が「実装ではなくインターフェイスへのプログラム」の原則とどのように異なるかはわかりません。 Web上のいくつかの場所でDIPについて読みましたが、混乱は解消されませんでした。2つの原則がどのように異なるかはまだわかりません。ご協力いただきありがとうございます。

12 design  object-oriented  principles 

環境 オブジェクトの階層（式ツリー）で「疑似」ビジターパターン（二重ディスパッチを使用しないように疑似）を使用しています。 public interface MyInterface { void Accept(SomeClass operationClass); } public class MyImpl : MyInterface { public void Accept(SomeClass operationClass) { operationClass.DoSomething(); operationClass.DoSomethingElse(); // ... and so on ... } } ただし、MyInterfaceの実装の数は非常に多く（〜50以上）、余分な操作を追加する必要がないため、この設計は疑わしく、かなり快適でした。 各実装は一意であり（異なる式または演算子です）、一部は複合（つまり、他の演算子/リーフノードを含む演算子ノード）です。 トラバーサルは現在、ツリーのルートノードでAccept操作を呼び出すことによって実行され、その操作は、その子ノードのそれぞれでAcceptを呼び出します。 しかし、きれいな印刷などの新しい操作を追加する必要があるときが来ました。 public class MyImpl : MyInterface { // Property does not come from MyInterface public string …

12 c#  design-patterns  object-oriented  visitor-pattern 

私の友人から、ベストプラクティスは、mainメソッドを含むクラスには名前を付けMain、mainメソッドのみを含めることがベストプラクティスだと言われました。また、mainメソッドは入力のみを解析し、他のオブジェクトを作成し、他のメソッドを呼び出す必要があります。Mainクラスとmainメソッドは、何かをやるべきではありません。基本的に、彼はmainメソッドを含むクラスは次のようにすべきだと言っています： public class Main { public static void main(String[] args) { //parse inputs //create other objects //call methods } } ベストプラクティスですか？

12 object-oriented  programming-practices 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 短い質問 OO Cプロジェクトの「パブリック」メンバーと「プライベート」メンバーに名前を付ける一般的な方法はありますか？ 背景 私は、パブリックおよびプライベートメンバーがC言語に実際に存在しないことを完全に理解しています。ただし、ほとんどのCプログラマーと同様に、OO設計を維持するためにメンバーをパブリックまたはプライベートとして扱います。典型的なオブジェクト指向の方法に加えて、私は私がされている方法を区別することが容易になり、パターン（以下の例を参照）、以下の私の自己を発見したもので、より少ないチェックを有することができるプライベートメンバー対外の世界のために/より効率的などです...そのようなことに対して標準またはベストプラクティスが存在するか、またはこれにアプローチするための良い方法は私の例ですか？ ヘッダーの例 #ifndef _MODULE_X_H_ #define _MODULE_X_H_ bool MOD_X_get_variable_x(void); void MOD_X_set_variable_x(bool); #endif /* _MODULE_X_H_ */ サンプルソース // Module Identifier: MOD_X #include "module_x.h" // Private prototypes static void mod_x_do_something_cool(void); static void mod_x_do_something_else_cool(void); // Private Variables static bool var_x; // Public Functions - Note the upper …

12 object-oriented  c  embedded-systems 

オブジェクト指向ソリューションを設計しようとすると、通常、CRCモデリングを使用して、クラス名（名詞）、それらが行うこと（動詞）、および他のクラスとのコラボレーション方法をリストします。 このブログには、この名詞動詞のアプローチについて以下のことを述べています ...This approach, which I will call “noun and verb,” is so limited I’ll dare to call it brain damaged.... 私の質問は、オブジェクト指向アプローチを使用するためのより良いモデリング手法が存在するかどうかです。

12 design  object-oriented  design-patterns 

私は「依存性注入の原則、実践、およびパターン」という本を読んでおり、この本で十分に説明されているリークのある抽象化の概念について読んでいます。 最近では、依存関係の注入を使用してC＃コードベースをリファクタリングし、非同期呼び出しをブロックの代わりに使用しています。そうすることで、コードベースの抽象化を表し、非同期呼び出しを使用できるように再設計する必要があるいくつかのインターフェイスを検討しています。 例として、アプリケーションユーザーのリポジトリを表す次のインターフェースについて考えてみます。 public interface IUserRepository { Task<IEnumerable<User>> GetAllAsync(); } 本の定義によれば、リークの多い抽象化は特定の実装を念頭に置いて設計された抽象化であり、一部の実装は抽象化自体を通じて「リーク」します。 私の質問は次のとおりです。IUserRepositoryなどの非同期を念頭に置いて設計されたインターフェイスを、漏れやすい抽象化の例として検討できますか？ もちろん、可能なすべての実装が非同期と関係があるわけではありません。アウトプロセス実装（SQL実装など）だけが必要ですが、インメモリリポジトリは非同期を必要としません（実際にインメモリバージョンのインターフェイスを実装する方がおそらくインターフェースが非同期メソッドを公開している場合は困難です。たとえば、メソッドの実装でTask.CompletedTaskまたはTask.FromResult（users）のようなものを返す必要がある場合があります。 あれについてどう思う ？

12 c#  object-oriented  api-design  interfaces  dependency-injection 

ドメイン駆動設計では、ドメイン層にいくつかの（従来の）サービスを含めることができます。たとえば、ユーザードメインの場合、次のようになります。 さまざまな方法でUserオブジェクトを構築するUserFactory インフラストラクチャレイヤーの永続サービスとの対話を担当するUserRepository ドメインレイヤーのUserServiceは、これら2つのサービスとインフラストラクチャレイヤーのメディエーターやファサードにすぎませんか、それともそれ以上ですか？

12 object-oriented  object-oriented-design  domain-driven-design 

オブジェクト指向プログラミングの重要な概念の1つはカプセル化です。ただし、最近のソフトウェアの世界は、関数型プログラミングなどの他のパラダイムに傾倒しているようです。 それは私に、カプセル化と他のOOP原則についてはどう思いますか？彼らは間違っていますか？ OOPが間違って適用されているのですか？たとえば、アランケイはOOPSLA'97基調講演で言ったことで注目されています。 Joe Armstrong-「オブジェクトは関数とデータ構造を分割できない単位でバインドします。関数とデータ構造はまったく異なる世界に属しているため、これは根本的なエラーだと思います。」

12 object-oriented  functional-programming 

私は電気技師で、一体何をしているのかわかりません。私のコードの将来のメンテナーを保存してください。 最近、機能が論理的に「手続き型」である（C＃の）いくつかの小さなプログラムに取り組んでいます。たとえば、その1つは、さまざまなデータベースから情報を収集し、その情報を使用して一種の要約ページを生成し、印刷してから終了するプログラムです。 これらすべてに必要なロジックは約2000行です。以前の開発者が行っていたように、私はそれらすべてを1つにmain()詰め込んで#regionsで「クリーンアップ」したくありません（シャダー）。 ここに私がすでに満足していないいくつかの試みがあります： DatabaseInfoGetter、SummaryPageGenerator、PrintUtilityなど、機能の粗いビットごとに静的ユーティリティを作成します。メイン関数を次のようにします。 int main() { var thisThing = DatabaseInfoGetter.GetThis(); var thatThing = DatabaseInfoGetter.GetThat(); var summary = SummaryPageGenerator.GeneratePage(thisThing, thatThing); PrintUtility.Print(summary); } 1つのプログラムでは、インターフェイスも使用しました int main() { /* pardon the psuedocode */ List<Function> toDoList = new List<Function>(); toDoList.Add(new DatabaseInfoGetter(serverUrl)); toDoList.Add(new SummaryPageGenerator()); toDoList.Add(new PrintUtility()); foreach (Function f in toDoList) f.Do(); } …

12 c#  object-oriented  code-quality  code-smell  procedural 

パーサーを作成しているとしましょう。1つの実装は次のようになります。 public sealed class Parser1 { public string Parse(string text) { ... } } または、代わりにテキストをコンストラクタに渡すこともできます。 public sealed class Parser2 { public Parser2(string text) { this.text = text; } public string Parse() { ... } } どちらの場合も使用法は簡単ですが、他のものと比較して、へのパラメーター入力を有効にするとはどういう意味Parser1ですか？他のプログラマーがAPIを見たときに、どのメッセージを送信しましたか？また、特定の場合に技術的な利点/欠点はありますか？ 2番目の実装ではインターフェイスがまったく意味がないことに気づくと、別の質問が出てきます。 public interface IParser { string Parse(); } ...最初のインターフェイスが少なくともいくつかの目的に役立つ場合。これは特に、クラスが「インターフェース可能」かどうかを示していますか？

12 object-oriented  interfaces  methods  construction