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

Javaには、メソッドに使用可能な4つのアクセス修飾子があります。 public -すべてのクラスがこのメソッドを使用できます。 protected -同じパッケージ内のクラスおよび任意のパッケージ内のサブクラスは、このメソッドを使用できます。 private -このクラスのみがこのメソッドを使用できます。 no modifier （ "package private"）-同じパッケージ内のクラスのみがこのメソッドを使用できます。 よく起こるのは、すべてのサブクラスが使用できる便利なメソッドをスーパークラスに入れたいということです。しかし、他のクラスがこのメソッドにアクセスすることは意味がなく、ある意味ではカプセル化を破ります。 したがって、これらの便利なメソッドをスーパークラスpublicまたはで宣言するprotected必要があります。これにより、少なくともパッケージ内の他のすべてのクラスに公開されます。それらはサブクラスによってのみ使用されることを意図していますが。 subclasses-onlyJavaにアクセス修飾子がない理由はありますか？私にはとても奇妙に思えます。何か不足していますか？ また、subclasses-onlyアクセス修飾子は、サブクラスにのみ変数を公開する場合にも役立ちます。私にはこれがよく起こります。

16 java  object-oriented  inheritance  language-features 

現実世界の何かを参照する機能プログラミングの優れたメンタルモデルやメタファーを持っている人はいますか？ オブジェクト指向プログラミングは直感的に理にかなっています。プロパティを持っているものがありますが、時にはプロパティを操作したり、プロパティ（メソッド）を計算したりすることもできます。（例：車、形、猫）。 私は関数型プログラミングに何の害もないし、2つの美徳についての議論には興味がありません。オブジェクト指向プログラミングと同じように、メタファーまたはメンタルモデルが必要です。 機能的パラダイムでプログラミングするための優れたメンタルモデルまたは現実世界のメタファーとは何ですか？機能を処理する機能で構成される機能については、立ち上がって発言するための確固たる場所がなくなります。

16 object-oriented  functional-programming 

OOPの「抽象化」の定義を理解しようとしています。 私はいくつかの主要な定義に出会いました。それらはすべて有効ですか？それらの1つは間違っていますか？よくわかりません。（定義を自分の言葉で書き直しました）。 定義1： 抽象化とは、現実世界からオブジェクトを取り出し、それをプログラミング用語に変換する概念です。そのような作成などのHumanクラスを、それを与えint health、int age、String name、などの性質、およびeat()等の方法。 定義2： より一般的な定義。抽象化は、「物事をより一般的/単純化/抽象化する」ことが関係するソフトウェアシステムのどこででも起こる概念です。いくつかの例： 継承階層。上位クラスがより単純またはより一般的であり、より一般的で抽象的な実装を定義します。階層の下位クラスはより具体的であり、より詳細な実装を定義します。 カプセル化を使用して、クラスの実装の詳細を他のクラスから隠すことにより、クラスを外部ソフトウェアの世界により「抽象化」（単純化）します。 定義3 別の一般的な定義：抽象化とは、物事の詳細や具体的な実装から、物事の種類（クラス）、利用可能な操作（メソッドなど）にフォーカスを移動する概念です。より抽象的な。（これは、ソフトウェアシステム内の任意のコンテキストで実行できます）。カプセル化は実装の詳細を隠し、物の種類とそれらのより一般的かつ抽象的な定義のみを表示することを意味するため、例えばカプセル化するときに行われます。Anotehrの例ではList、Javaでオブジェクトを使用します。このオブジェクトは実際にArrayListaまたはaの実装詳細を使用しますLinkedListが、この情報はより一般的な名前を使用して抽象化されListます。 これらの定義は正しいですか？（私は最も一般的で受け入れられている定義に言及しています）。

16 object-oriented  abstraction 

