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

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

3
継承のないオブジェクト指向言語はありますか？
今日のコードレビューの間に、私の同僚は何か面白いことを言った。 prototypeは、継承が必要な場合にのみ役立ちます- いつ継承が良いアイデアですか？ 私はこれについて考え、私は通常、継承を使用して、最初はひどく設計されたコードを回避することに気付きました。現代のオブジェクト指向スタイルは継承よりも合成を好みますが、これを心に留めて実際に強制した言語は知りません。 クラス、オブジェクト、メソッド、インターフェースなどを備えた汎用プログラミング言語はありますか？クラスベースの継承を禁止しますか？（このような考えが意味をなさない場合、なぜですか？）
7
オブジェクトモデルの変更を伝播するためのパターン..？
対処するのが常にイライラする一般的なシナリオを次に示します。 親オブジェクトを持つオブジェクトモデルがあります。親には、いくつかの子オブジェクトが含まれます。このようなもの。 public class Zoo { public List<Animal> Animals { get; set; } public bool IsDirty { get; set; } } 各子オブジェクトにはさまざまなデータとメソッドがあります public class Animal { public string Name { get; set; } public int Age { get; set; } public void MakeMess() { ... } } 子が変更されたとき、この場合はMakeMessメソッドが呼び出されたときに、親の値を更新する必要があります。Animalの特定のしきい値が混乱した場合、ZooのIsDirtyフラグを設定する必要があるとします。 このシナリオを処理する方法はいくつかあります（私が知っていることです）。 1）変更を通知するために、各動物は親動物園の参照を持つことができます。 …
9
OOPの原則とメソッド名
class Boxer: def punch(self, punching_bag, strength): punching_bag.punch(strength) class PunchingBag: def punch(self, strength): print "Punching bag punched with strength", strength boxer = Boxer() punching_bag = PunchingBag() boxer.punch(punching_bag, 2) punchボクサーの場合、それが良いメソッド名であることは間違いありません。しかし、名前punchはパンチングバッグの方法にも適していますか？どちらの場合も、コマンドとしてのパンチ（つまり、パンチ）を意味します。
6
オブジェクトは自身のIDを知っている必要がありますか？
obj.idはかなり一般的であり、オブジェクトがそれ自体について知ることができる範囲内に収まるようです。私は自分のオブジェクトが自分のIDを知っている必要がある理由を尋ねています。 それを持っている理由がないようですか？それが存在する主な理由の1つはそれを取得することです。したがって、私のリポジトリはそれを知る必要があり、したがってデータベースとの対話に使用する必要があります。 また、IDがペイロードに収まらないように見えるRESTful APIのオブジェクトをJSONにシリアル化したいという問題に一度遭遇しました。 オブジェクトは自身のIDを知る必要がありますか？なぜですか？ 更新： 用語 id：オブジェクトの識別子属性。データベース用語では、代理キーは自然キーではありません。 オブジェクト：エンティティ、またはシステム内で一意に識別可能なオブジェクト。
1
アラン・ケイがこの用語を発明する前に、彼らは何をオブジェクト指向プログラミングと呼んだのですか？
アラン・ケイは「私は「オブジェクト指向」という用語を作り上げました。C++を念頭に置いていなかったと言えます」もちろん、彼が念頭に置いていたのはSmalltalkでした。しかし、彼はオブジェクト指向プログラミング自体を構成しませんでした。彼はSimulaから基本的なアイデアを得ました。この用語がまだ発明されていない場合、Simulaで元々オブジェクト指向プログラミングと呼ばれていたものは何ですか？
6
ユースケースなしの疎結合はアンチパターンですか？
一部の開発者にとって、疎結合は、適切に設計されたソフトウェアの聖杯です。予測可能な将来に発生する可能性のある変更に直面してコードをより柔軟にする、またはコードの重複を回避する場合、それは確かに良いことです。 一方、コンポーネントを疎結合しようとすると、プログラム内の間接参照の量が増え、そのため複雑さが増し、理解が難しくなり、効率が低下することがよくあります。 疎結合のユースケースを使用しない疎結合（コードの重複を回避したり、近い将来発生する可能性のある変更を計画するなど）をアンチパターンと考えていますか？ゆるい結合はYAGNIの傘の下に落ちますか？
3
C ++クラスコンストラクターでエラーが発生した場合の対処方法
コンストラクターがいくつかの操作を行うCPPクラスがあります。これらの操作の一部は失敗する場合があります。コンストラクタは何も返さないことを知っています。 私の質問は、 コンストラクターでメンバーを初期化する以外の操作を実行できますか？ コンストラクターの一部の操作が失敗したことを呼び出し元の関数に伝えることは可能ですか？ new ClassName()コンストラクターでエラーが発生した場合にNULL を返すことはできますか？
4
「オブジェクト指向すぎる」
私は強力なオブジェクト指向のバックグラウンドから来ており、コードはJavaで書かれていますが、以前よりも優れたオブジェクト指向設計にあまり重点を置いていない組織で働き始めました。私は「あまりにも多くの抽象化」を導入し、代わりに常に行われている方法をコーディングする必要があると言われました。これはJavaの手続き型です。 TDDもここではあまり実践されていませんが、テスト可能なコードが必要です。大きな「神クラス」の静的プライベートメソッドにビジネスロジックを埋め込むことは（このチームの標準と思われます）、あまりテストできません。 私は自分の動機を同僚に明確に伝えることに苦労しています。OOとTDDを使用するとコードのメンテナンスが容易になることを同僚に納得させる方法について、誰かアドバイスがありますか？ 技術的負債に関するこの質問は私の質問に関連しています。ただし、他の問題がカバーする事実の後に返済するのではなく、そもそも借金の発生を回避しようとしています。
5
巨大な接着方法を避ける方法は？
私の現在の仕事では、古いコードを数回クリーンアップする仕事をしました。多くの場合、コードは迷路であり、その背後のデータはさらに複雑です。私は物事をすてきな、きちんとした、モジュール式の方法にまとめると思います。各メソッドは1つのことを行い、それをうまく行います。それは物事が南に行き始めるときです... 常に、私はきれいなAPIになり、それをすべて結びつける実際の方法はありません。解決策は、最終的にすべての「クリーン」メソッドを呼び出す、大きない「グルー」メソッド（通常は条件ステートメントでいっぱい）を記述することです。 通常、glueメソッドは、クリーンアップしようとしたコード/データのもつれの簡潔なバージョンになります。一般的に読みやすいですが、それでもいらいらします。 そのような方法を避けるにはどうすればよいですか？これはもつれたデータの症状なのでしょうか、それとも私が間違っていることを反映しているのでしょうか？
5
静的クラスを名前空間として使用する
この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 名前空間として静的クラスを使用している他の開発者を見てきました public static class CategoryA { public class Item1 { public void DoSomething() { } } public class Item2 { public void DoSomething() { } } } public static class CategoryB { public class Item3 { public void DoSomething() { } } public …
12
ゲームの開発はプログラミングを学ぶための最良の方法ですか？[閉まっている]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 私は最近、ゲームを開発することがプログラミングを学ぶための最良の方法であるというインストラクターの助言を聞いた。すべてをコードで作成しなければならなかったという事実に加えて、彼はあなたが本当にあなたのプログラムにOOPを完全に経験して実装できるようになると言いました。つまり、ゲームで作成するものはすべて、技術的にも概念的にも文字通りのオブジェクトです。この仮定をするのは安全ですか？または、プログラミングを学習するときに常に例外がありますか？ .net / xna / c＃開発を対象としたものであることに注意してください。
4
コードカバレッジを劇的に改善する方法は？
ユニットテストの下でレガシーアプリケーションを取得することを任されています。アプリケーションに関する最初の背景：これらの主要な問題を伴う600k LOC Java RCPコードベースです。 大規模なコードの複製 カプセル化なし、ほとんどのプライベートデータは外部からアクセスできます。ビジネスデータの一部はシングルトンにもなっているため、外部からだけでなくどこからでも変更できます。 抽象化なし（たとえば、ビジネスモデルなし、ビジネスデータはObject []およびdouble [] []に格納されます）。したがって、OOはありません。 優れた回帰テストスイートがあり、効率的なQAチームがバグのテストと発見を行っています。マイケル・フェザーズなどの古典的な本からテストする方法を知っていますが、それは遅すぎます。実用的なリグレッションテストシステムがあるので、ユニットテストを作成できるようにシステムを積極的にリファクタリングすることを恐れていません。 迅速にカバレッジを得るために、どのように問題を攻撃し始める必要がありますか？そうすれば、経営陣に進捗を示すことができます（実際には、JUnitテストのセーフティネットから収益を上げることができます）？AgitarOneなどの回帰テストスイートを生成するツールを使用したくないのは、これらのテストは何かが正しいかどうかをテストしないためです。
5
フォールバックのある特別なケースは、リスコフ代替原理に違反しますか？
FooInterface次のシグネチャを持つインターフェイスがあるとします。 interface FooInterface { public function doSomething(SomethingInterface something); } そして、ConcreteFooそのインターフェースを実装する具体的なクラス： class ConcreteFoo implements FooInterface { public function doSomething(SomethingInterface something) { } } ConcreteFoo::doSomething()特別なタイプのSomethingInterfaceオブジェクトが渡された場合、ユニークな何かをしたいと思います（と呼ばれますSpecialSomething）。 メソッドの前提条件を強化するか、新しい例外をスローする場合、それは間違いなくLSP違反ですが、SpecialSomething汎用SomethingInterfaceオブジェクトのフォールバックを提供しながらオブジェクトを特別にケースに入れた場合でもLSP違反になりますか？何かのようなもの： class ConcreteFoo implements FooInterface { public function doSomething(SomethingInterface something) { if (something instanceof SpecialSomething) { // Do SpecialSomething magic } else { // Do generic SomethingInterface …
3
ジェネリックと共通のインターフェース？
前回ジェネリッククラスを書いたときのことは覚えていません。何かを考えてから必要になると思うたびに、結論を出します。 この質問に対する2番目の答えは、明確化を求めることでした（まだコメントできないので、新しい質問をしました）。 ジェネリックが必要な場合の例として、与えられたコードを取り上げましょう。 public class Repository<T> where T : class, IBusinessOBject { T Get(int id) void Save(T obj); void Delete(T obj); } 型の制約があります： IBusinessObject 私の通常の考え方は次のとおりです。クラスはuse IBusinessObjectに制限されているため、これを使用するクラスもそうRepositoryです。リポジトリはこれらを保存します。IBusinessObjectほとんどの場合、これのクライアントはインターフェースをRepository介してオブジェクトを取得および使用したいと思うでしょうIBusinessObject。それではなぜ public class Repository { IBusinessOBject Get(int id) void Save(IBusinessOBject obj); void Delete(IBusinessOBject obj); } また、この例は、単なる別のコレクションタイプであり、ジェネリックコレクションはクラシックであるため、良くありません。この場合、型制約も奇妙に見えます。 実際、この例class Repository<T> where T : class, IBusinessbBjectはclass BusinessObjectRepository私によく似ています。これはジェネリックが修正するために作られたものです。 要点は、ジェネリックはコレクション以外のすべてに適しているので、クラス内でジェネリック型パラメーターの代わりにこの型制約を使用するように、型制約を特殊化することはありませんか？
5
ほぼ全員が共通のデータ構造にアクセスする必要がある場合の依存性注入の利点は何ですか？
OOPでグローバルが悪である理由はたくさんあります。 共有を必要とするオブジェクトの数またはサイズが大きすぎて関数パラメーターで効率的に渡されない場合、通常はグローバルオブジェクトではなく依存性注入をお勧めします。 しかし、ほとんどすべての人が特定のデータ構造について知る必要がある場合、なぜ依存性注入がグローバルオブジェクトよりも優れているのでしょうか？ 例（特定のアプリケーションを深く掘り下げることなく、ポイントを一般的に示すための簡略化されたもの） 種類、名前、色、速度、位置など、膨大な数のプロパティと状態を持つ仮想車両が多数あります。多数のユーザーがそれらをリモートコントロールでき、膨大な数のイベント（両方ともユーザー、開始および自動）は、多くの状態またはプロパティを変更できます。 素朴な解決策は、それらのグローバルコンテナを作成することです。 vector<Vehicle> vehicles; どこからでもアクセスできます。 よりOOPに適したソリューションは、コンテナーをメインイベントループを処理するクラスのメンバーにし、コンストラクターでインスタンス化することです。それを必要とし、メインスレッドのメンバーであるすべてのクラスには、コンストラクターのポインターを介してコンテナーへのアクセスが許可されます。たとえば、外部メッセージがネットワーク接続を介して着信した場合、解析を処理するクラス（接続ごとに1つ）が引き継ぎ、パーサーはポインターまたは参照を介してコンテナーにアクセスできます。解析されたメッセージの結果、コンテナの要素が変更された場合、またはアクションを実行するためにそこからデータが必要な場合、信号やスロットを介して数千の変数を投げる必要なく処理できます（または、それらをパーサーに保存して、パーサーを呼び出した人が後で取得できるようにします）。もちろん、依存性注入を介してコンテナへのアクセスを受け取るすべてのクラスは、同じスレッドの一部です。異なるスレッドは直接アクセスしませんが、ジョブを実行してからメインスレッドに信号を送信すると、メインスレッドのスロットがコンテナを更新します。 ただし、クラスの大部分がコンテナにアクセスできるようになった場合、グローバルとはどう違うのでしょうか？非常に多くのクラスがコンテナ内のデータを必要とする場合、「依存性注入方法」は単なる偽装グローバルではありませんか？ 答えの1つはスレッドセーフです。グローバルコンテナを乱用しないように注意を払っていますが、近い将来、他の開発者が近い締め切りの圧力の下で、すべてを気にせずに別のスレッドでグローバルコンテナを使用する可能性があります衝突の場合。ただし、依存性注入の場合でも、別のスレッドで実行されている誰かにポインターを与えると、同じ問題が発生する可能性があります。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.