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

Ruby on Railsで有名になったActiveRecordパターンが、SOLID設計原則の使用を奨励または阻止するかどうかに興味があります。 たとえば、ActiveRecordオブジェクトには、ドメインロジックと、単一責任の違反である永続化ロジックの両方が含まれているように思えます。

43 object-oriented  ruby-on-rails 

レガシーコードでは、データのラッパーにすぎないクラスが時々見られます。何かのようなもの： class Bottle { int height; int diameter; Cap capType; getters/setters, maybe a constructor } オブジェクト指向についての私の理解は、クラスはデータの構造であり、そのデータを操作する方法だということです。これは、このタイプのオブジェクトを除外するようです。私にとって、それらはstructsオブジェクト指向の目的に勝るものではありません。コードの匂いかもしれませんが、必ずしも悪いとは思いません。 そのようなオブジェクトが必要になる場合はありますか？これが頻繁に使用される場合、デザインが疑わしいですか？

43 java  code-quality  object-oriented  code-smell 

ほとんどのOOP言語では、オブジェクトは通常、限られた例外セット（たとえば、Pythonのタプルや文字列など）を使用して変更可能です。ほとんどの関数型言語では、データは不変です。 可変オブジェクトと不変オブジェクトの両方が、独自の長所と短所の完全なリストをもたらします。 たとえば、（明示的に宣言された）可変データと不変データがあるscalaのような両方の概念を結合しようとする言語があります（間違っている場合は修正してください、scalaの知識は限られています）。 私の質問は次のとおりです。完全な（原文のまま！）不変性-つまり、オブジェクトが作成された後はオブジェクトを変更できません-は、OOPコンテキストで意味をなしますか？ そのようなモデルの設計または実装はありますか？ 基本的に、（完全な）不変性とOOPは反対ですか、それとも直交ですか？ 動機：OOPでは通常、データを操作し、基礎となる情報を変更（変更）し、それらのオブジェクト間の参照を保持します。たとえば、別のオブジェクトを参照Personするメンバーを持つクラスのオブジェクト。父親の名前を変更すると、更新の必要なく、これはすぐに子オブジェクトに表示されます。不変なので、父と子の両方に新しいオブジェクトを構築する必要があります。ただし、共有オブジェクト、マルチスレッド、GILなどを使用すると、kerfuffleがはるかに少なくなります。fatherPerson

43 object-oriented  immutability 

時間が経つにつれて、SOLIDの 2つの部分、「S」と「O」を理解できました。 「O」–継承と戦略パターンの助けを借りて、オープンクローズドプリンシプルを学びました。 “ S” – ORMの学習中に単一責任の原則を学習しました（永続化ロジックはドメインオブジェクトから取り除かれます）。 同様に、SOLIDの他の部分（「L」、「I」、「D」）を学習するのに最適な領域/タスクは何ですか？ 参照資料 msdn-C＃でのSOLID原則違反の危険性 channel9-.NET / C＃でのSOLID Principlesの適用 OOPS原則（固体原則）

43 object-oriented  solid 

コントローラがサービスの代わりにリポジトリを呼び出すのは悪い習慣ですか？ さらに説明する： 優れた設計では、コントローラーがサービスを呼び出し、サービスがリポジトリを使用することがわかります。 ただし、コントローラーにはロジックがない場合や必要ない場合があり、dbからフェッチしてビューに渡すだけでよい場合があります。 そして、私はリポジトリを呼び出すだけでそれを行うことができます-サービスを呼び出す必要はありません-それは悪い習慣ですか？

43 design-patterns  object-oriented  mvc  repository 

よると、原始的強迫観念ではないコードのにおいがある場合は？、Stringオブジェクトの代わりに郵便番号を表すZipCodeオブジェクトを作成する必要があります。 しかし、私の経験では、私は見たいです public class Address{ public String zipCode; } の代わりに public class Address{ public ZipCode zipCode; } 後者では、プログラムを理解するためにZipCodeクラスに移動する必要があると思うからです。 そして、私はすべてのプリミティブデータフィールドがあるかのように感じているクラスに置き換えた場合、私は定義を参照するために多くのクラス間を移動する必要があると考えているから苦しみヨーヨー問題（アンチパターン）。 そこで、ZipCodeメソッドを新しいクラスに移動したいと思います。例えば： 古い： public class ZipCode{ public boolean validate(String zipCode){ } } 新着： public class ZipCodeHelper{ public static boolean validate(String zipCode){ } } そのため、郵便番号を検証する必要があるのはZipCodeHelperクラスに依存するだけです。そして、私は原始的な強迫観念を保持する別の「利点」を見つけました。たとえば、文字列列zipCodeを持つアドレステーブルなど、クラスがシリアル化された形式のように見えます。 私の質問は、「ヨーヨーの問題を回避する」（クラス定義間を移動する）が「原始的な強迫観念」を許可する正当な理由ですか？

42 object-oriented  coding-style 