私はActionクラスを持っているUIコードで作業しています、このようなもの- public class MyAction extends Action { public MyAction() { setText("My Action Text"); setToolTip("My Action Tool tip"); setImage("Some Image"); } } このActionクラスが作成されたとき、Actionクラスはカスタマイズできないと想定されていました（ある意味で、そのテキスト、ツールチップ、またはイメージはコードのどこでも変更されません）。現在、コード内の特定の場所でアクションテキストを変更する必要があります。そのため、ハードコーディングされたアクションテキストをコンストラクターから削除し、引数として受け入れるように同僚に提案しました。以下のこのコードのようなもの- public class MyAction extends Action { public MyAction(String actionText) { setText(actionText); setTooltip("My Action tool tip"); setImage("My Image"); } } ただし、setText()メソッドは基本クラスに属しているため、アクションインスタンスが作成された場所にアクションテキストを渡すために柔軟に使用できると考えています。そうすれば、既存のMyActionクラスを変更する必要はありません。したがって、彼のコードは次のようになります。 MyAction action = new MyAction(); //this creates action …

16 java  design  object-oriented  refactoring 

OOPの概念に対するOracleの紹介を読んでいたときに、この説明に出会いました。 実世界のオブジェクトには2つの特性があります。それらはすべて状態と動作を持っています。犬には状態（名前、色、品種、空腹）と行動（（える、フェッチング、尾を振る）があります。ソフトウェアオブジェクトは、概念的には実世界のオブジェクトに似ています。それらも状態と関連する動作で構成されています。 そのパッセージに関する私の問題は、状態を記述するときに、その属性もそこにあるということです。たとえば、犬の名前と色はその属性であり、空腹または喉が渇いているのはその状態です。 したがって、私の意見では、オブジェクトの特性を属性、状態、および動作の 3つの部分に分ける方がより正確です。 確かに、これをプログラミング言語に翻訳すると、属性と状態の両方がフィールド/変数に格納され、動作がメソッド/関数に格納されるため、3分割パーティションが2分割パーティションになることがわかります。 しかし、概念的に言えば、3つのものを分離する方が理にかなっています。 別の例を次に示します。ランプを考えてみましょう。ランプのサイズと点灯するかどうかの両方が状態であると言うことは、私の意見では広まっています。ランプサイズは状態ではなく属性であり、ランプのオン/オフは状態です。 または私は何かを見逃しましたか？

16 object-oriented 

多くの異なるファイルを持つプロジェクトを扱うとき、私は常に、パーツが相互にどのように相互作用するかについて、ゆるい追跡をしているように見えます。私は小さなコンポーネントを単独で理解するのに本当に大きな問題を抱えたことはありませんが、プロジェクトの複雑さが増すにつれて、何が起こっているのかを精神的に理解することができなくなります。メソッドとソースファイルの数が増えると、特にOOPプロジェクトでこれに気付きます。 私の経歴：私は独学のWebプログラマーです。私は主にpythonを使用して迅速で汚いスクリプトを処理しましたが、いくつかの基本的なdjangoプロジェクトも実行しました。私のようなWebフレームワークのようなフラスコ、単一ファイルレイアウトの単純さに、私は簡単に何が起こっているかの（主に）追跡することができますので。 私は今、誰かが開発した大規模なZend Framework PHPプロジェクトとやり取りする必要がある状況にいることに気づき、多数のファイルに広がるコードを理解しようとすることに圧倒されます。 他の誰かが開発した大規模なコードベースを理解するために、どのテクニックとプロセスが有用だと思いましたか？全体像を把握するのに役立つ特定の図はありますか？

16 web-development  object-oriented  zend-framework  technique  mind-mapping 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 OOPの継承の概念を説明しようとする場合、一般的な例は哺乳類の例です。私見、これは本当に悪い例です。なぜなら、初心者がこの概念を間違った方法で使用するようになるからです。さらに、彼らが日々のデザインの仕事で直面するのは一般的なデザインではありません。 それでは、継承を使用して解決される素敵でシンプルで具体的な問題は何でしょうか？

16 design-patterns  object-oriented  inheritance 

これらの行を読むだけで データが本来オブジェクトである場合は、オブジェクトストア（「NoSQL」）を使用します。リレーショナルデータベースよりもはるかに高速です。 データがリレーショナルデータである場合、リレーショナルデータベースのオーバーヘッドはそれだけの価値があります。 から- http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern それで、データが本質的にリレーショナルであるかオブジェクト指向であるかをどのようにして知ることができますか？

