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

私がレビューしているいくつかのコードでは、次のものと同等の道徳的なものを見ています： public class Foo { private Bar bar; public MethodA() { bar = new Bar(); bar.A(); bar = null; } public MethodB() { bar = new Bar(); bar.B(); bar = null; } } このフィールドbarは論理的にローカル変数です。これは、その値がメソッド呼び出し間で持続することを意図していないためです。ただし、メソッドの多くはFootypeのオブジェクトを必要とするBarため、元のコード作成者はtypeのフィールドを作成しましたBar。 これは明らかに悪いことですよね？ このアンチパターンに名前はありますか？

68 object-oriented  terminology  anti-patterns 

ダウンキャストとは、基本クラス（またはインターフェイス）からサブクラスまたはリーフクラスにキャストすることです。 ダウンキャストの例は、System.Object他のタイプにキャストする場合です。 ダウンキャストは人気がありませんが、コードの匂いかもしれません。例えば、オブジェクト指向の教義は、ダウンキャストの代わりに仮想メソッドまたは抽象メソッドを定義して呼び出すことを好むことです。 ダウンキャストの適切で適切なユースケースは、もしあれば、何ですか？つまり、ダウンキャストするコードを書くことが適切なのはどのような状況ですか？ 答えが「なし」である場合、ダウンキャストが言語でサポートされているのはなぜですか？

68 c#  object-oriented 