アプリケーションを設計しているだけで、SOLIDとOOPを正しく理解しているかどうかはわかりません。クラスは1つのことを実行し、適切に実行する必要がありますが、一方で、クラスは実際のオブジェクトを表します。 私の場合、データセットで特徴抽出を行い、機械学習分析を行います。私は3つのクラスを作成できると思います FeatureExtractor データセット アナライザ しかし、FeatureExtractorクラスは何も表さず、クラスというよりもルーチンのようなものにします。使用される関数はextract_features（）1つだけです。 一つのことではなく一つのことを表すクラスを作成するのは正しいですか？ 編集：それが重要かどうかはわかりませんが、私はPythonを使用しています そして、extract_features（）がそのように見える場合：そのメソッドを保持する特別なクラスを作成する価値はありますか？ def extract_features(df): extr = PhrasesExtractor() extr.build_vocabulary(df["Text"].tolist()) sent = SentimentAnalyser() sent.load() df = add_features(df, extr.features) df = mark_features(df, extr.extract_features) df = drop_infrequent_features(df) df = another_processing1(df) df = another_processing2(df) df = another_processing3(df) df = set_sentiment(df, sent.get_sentiment) return df

42 object-oriented  object-oriented-design  solid 

私は、OOPの名詞に基づいた動詞を使用することが合法かどうか疑問に思っています。 私はこの素晴らしい記事に出くわしましたが、それが主張する点にはまだ賛成しません。 この問題をもう少し説明するために、この記事では、たとえばFileWriterクラスが存在するべきではないと述べていますが、書き込みはアクションなので、クラスのメソッドである必要がありFileます。RubyプログラマーはFileWriterクラスの使用に反対する可能性が高い（RubyはメソッドFile.openにファイルへのアクセスを使用する）のに対し、Javaプログラマーはそうではないため、多くの場合言語に依存していることに気付くでしょう。 私個人の（そしてもちろん、非常に謙虚な）視点は、そうすることは単一責任の原則を破ることだということです。PHPでプログラミングしたとき（PHPは明らかにOOPに最適な言語だからです）、この種のフレームワークをよく使用します。 <?php // This is just an example that I just made on the fly, may contain errors class User extends Record { protected $name; public function __construct($name) { $this->name = $name; } } class UserDataHandler extends DataHandler /* knows the pdo object */ { public function …

42 object-oriented  solid  single-responsibility 

「ユースケース」、「ユーザーストーリー」、「使用シナリオ」の区別について、正確でありながらシンプルで理解しやすい定義はありますか？ 多くの説明がありますが、今のところ、1つか2つの文の違いを説明している人はいません... （例：http : //c2.com/cgi-bin/wiki?UserStoryAndUseCaseComparisonは非常に長く取得が難しく、議論に満ちています）

42 agile  object-oriented 

オブジェクト指向プログラミング（OOP）は、たとえばPythonとは異なり、ファーストクラスの機能を持たないJavaとは異なるため、この質問は多少言語に依存しませんが、完全ではありません。 言い換えれば、Javaのような言語で不必要なクラスを作成することに対する罪悪感は減りますが、Pythonのような定型的でない言語にはもっと良い方法があるかもしれないと感じています。 私のプログラムは、比較的複雑な操作を何度も行う必要があります。その操作には多くの「ブックキーピング」が必要であり、いくつかの一時ファイルを作成および削除する必要があります。 そのため、他の多くの「サブオペレーション」も呼び出す必要があります。すべてを1つの巨大なメソッドに入れるのは、あまり良くなく、モジュール式で、読みやすいなどではありません。 今、これらは私の頭に浮かぶアプローチです： 1.パブリックメソッドを1つだけ持つクラスを作成し、そのインスタンス変数にサブ操作に必要な内部状態を保持します。 次のようになります。 class Thing: def __init__(self, var1, var2): self.var1 = var1 self.var2 = var2 self.var3 = [] def the_public_method(self, param1, param2): self.var4 = param1 self.var5 = param2 self.var6 = param1 + param2 * self.var1 self.__suboperation1() self.__suboperation2() self.__suboperation3() def __suboperation1(self): # Do something with self.var1, self.var2, …

40 object-oriented  python  object-oriented-design 

AS3アプリケーションとバックエンドとの通信方法を変更するプロセスを進めており、RESTシステムを実装して古いシステムを置き換えるプロセスを進めています。 悲しいことに、作業を開始した開発者は現在、長期の病気休暇中であり、私に引き継がれています。私は過去1週間かそこらでこれを使って作業しており、システムを理解していますが、心配していることが1つあります。関数の関数への受け渡しが多いようです。たとえば、サーバーへの呼び出しを行うクラスは、プロセスが完了してエラーが処理されたときにオブジェクトを呼び出して渡す関数を受け取ります。 それは恐ろしい練習であると感じる「悪い気持ち」を与えてくれます。そして、いくつかの理由を考えることができますが、システムにやり直しを提案する前に確認が必要です。この問題の経験がある人はいないだろうか？