16 object-oriented  database  relational-database 

大規模なASP.NET Webフォームアプリケーションの既存のコードベースのクリーンアップを開始する方法に関する戦略を学習することを目的として、「レガシーコードとクリーンコードの効果的な使用」を読んでいます。 このシステムは2005年から使用されており、それ以来多くの機能強化が行われています。もともと、コードは次のように構成されていました（そして、まだ大部分はこのように構成されています）： ASP.NET（aspx / ascx） コードビハインド（c＃） ビジネスロジックレイヤー（c＃） データアクセス層（c＃） データベース（Oracle） 主な問題は、コードがオブジェクト指向のように手続き的に偽装されていることです。これは、両方の本で説明されているすべてのガイドラインに事実上違反しています。 これは、ビジネスロジックレイヤーの典型的なクラスの例です。 public class AddressBO { public TransferObject GetAddress(string addressID) { if (StringUtils.IsNull(addressID)) { throw new ValidationException("Address ID must be entered"); } AddressDAO addressDAO = new AddressDAO(); return addressDAO.GetAddress(addressID); } public TransferObject Insert(TransferObject addressDetails) { if (StringUtils.IsNull(addressDetails.GetString("EVENT_ID")) || StringUtils.IsNull(addressDetails.GetString("LOCALITY")) || …

16 c#  .net  unit-testing  object-oriented 

データベースを操作しながら、ユニットのテストを可能にするOOP戦略にはどのようなものがありますか？Userクラスがあり、本番環境がMySQLに対して機能しているとします。PHPを使用してここに示す2つの可能なアプローチがあります。 load()およびのインターフェイスで$ data_sourceを渡し、save()データのバックエンドソースを抽象化します。テスト時には、別のデータストアを渡します。 $ user = new User（$ mysql_data_source）; $ user-> load（ 'bob'）; $ user-> setNickname（ 'Robby'）; $ user-> save（）; データベースにアクセスし、結果行をユーザーのコンストラクターに渡すファクトリーを使用します。テスト時には、$ rowパラメーターを手動で生成するか、UserFactory :: $ data_sourceでオブジェクトをモックします。（変更をレコードに保存するにはどうすればよいですか？） class UserFactory { static $data_source; public static function fetch( $username ) { $row = self::$data_source->get( [params] ); $user = new User( $row ); return $user; …

16 architecture  unit-testing  object-oriented  database 

単一責任原則は、「クラスには変更の理由が1つあるべきだ」と述べています。 MVCパターンでは、コントローラーの仕事は、ビューとモデルの間を仲介することです。GUIでユーザーが行ったアクションをレポートするためのビューのインターフェースを提供し（ビューの呼び出しを許可するcontroller.specificButtonPressed()など）、データを操作したり操作を呼び出すためにモデルの適切なメソッドを呼び出すことができます（例model.doSomething()） 。 この意味は： ビューにユーザーアクションを報告するための適切なインターフェイスを提供するために、コントローラーはGUIについて知る必要があります。 また、モデルの適切なメソッドを呼び出すことができるように、モデルのロジックについて知る必要があります。 つまり、GUIの変更とビジネスロジックの変更という2つの理由があります。 GUIが変更された場合（新しいボタンが追加された場合など）、コントローラーは、ユーザーがこのボタンを押したことをビューが報告できるように新しいメソッドを追加する必要がある場合があります。 また、モデルのビジネスロジックが変更された場合、モデルの正しいメソッドを呼び出すためにコントローラーを変更する必要があります。 そのため、Controllerには2つの変更可能な理由があります。SRPを壊しますか？

16 design  object-oriented  mvc  single-responsibility 

ドメイン駆動型設計（DDD）に従う場合、たまたま別のアグリゲートのルートエンティティである内部エンティティへの参照をルートアグリゲートが保持するのは正しいですか？ 私はこれが正しいとは思わない、主にブルーブックのこのルールのため： AGGREGATE境界の外側にあるものは、ルートENTITYを除き、内側にあるものへの参照を保持できません。ルートENTITYは、内部ENTITIESへの参照を他のオブジェクトに渡すことができますが、それらのオブジェクトは一時的にのみそれらを使用でき、参照を保持することはできません。ルートはVALUE OBJECTのコピーを別のオブジェクトに渡すことができますが、それがどうなるかは問題ではありません。これは単なるVALUEであり、AGGREGATEとの関連付けがなくなるためです。 ルートアグリゲートが別のルートアグリゲートへの参照を保持している場合、前者の境界に違反しており、アグリゲートの概念全体が破損しているため、ルートアグリゲートが別のルートアグリゲートへの参照を保持する必要があるように見える場合は、別のエンティティを作成するには、おそらく他のルートエンティティと同じメンバーの一部を共有しますが、この本の他のルールが示すように、グローバルアイデンティティはありません。 ルートエンティティにはグローバルアイデンティティがあります。境界内のエンティティには、AGGREGATE内でのみ一意のローカルIDがあります。 これは正しい方法だと思いますが、それは反復的で冗長であると感じるので（DDDのコンテキストを取り除いて、純粋なOOPで）、フィードバックを求めています。

16 object-oriented  domain-driven-design 

私はセマンティクスについての意見を探しているのではなく、単にゲッターを賢明に使用することが実際の障害である場合を探しています。たぶん、それらに頼るという終わりのないスパイラルに私を投げ込むかもしれません、多分、代替案はよりきれいで、ゲッターを自動的に処理するなどです。具体的な何か。 私はすべての議論を聞いた、彼らはあなたがデータソースとしてオブジェクトを扱うことを余儀なくされるので、彼らが悪いと聞いた、彼らはオブジェクトの「純粋な状態」に違反しているたくさん受け入れる」。 しかし、a getDataが悪いものである理由はまったく理にかなったものではなく、実際には、セマンティクス、ゲッター自体は素晴らしいと主張する人もいますがgetX、名前を付けないでください、これは少なくとも面白いです。 私が賢明にゲッターを使用すると、そしてオブジェクトの完全性がそれを外に出しても壊れないデータのために、意見なしで壊れる1つのことは何ですか？ もちろん、何かを暗号化するために使用される文字列にゲッターを許可することは愚かなことではありませんが、システムが機能するために必要なデータについて話しているのです。たぶん、あなたのデータが通って引っ張られProviderたオブジェクトから、しかし、まだ、オブジェクトがまだ許可する必要がありProviderませんし$provider[$object]->getData、その周りに方法はありません。 なぜ私が求めているのですか：私にとって、ゲッターは賢明に使用され、「安全」として扱われるデータで神に送信され、私のゲッターの99％はオブジェクトを識別するために使用されますObject, what is your name? Object, what is your identifier?。プログラミングに関するほとんどすべてがアイデンティティであり、オブジェクト自体よりもそれが何であるかをよく知っている人がいるので、オブジェクトを扱う人はオブジェクトに関するこれらのことを知っているはずです。あなたが純粋主義者でない限り、私は本当の問題を見ることはできません。 「なぜゲッター/セッター」が悪いのかに関するStackOverflowの質問をすべて見てきました。99％のケースでセッターが本当に悪いことに同意しますが、ゲッターは韻を踏むだけで同じように扱われる必要はありません。 セッターはオブジェクトのIDを危険にさらし、誰がデータを変更しているかをデバッグするのを非常に難しくしますが、ゲッターは何もしません。

15 object-oriented 

Clojureなどの関数型プログラミング言語への（明らかに限定された）経験から、データのカプセル化はそれほど重要ではないようです。通常、マップやセットなどのさまざまなネイティブタイプは、オブジェクトよりもデータを表すための優先通貨です。さらに、そのデータは一般に不変です。 たとえば、この件に関するインタビューで、Clojureの名声のRich Hickeyからの有名な引用の1つを次に示します。 Fogus：その考えに従うと、Clojureがそのタイプでデータ隠蔽のカプセル化を行わないという事実に驚く人もいます。なぜデータ隠蔽をやめることにしたのですか？ ヒッキー：Clojureがプログラミングを抽象化に重点を置いていることを明確にしましょう。ただし、ある時点で、誰かがデータにアクセスする必要があります。また、「プライベート」という概念がある場合、それに対応する特権と信頼の概念が必要です。そして、それは非常に多くの複雑さと小さな価値を追加し、システムに硬直性をもたらし、しばしば物を本来あるべきでない場所に住まわせます。これは、単純な情報がクラスに入れられるときに発生する他の損失に追加されます。データが不変である限り、誰かが変更される可能性のあるものに依存するようになる可能性があることを除いて、アクセスを提供することによってもたらされる害はほとんどありません。まあ、大丈夫、人々は実際の生活の中で常にそうしていて、物事が変わると適応します。そして、それらが合理的であれば、彼らは、将来変化する可能性のある何かに基づいて決定を下すときを知っています。だから、それはリスク管理の決定であり、プログラマは自由にすべきだと思う。抽象化に向けてプログラミングを行い、実装の詳細と結婚することを警戒したいという感覚がなければ、優秀なプログラマーになることは決してありません。 オブジェクト指向の世界から来て、これは私が長年にわたって学んだ神聖な原則のいくつかを複雑にするようです。これらには、情報隠蔽、デメテルの法則、統一アクセス原則などが含まれます。カプセル化という一般的なスレッドにより、他の人が触れてはいけないことを知るためのAPIを定義できます。本質的に、一部のコードのメンテナーがコンシューマーのコードにバグを導入する可能性を心配することなく、自由に変更やリファクタリングを行えるようにするコントラクトを作成します（オープン/クローズ原則）。また、他のプログラマーがそのデータを取得または構築するために使用できるツールを知るための、クリーンで精選されたインターフェースを提供します。 データへの直接アクセスが許可されると、そのAPIコントラクトは壊れ、カプセル化の利点はすべてなくなるようです。また、厳密に不変のデータは、ドメイン固有の構造（オブジェクト、構造体、レコード）の受け渡しを、状態とその状態で実行できる一連のアクションを表すという意味であまり役に立たないようです。 APIを定義する必要があり、多くの開発者がシステムの特定の部分の操作に関与するなど、コードベースのサイズが巨大になったときに発生するように思われるこれらの問題に、機能コードベースはどのように対処しますか？これらのタイプのコードベースでこれがどのように処理されるかを示すこの状況の例はありますか？

15 object-oriented  architecture  functional-programming 

OOPの原則を実践する方法として、C ++で中規模のOOPアプリケーションを作成しています。 私のプロジェクトにはいくつかのクラスがあり、それらのいくつかはランタイム構成パラメーターにアクセスする必要があります。これらのパラメーターは、アプリケーションの起動時にいくつかのソースから読み取られます。ユーザーのhome-dirにある設定ファイルから読み込まれるものもあれば、コマンドライン引数（argv）であるものもあります。 そこで、クラスを作成しましたConfigBlock。このクラスは、すべてのパラメーターソースを読み取り、適切なデータ構造に格納します。例としては、構成ファイルまたは--verbose CLIフラグでユーザーが変更できるパスとファイル名があります。次に、ConfigBlock.GetVerboseLevel()この特定のパラメーターを読み取るために呼び出すことができます。 私の質問：このようなすべてのランタイム構成データを1つのクラスに収集することをお勧めしますか？ 次に、クラスはこれらすべてのパラメーターにアクセスする必要があります。私はこれを達成するためのいくつかの方法を考えることができますが、どの方法を取るべきかはわかりません。クラスのコンストラクターは、次のようにConfigBlockへの参照を指定できます。 public: MyGreatClass(ConfigBlock &config); または、CodingBlockの定義を含むヘッダー「CodingBlock.h」を含めるだけです。 extern CodingBlock MyCodingBlock; その後、クラスの.cppファイルのみがConfigBlockのものを含めて使用する必要があります。 .hファイルは、このインターフェイスをクラスのユーザーに導入しません。ただし、ConfigBlockへのインターフェイスはまだありますが、.hファイルからは隠されています。 このように隠すのは良いですか？ インターフェイスをできるだけ小さくしたいのですが、最終的には、構成パラメーターを必要とするすべてのクラスがConfigBlockに接続する必要があると思います。しかし、この接続はどのように見えますか？

15 design-patterns  object-oriented  c++