以下の2つのUpdateSubjectメソッドの違いは何ですか？エンティティを操作する場合は、静的メソッドを使用する方が良いと感じました。どのような状況で非静的メソッドを使用する必要がありますか？ public class Subject { public int Id {get; set;} public string Name { get; set; } public static bool UpdateSubject(Subject subject) { //Do something and return result return true; } public bool UpdateSubject() { //Do something on 'this' and return result return true; } } 私はこの本当に面倒な質問に対してコミュニティから多くのキックを得ることを知っていますが、私はそれを尋ねることを止めることができませんでした。 継承を扱う場合、これは非現実的になりますか？ 更新： 職場で今起こっています。5人の開発者と6か月のasp.net …

64 object-oriented  static-methods 

単一責任の原則では、クラスはただ1つのことを行うべきであると述べています。かなり明確な場合もあります。ただし、特定の抽象化レベルで表示したときに「1つのもの」のように見えるものは、下位レベルで表示したときに複数のものになる可能性があるため、他のものは困難です。また、単一の責任原則が低レベルで尊重されている場合、過度に分離された冗長なラビオリコードが発生し、すべての小さなクラスを作成し、実際の問題を解決するよりも情報を配管することに多くの行が費やされる可能性があります。 「一つのこと」の意味をどのように説明しますか？クラスが実際に「1つのこと」以上のことを行う具体的な兆候は何ですか？

64 design  object-oriented 

今日、誰かと議論がありました。 私は貧血領域モデルとは対照的に、豊富な領域モデルを持つことの利点を説明していました。そして、次のような単純なクラスでポイントをデモしました。 public class Employee { public Employee(string firstName, string lastName) { FirstName = firstName; LastName = lastname; } public string FirstName { get private set; } public string LastName { get; private set;} public int CountPaidDaysOffGranted { get; private set;} public void AddPaidDaysOffGranted(int numberOfdays) { // Do stuff } …

63 c#  object-oriented  single-responsibility 

私はまだ高校生（10年生）で、学校で実際のコンピューターコースをまだ受講していません。これまでにやったことはすべて本を通してです。これらの本は、継承などの概念を教えてくれましたが、プログラムを複数のクラスに分割するとどのように役立ちますか？本は私に決して言わなかった。 主に最近のプロジェクトのためにこれを求めています。これはアーケードビデオゲームで、一部の人が言っているようにFlashゲームのようなものです（Flashゲームとは何なのかはわかりませんが）。事は、それはただ一つのクラスです。1つのクラスで完全に正常に動作します（ただし、時折ラグが発生します）。だから、私はそれを複数のクラスに分割することがどのように役立つかを尋ねています。 このプロジェクトはJavaで行われ、記録のために私がプロジェクトに取り組んでいるのは私だけです。

62 java  object-oriented  inheritance  class 

OOPの背後にある主な考え方は、単一のエンティティ（オブジェクト）でデータと動作を統合することです。手続き型プログラミングには、データと、データを変更する個別のアルゴリズムがあります。 Model-View-Controllerパターンでは、データとロジック/アルゴリズムはそれぞれ別個のエンティティ、モデル、コントローラーに配置されます。同等のOOPアプローチでは、モデルとコントローラーを同じ論理エンティティに配置するべきではありませんか？

62 design  object-oriented  mvc 

ORMとその長所と短所について同僚と非常に刺激的で興味深い議論をしました。私の意見では、ORMは非常にまれな場合にのみ役立ちます。少なくとも私の経験では。 しかし、現時点では自分の主張をリストしたくありません。それでは、ORMについてどう思いますか？長所と短所は何ですか？

58 object-oriented  design-patterns  orm  anti-patterns 

問題の概要： 長い話を簡単に言えば、私はコードベースと開発チームを引き継ぎました。私はこれを置き換えることは許されておらず、God Objectsの使用は大きな問題です。今後、リファクタリングをしてもらいたいのですが、「もっと簡単だから」、God Objectsを使ってすべてをやりたいチームから押し戻されています。これは、リファクタリングが許可されないことを意味します。私は長年の開発経験、これらのことを知るために雇われた新しいボスなどを押し返しました。また、サードパーティのオフショア会社が営業担当者を説明しました。これは現在、役員レベルと会議です明日であり、長期的にはより安くなると思うので、多くの技術的な弾薬を使ってベストプラクティスを提唱したいと思います（そして、個人的にはサードパーティが心配していることだと感じています）。 私の問題は技術レベルからのものであり、長期的にはよく知っていますが、超短期間と6か月の期間には問題があります。 1人（ロバートC.マーティン、別名ボブおじさん）の、1人のデータ（1人のみ）（ロバートCマーティン）が十分な議論をしていないと言われているように。 質問： 「神」オブジェクト/クラス/システムのこの使用は明らかに悪いと言っている分野の有名な専門家が直接引用できるリソース（タイトル、発行年、ページ番号、引用）は何ですか？最も技術的に有効なソリューションの場合）？ 私がすでに行った研究： ここにはたくさんの本があり、「god object」と「god class」という言葉の使用についてインデックスを検索しました。奇妙なことに、ほとんど使用されておらず、たとえば、私が持っているGoF本のコピーは使用されません（少なくとも私の目の前のインデックスによると）が、下の2冊の本で見つけましたが、もっと欲しい私は使えます。 ウィキペディアのページで「God Object」と現在の参照リンクの少ないスタブを確認したので、個人的には有効とは見なされない環境ではあまり使用できないと言うことには個人的に同意します。引用された本はまた、私がこれらの技術的ポイントを議論している人々によって有効であるには古すぎると考えられています。 「オブジェクトは使いやすい」。私は個人的にこの声明が間違っていると信じていますが、それが何であれ真実を証明したいと思います。 ロバートCマーティンの「C＃のアジャイルの原則、パターン、および実践」（ISBN：0-13-185725-8、ハードカバー）では、266ページに「神のクラスが悪い考えであることを誰もが知っています。システムのすべてのインテリジェンスを単一のオブジェクトまたは単一の機能に集中させること。OODの目標の1つは、動作を多数のクラスおよび多数の機能に分割および分散することです。-そして、とにかく時々神のクラスを使用する方が良いことを時々言い続けます（例としてマイクロコントローラーを引用）。 ロバートCマーティンの「クリーンコード：アジャイルソフトウェアクラフツマンシップハンドブック」136ページ（およびこのページのみ）で、「神のクラス」について説明し、「クラスは小さくなければならない」ルールの違反の主な例として呼び出しています彼は138ページから始まる単一責任原則の推進に使用しています。 私が抱えている問題は、すべての参考文献と引用が同じ人（ロバートC.マーティン）から来ており、同じ一人の人/情報源から来ていることです。彼はただ一つの見解であるため、「神クラス」を使用しないという私の願望は無効であり、ソフトウェア業界の標準的なベストプラクティスとして受け入れられないと言われています。これは本当ですか？ボブおじさんの教えを守ろうとすることで、技術的な観点から間違ったことをしているのでしょうか？ 神のオブジェクトとオブジェクト指向プログラミングおよび設計： これについて考えるほど、OOPを勉強するときに学ぶことが多くなり、明示的に呼び出されることはありません。良いデザインへのその暗黙は私の考えです（私が学びたいので、自由に訂正してください）、問題は私がこれを「知っている」ことですが、誰もがそうではありません。統計的にほとんどの人はプログラマーではないため、実際にはほとんどの人が統計的に無知であるにもかかわらず、私は事実上それを普遍的な真実と呼んでいます。 結論： 彼らが技術的な主張をしており、真実を知り、実際のエンジニア/科学者のような引用でそれを証明できるようにしたいので、引用する最良の追加結果を得るために何を検索するのか迷っています私は、神のオブジェクトを使用したコードの個人的な経験のために、神のオブジェクトに偏っています。どんな援助または引用も深く感謝されるでしょう。

56 object-oriented  class  object  single-responsibility 

おそらく、オブジェクト指向のパラダイムを使用する最大の約束は、コードの再利用です。これが達成されたという論争もある。なぜ達成されたのか（達成されなかったのか）？ OOPが定義するとおりにコードを再利用し、プロジェクトの生産性を高めますか？ それとも管理しやすいですか？または保守が簡単ですか？または、より品質が高いですか？ おそらく、コードの再利用は良いことですが、この目標を達成する方法はいくつかあります。問題は、OOPが提供するコード再利用の方法です。良かった？オブジェクト指向、サブクラス化、ポリモーフィズムなどよりも優れたコード再利用を実現する方法はありますか？より良い方法は何ですか？なんで？ OOPの再利用や他のパラダイムの再利用の経験を教えてください。

56 productivity  code-quality  object-oriented  code-reuse 

私はちょうど（コンピューティングの）修士号を取得し、仕事に応募しています。多くの企業がオブジェクト指向の理解を特に求めていることに気付きました。人気のあるインタビューの質問は、継承、ポリモーフィズム、アクセサーなどに関するものです。 オブジェクト指向は本当に重要ですか？私はCでのプログラミングの仕事の面接さえ受けましたが、面接の半分はオブジェクト指向でした。 現実の世界では、実際のアプリケーションの開発において、ほとんど常にオブジェクト指向が使用されていますか？ポリモーフィズムのような主要な機能はLOTを使用していますか？ 私の質問は私の弱点の一つから来ていると思います。私はオブジェクト指向について知っていますが、私はそれを私のプログラムに大いに組み込むことができないようです。

55 object-oriented  inheritance  polymorphism 

C ++には単純な多重継承があり、多くの言語設計では危険なものとして禁止されています。しかし、RubyやPHPなどの一部の言語では、奇妙な構文を使用して同じことを行い、それをmixinまたはtraitsと呼びます。ミックスイン/特性は、単純な多重継承よりも悪用しにくいと何度も耳にしました。 それらを特に危険性の低いものにしているのは何ですか？ミックスイン/トレイトではできないが、C ++スタイルの多重継承では可能なことはありますか？彼らとダイヤモンドの問題に遭遇することは可能ですか？ これは、多重継承を使用しているように見えますが、それらを使用できるように、それらがミックスイン/特性であるという言い訳をするだけです。

54 object-oriented  inheritance  multiple-inheritance  mixins 

私が働いている場所では、このようなことをするクラスがたくさんあります。 public class ClassThatCallsItsOwnGettersAndSetters { private String field; public String getField() { return field; } public void setField(String field) { this.field = field; } public void methodWithLogic() { setField("value"); //do stuff String localField = getField(); //do stuff with "localField" } } これを最初から書いた場合methodWithLogic()、代わりに次のように書いたでしょう。 public class ClassThatUsesItsOwnFields { private String field; public …

53 java  object-oriented  programming-practices 

私は、オブジェクト指向プログラミングが現実世界のモデリングに基づいていることをよく見ましたが、それは本当ですか？ 私には、ビジネス層以外の何も真実ではないようです。私のGUIクラス/データアクセスクラスは、現実の世界では何もモデリングしていません。私のビジネス層にも、オブザーバー、マネージャー、工場など、現実世界のオブジェクトではないクラスがあります。カプセル化などを利用するようにクラスを設計しようとしていますが、現実の世界はカプセル化されていますか？ 私が作成するオブジェクトの中には、現実世界のオブジェクトをモデリングしているものがありますが、OOP前のコードは同じことをしないでしょうか？OOは、Customerのような概念をコードベースに最初に組み込んだ人ではなかったと思います。しかし、オブジェクト指向は本当に物事をモデル化する方法に関するものであり、そのモデル化の方法は私にとって現実の世界に触発されていないようです。 では、オブジェクト指向プログラミングは実際に現実世界をモデル化していますか？

52 object-oriented 

IOCコンテナの目的は何ですか？組み合わされた理由は、次のように簡略化できます。 OOP / SOLID開発の原則を使用する場合、依存関係の注入が面倒になります。下位レベルの複数のレベルの依存関係を管理し、構築を通じて依存関係を再帰的に渡す最上位のエントリポイントがあるか、必要に応じて依存関係を構築するファクトリー/ビルダーパターンおよびインターフェイスにコードが多少重複しています。 これを実行するには、何のOOP / SOLID方法はありませんと、超きれいなコードを持っているが。 前のステートメントが正しい場合、IOCコンテナーはどのようにそれを行いますか？私の知る限り、それらは手動のDIでは実行できない未知の手法を使用していないため、IOCコンテナは静的オブジェクトのプライベートアクセッサを使用してOOP / SOLID原則を破ることだけです。 IOCコンテナは、背後で次の原則を破っていますか？私はよく理解しているので、これは本当の質問ですが、他の誰かがより良い理解を持っていると感じています スコープ制御。スコープは、コード設計に関するほとんどすべての決定の理由です。ブロック、ローカル、モジュール、静的/グローバル。スコープは、ブロックレベルでできるだけ多く、静的でできるだけ少なくする必要があります。宣言、インスタンス化、およびライフサイクルの終了が表示されます。言語とGCは、明示的に明示している限り、スコープを管理することを信頼しています。私の研究では、IOCコンテナがほとんどまたはすべての依存関係を静的として設定し、バックグラウンドでAOP実装を介して制御していることがわかりました。したがって、何も透明ではありません。 カプセル化。カプセル化の目的は何ですか？なぜプライベートメンバーを保持する必要があるのですか？実際的な理由により、APIの実装者は、状態（所有者クラスによって管理される必要があります）を変更して実装を中断することはできません。しかし、セキュリティ上の理由から、メンバー状態を追い越し、検証とクラス制御をバイパスするインジェクションが発生しないようにします。したがって、プライベートメンバーへの外部アクセスを許可するためにコンパイル時間の前に何らかの形でコードを挿入するもの（モックフレームワークまたはIOCフレームワーク）は非常に巨大です。 単一責任の原則。表面的には、IOCコンテナは物事をよりきれいにするようです。しかし、ヘルパーフレームワークなしで同じことを達成する方法を想像してください。十数個の依存関係を持つコンストラクターが渡されます。それはIOCコンテナーでそれをカバーすることを意味するものではありません、それは良いことです！コードをリファクタリングし、SRPに従うことを示すサインです。 オープン/クローズ。SRPがクラスのみではないように（メソッドはもちろん、SRPを単一の責任ラインに適用します）。Open / Closedは、クラスのコードを変更しないという単なる高レベルの理論ではありません。プログラムの構成を理解し、何が変更され、何が拡張されるかを制御する習慣です。IOCコンテナは、次の理由でクラスの動作方法を完全に変更できます。 a。主なコードは依存関係の切り替えを決定するのではなく、フレームワークの構成です。 b。スコープは、呼び出し元のメンバーによって制御されていないときに変更される可能性があり、代わりに静的フレームワークによって外部で決定されます。 したがって、クラスの構成は実際には閉じられていません。サードパーティのツールの構成に基づいて変更されます。 これが質問である理由は、私が必ずしもすべてのIOCコンテナのマスターではないからです。また、IOCコンテナーのアイデアは素晴らしいものの、実装が不十分なことを覆い隠す外観にすぎません。しかし、外部のスコープ制御、プライベートメンバーアクセス、および遅延読み込みを実現するには、多くの重要な疑問の余地のある作業を継続する必要があります。AOPは素晴らしいですが、IOC Containersを介して達成される方法にも疑問があります。 私は、C＃と.NET GCが期待どおりに動作することを信頼できます。しかし、コンパイルされたコードを変更して、手動で実行できないことに対する回避策を実行するサードパーティ製のツールに同じ信頼を置くことはできません。 EG：Entity Frameworkと他のORMは、厳密に型指定されたオブジェクトを作成してデータベースエンティティにマッピングし、CRUDを実行するための基本的な機能を提供します。誰でも独自のORMを構築し、OOP / SOLID原則を手動で従うことができます。しかし、これらのフレームワークは私たちを助けてくれるので、毎回車輪を再発明する必要はありません。一方、IOC Containersは、OOP / SOLID原則を意図的に回避し、それを隠すのに役立つようです。

51 object-oriented  solid  inversion-of-control