40 object-oriented  object-oriented-design  rest 

赤、緑、リファクタリングのサイクルを実行するときは、常にテストに合格するための最小限のコードを記述する必要があります。これは私がTDDについて教えられてきた方法であり、ほとんどすべての本がプロセスを説明する方法です。 しかし、ロギングはどうですか？ 正直なところ、実際に複雑なことが起こっていない限り、アプリケーションでのログ記録はほとんど使用していませんが、適切なログ記録の重要性に関する多くの投稿を見てきました。 そのため、例外をログに記録する以外に、適切にテストされたアプリケーション（ユニット/統合/受け入れテスト）にログを記録することの本当の重要性を正当化できませんでした。 だから私の質問は： TDDを実行している場合、ログを記録する必要がありますか？テストに失敗しても、アプリケーションのどこが悪いのかわかりませんか？ 各クラスの各メソッドにロギングプロセスのテストを追加する必要がありますか？ たとえば、実稼働環境でいくつかのログレベルが無効になっている場合、テストと環境の間に依存関係が生じませんか？ 人々はログがデバッグを容易にする方法について話しますが、TDDの主な利点の1つは、テストの失敗によって何が間違っているかを常に知っていることです。 私がそこに欠けているものはありますか？

40 design  object-oriented  unit-testing  tdd  logging 

私は構文、抽象クラスに適用されるルールを知っており、抽象クラスの使用法を知りたい 抽象クラスは直接インスタンス化できませんが、他のクラスによって拡張できます そうすることの利点は何ですか？ インターフェースとどう違うのですか？ 1つのクラスで複数のインターフェイスを実装できるが、1つの抽象クラスしか拡張できないことを知っています。インターフェイスと抽象クラスの違いはそれだけですか？ インターフェースの使用法を知っています。JavaでのAWTのイベント委任モデルからそれを学びました。 どのような状況でクラスを抽象クラスとして宣言する必要がありますか？その利点は何ですか？

40 java  object-oriented  abstract-class 

私の学校のCSプログラムでは、オブジェクト指向プログラミングについては一切言及していません。そのため、私はそれを補足するために独力で読んでいます。具体的には、Bertrand MeyerによるObject Oriented Software Constructionです。 Meyerは、クラスが実装に関する可能な限り多くの情報を隠すべきであると繰り返し指摘していますが、これは理にかなっています。特に、彼は、属性（つまり、クラスの静的で計算されていないプロパティ）とルーチン（関数/プロシージャ呼び出しに対応するクラスのプロパティ）を互いに区別できないと繰り返し主張しています。 たとえば、クラスPersonに属性がある場合、定数属性として定義されている場所またはのようなものに内部的に対応するageかどうかを表記法から判断Person.ageすることは不可能であると主張します。これは私にとって理にかなっています。ただし、彼は次のように主張し続けています。return current_year - self.birth_datereturn self.ageself.age クラスの短い形式として知られるクラスの標準クライアントドキュメントは、特定の機能が属性または関数のどちらであるかを明らかにしないように考案されます。 つまり、クラスのドキュメントでさえ、「getter」が計算を実行するかどうかを指定することを避けるべきだと主張しています。 これ、私は従わない。この区別をユーザーに知らせることが重要になるのは、ドキュメントだけではありませんか？Personオブジェクトで満たされたデータベースを設計する場合Person.age、高価な呼び出しかどうかを知ることは重要ではないので、何らかのキャッシュを実装するかどうかを決定できますか？彼が言っていることを誤解していませんか、それとも彼はOOP設計哲学の特に極端な例ですか？

39 design  object-oriented  documentation  performance 

UMLクラス図の表記法のいくつかについて混乱しています。 協会が何を意味するのか、私はよく知っています。2つのクラスのインスタンス間の関係（1つのクラスのインスタンスが作業を実行するために2番目のクラスのインスタンスを知る必要がある場合）は、関連関係です。関連とは、クラスAがクラスBのインスタンスへの参照（フィールド）を持っていることを意味することがよくあります。 しかし、集計と構成の矢印の意味を理解するのに苦労しています。私の混乱の一部は、これらの表記法の異なる定義に遭遇したことが原因でした。 集計表記法の2つの定義： 定義1： 2つのクラス間の集約表記は、クラスA のインスタンスがクラスBのインスタンスのコレクション（リスト、配列など）を保持する場合に適しています。 定義2：クラスAのインスタンスがクラスBのインスタンスへの参照を保持し、BインスタンスがAインスタンスのライフサイクルに依存している場合、2つのクラス間の集約リンクが適しています。意味：クラスAのインスタンスが削除されると、クラスBのインスタンスも削除されます。クラスBのインスタンスは、クラスAのインスタンスに完全に含まれます。クラスB（通常のAssociation）。 構成表記の意味と、それが集約表記とどのように異なるかについては、わかりません。 定義を明確にして、理解してください。具体的な例を歓迎します。

39 object-oriented  uml  class-diagram