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

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

6
オブジェクト指向デザイン、トーナルハーモニーのモデリング方法
コード、音階、ハーモニーを分析するプログラムをC ++ 11で書き始めました。私が設計段階で抱えている最大の問題は、音「C」が音、コードのタイプ（Cmaj、Cmin、C7など）、およびキーのタイプ（Cmajor、Cminorのキー）であることです。間隔（マイナー3、メジャー3）でも同じ問題が発生します。 私は、プログラム内のすべての「シンボル」の基本クラスである基本クラスであるトークンを使用しています。例えば： class Token { public: typedef shared_ptr<Token> pointer_type; Token() {} virtual ~Token() {} }; class Command : public Token { public: Command() {} pointer_type execute(); } class Note : public Token; class Triad : public Token; class MajorTriad : public Triad; // CMajorTriad, etc class Key : …
1
オブジェクト指向のパラダイムが主流になるのに長い時間がかかったのはなぜですか？
この質問を読んで、かなり最近のことについて考えさせられました。オブジェクト指向言語。最初のものがいつ作成されたのかわかりませんが、なぜ彼らが主流になるまでにそれほど時間がかかったのですか？ Cは非常に人気を博しましたが、後にオブジェクト指向C ++になりませんでした（数十年後）。 90年代以前の主流言語はオブジェクト指向ではありませんでした オブジェクト指向は、ほぼ同時期にJavaとC ++を使用するようになりました さて、私の質問、なぜこれにそれほど時間がかかったのですか？Cが元々オブジェクト指向言語として考えられていなかったのはなぜですか？C ++の非常に小さなサブセットを使用しても、コア言語に大きな影響は及ばなかったのに、なぜこのアイデアは90年代まで普及しなかったのでしょうか？
2
オブジェクト指向設計のアドバイスを探しています
私は産業環境でバルブを開閉するために使用されるアプリを開発しており、このような単純なことを考えていました：- public static void ValveController { public static void OpenValve(string valveName) { // Implementation to open the valve } public static void CloseValve(string valveName) { // Implementation to close the valve } } （実装は、バルブを制御するためにシリアルポートに数バイトのデータを書き込みます-バルブ名から派生した「アドレス」、およびバルブを開閉する「1」または「0」）。 別の開発者は、代わりに物理的なバルブごとに個別のクラスを作成するかどうかを尋ねました。のようなコードを書く方が良いと思いますPlasmaValve.Open()がValveController.OpenValve("plasma")、これはやり過ぎですか？ また、私はいくつかの仮説的な将来の要件を念頭に置いて設計に取り組む最善の方法を疑問に思っていました： バルブの開閉に異なる値を必要とする新しいタイプのバルブ（0と1ではありません）をサポートするよう求められています。 単に「開く」または「閉じる」のではなく、0〜100の任意の位置に設定できるバルブをサポートする必要があります。 通常、この種のことには継承を使用しますが、最近、「継承を超える構成」に頭を悩まし始め、構成を使用するスリッカーソリューションがあるのではないかと考え始めました。
6
ゲッターとセッターを定義する順序は？[閉まっている]
現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 ゲッターとセッターを定義する順序のベストプラクティスはありますか？2つのプラクティスがあるようです： ゲッター/セッターペア 最初にゲッター、次にセッター（またはその逆） ここで違いを明らかにするために、ゲッター/セッターペアのJavaの例を示します。 public class Foo { private int var1, var2, var3; public int getVar1() { return var1; } public void setVar1(int var1) { this.var1 = var1; } public int getVar2() { return var2; } public void setVar2(int var2) { this.var2 = var2; } public int getVar3() …
2
シミュレーションおよびモデリング用のFP
シミュレーション/モデリングプロジェクトを開始しようとしています。OOPがこの種のプロジェクトに使用されていることは既に知っています。しかし、Haskellを勉強することで、コンポーネントのシステムのモデリングにFPパラダイムを使用することを検討しました。詳しく説明します。 データセット（温度や圧力、PDE、境界条件などのパラメーター）で特徴付けられるタイプAのコンポーネントと、異なるデータセット（異なるまたは同じパラメーター、異なるPDEおよび境界条件）。また、各コンポーネントに適用される関数/メソッドが同じであると仮定しましょう（たとえば、Galerkinメソッド）。オブジェクトの可変状態は、定数でないパラメーターに使用されます。 OOPアプローチを使用する場合、各タイプのデータをカプセル化する2つのオブジェクト、PDEを解決するメソッド（ここではコードの再利用に継承が使用されます）、およびPDEのソリューションを作成します。 一方、FPアプローチを使用する場合、各コンポーネントは、PDEのソリューションを取得するためにデータパーツとデータに作用する関数に分割されます。非定数パラメーターは、他の何かの関数として渡されるか（たとえば、時間）、ある種の可変性（可変性のエミュレーションなど）で表現されます。 結論として、FPアプローチの実装は、OOPアプローチと比較して、実際にはシンプルで管理しやすい（pdeを解決するために異なるタイプのコンポーネントまたは新しいメソッドを追加する）でしょうか？ 私はC ++ / Fortranのバックグラウンドを持っていますが、プロのプログラマーではないので、間違いがあれば修正してください。
4
オブジェクト指向プログラミング：ゲッター/セッターまたは論理名
私は現在、書いているクラスへのインターフェースについて考えています。このクラスには、キャラクターのスタイル、たとえば、キャラクターが太字、斜体、下線などが含まれます。これらのスタイル。私は論理名を好む傾向がありますが、それは効率的でも論理的でもないコードを書くことを意味します。例を挙げましょう。 私はクラスの持っているCharacterStylesメンバ変数があるbold、italic、underline（およびいくつかの他の人を、私はそれをシンプルに保つためにそれらを残しておきます）。最も簡単な方法は、あなたが行うことができるように、書き込みgetter / setterメソッドになり、これらの変数にアクセスするには、プログラムの他の部分を可能にstyles.setBold(true)してstyles.setItalic(false)。 しかし、私はこれが好きではありません。多くの人がゲッター/セッターがカプセル化を破ると言っているだけでなく（それは本当にそんなに悪いのですか？）私は、styles.format("bold", true)これらのすべての方法ではなく、1つの方法などでキャラクターのスタイルを設定することを期待しています。 ただし、1つの問題があります。C ++の文字列の内容ではオブジェクトメンバー変数にアクセスできないため、すべてのスタイルに対して大きなifステートメント/スイッチコンテナーを記述するか、スタイルを連想配列に格納する必要があります（地図）。 最善の方法がわからない。ある瞬間、私はゲッター/セッターを書くべきだと思い、次の瞬間、私は他の方法に傾く。私の質問は：あなたは何をしますか？そして、なぜあなたはそれをするのでしょうか？
4
分類のみにインターフェースを使用するのは悪い習慣ですか？
例えば： 私はクラスを持っていると言いますA、B、C。私は2つのインタフェースを持って、それらを呼び出すことができますIAnimalし、IDog。IDogから継承しIAnimalます。Aand BはIDogsで、while Cはそうではありませんが、IAnimalです。 重要な部分は、IDog追加機能を提供しないことです。特定のメソッドへの引数として渡されることを許可するためだけに使用されますがA、BではありませんC。 これは悪い習慣ですか？
4
OOP設計のグッドプラクティスをどのようにして得ましたか？[閉まっている]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 閉じた2年前。 OOPデザインを作成するのが難しいことに気付きました。このプロパティがXクラスに正しく設定されているかどうかを判断するのに多くの時間を費やしました。 たとえば、これは数日ある投稿です：https : //codereview.stackexchange.com/questions/8041/how-to-improve-my-factory-design 私は自分のコードを確信していません。だから私は自分のデザインを改善したい、それを作成する時間を短縮したい 良いデザインの作成をどのように学びましたか？あなたが私を推薦することができるいくつかの本？
3
コマンド/クエリの分離は、オブジェクトを作成してそのIDを返すメソッドに適用されますか？
ビジネスプロセスを呼び出すサービスがあるとします。このプロセスは、データレイヤーを呼び出して、データベースにタイプAのオブジェクトを作成します。 その後、データレイヤーの別のクラスを再度呼び出して、データベースにタイプBのインスタンスを作成する必要があります。外部キーのAに関する情報を渡す必要があります。 最初のメソッドでは、オブジェクトを作成（状態の変更）し、1つのメソッドでそのID（クエリ）を返します。 2番目のメソッドには、保存用の1つ（createA）とクエリ用の2つ（getId）の2つのメソッドがあります。 public void FirstMethod(Info info) { var id = firstRepository.createA(info); secondRepository.createB(id); } public void SecondMethod(Info info) { firstRepository.createA(info); var key = firstRepository.getID(info); secondRepository.createB(key); } 私の理解から、2番目の方法は、コマンドクエリの分離に完全に従います。しかし、作成したばかりのオブジェクトを取得するためにデータベースを照会するのは無駄で直観に反すると思います。 このようなシナリオでCQSをどのように調整しますか？ CQSに続くのは2番目の方法だけですか？その場合は、この場合に使用するのが望ましいですか？
4
肥大化したドメインオブジェクトの回避
DDDアプローチを使用して、肥大化したサービスレイヤーからドメインレイヤーにデータを移動しようとしています。現在、私たちのサービスには多くのビジネスロジックがありますが、それはいたるところに分散しており、継承の恩恵は受けません。 ほとんどの作業の中心である中央ドメインクラスがあります-貿易。Tradeオブジェクトは、それ自体の価格設定方法、リスクの推定方法、それ自体の検証方法などを知っています。その後、条件をポリモーフィズムに置き換えることができます。例えば、SimpleTradeはそれ自体の価格を設定しますが、ComplexTradeはそれ自体の価格を設定します。 ただし、これによりTradeクラスが膨張するのではないかと心配しています。本当に独自の処理を担当する必要がありますが、機能が追加されるにつれてクラスのサイズは指数関数的に増加します。 選択肢があります： Tradeクラスに処理ロジックを配置します。処理ロジックは現在、取引のタイプに基づいてポリモーフィックですが、取引クラスには複数の責任（価格、リスクなど）があり、大規模です TradePricingServiceなどの他のクラスに処理ロジックを配置します。Trade継承ツリーとポリモーフィックではなくなりましたが、クラスは小さくなり、テストが容易になりました。 推奨されるアプローチは何ですか？
9
OOPの概念/原理を実際に学ぶにはどうすればいいですか？[閉まっている]
現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 オブジェクト指向プログラミング言語を学びたかったのですが、OOPの概念全体を知ることだけを目的にしたくないのです。だから、誰が私がどの言語を学び始めるべきか教えてくれますか？
3
クラスと構造体
C ++およびその他の影響を受ける言語には、Structure（struct）と呼ばれる構造体と、と呼ばれる別の構造体がありclassます。どちらも関数と変数を保持できます。いくつかの違いは次のとおりです。 クラスには、ヒープ内のstructメモリが割り当てられ、スタック内のメモリが割り当てられます（注意：これはC ++では間違っていますが、OPが「影響を受けた言語」と呼んだものでは正しいかもしれません） クラス変数はデフォルトでプライベートであり、structそれらはパブリックです 私の質問はstruct、クラスはどういうわけか放棄されたのですか？もしそうなら、なぜですか？上記の違いをstruct除けば、クラスと同じことをすべて行うことができます。なぜそれを放棄するのですか？
8
オブジェクト指向クラスの設計
オブジェクト指向の優れたクラス設計について疑問に思っていました。特に、これらのオプションを決定するのに苦労しています。 静的対インスタンスメソッド パラメータまたは戻り値のないメソッド vs パラメータおよび戻り値のあるメソッド オーバーラップする対の異なる方法で機能 民間対公共方法 例1： この実装では、戻り値やパラメーターを持たず、機能が重複しないインスタンスメソッドを使用します。すべてのメソッドはpublic XmlReader reader = new XmlReader(url); reader.openUrl(); reader.readXml(); Document result = reader.getDocument(); 例2： この実装では、戻り値とパラメータを備えた静的メソッドを使用し、重複する機能とプライベートメソッドを使用します。 Document result = XmlReader.readXml(url); 例1では、すべてのメソッドがパブリックインスタンスであるため、ユニットテストが簡単になります。すべてのメソッドは異なりますが、readXml（）はopenUrl（）に依存しているため、openUrl（）を最初に呼び出す必要があります。すべてのデータはインスタンスフィールドで宣言されるため、コンストラクターとアクセサーを除き、どのメソッドにも戻り値やパラメーターはありません。 例2では、​​1つのメソッドのみがパブリックであり、残りはプライベートスタティックであるため、ユニットテストが困難です。readXml（）がopenUrl（）を呼び出すという点で、メソッドは重複しています。フィールドはありません。すべてのデータはメソッドのパラメーターとして渡され、結果はすぐに返されます。 適切なオブジェクト指向プログラミングを行うには、どの原則に従うべきですか？
9
継承が間違っている
良い継承モデルが下り坂になっているコードがいくつかあり、それを修正する理由と方法を理解しようとしています。基本的に、次のようなZoo階層があるとします。 class Animal class Parrot : Animal class Elephant : Animal class Cow : Animal 等 eat（）、run（）などのメソッドがあり、すべてが適切です。それからある日誰かがやって来て言う-私たちのCageBuilderクラスはうまく機能し、animal.weight（）とanimal.height（）を使用しますが、新しいアフリカバイソンは強すぎて壁を砕くことができるので、追加しますAnimalクラスのもう1つのプロパティ-isAfricanBizon（）で、マテリアルを選択するときにそれを使用し、AfricanBizonクラスに対してのみオーバーライドします。次の人が来て、似たようなことをします。次に、基本クラスへの階層のサブセットに固有のこれらすべてのプロパティがあることを知っています。 そのようなコードを改善/リファクタリングする良い方法は何ですか？ここでの1つの代替方法は、dynamic_castsを使用して型をチェックすることですが、呼び出し元を混乱させ、あらゆる場所にif-then-elseを追加します。ここでは、より具体的なインターフェイスを使用できますが、基本クラス参照のみを使用している場合は、あまり役に立ちません。他の提案はありますか？例？ ありがとう！
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.