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

ここに私が意味するものがあります： class MyClass { int arr1[100]; int arr2[100]; int len = 100; void add(int* x1, int* x2, int size) { for (int i = 0; i < size; i++) { x1[i] += x2[i]; } } }; int main() { MyClass myInstance; // Fill the arrays... myInstance.add(myInstance.arr1, myInstance.arr2, myInstance.len); } addクラスメソッドなので、必要なすべての変数に既にアクセスできますが、これは悪い考えですか？これを行うべき、またはすべきでない理由はありますか？

14 object-oriented  c++  class-design  methods  encapsulation 

ポリモーフィズムの概念を使用してクラス階層を作成し、親の参照を使用すると、オブジェクトを持っている特定の型を知らなくてもインターフェイス関数を呼び出します。これは素晴らしい。例： 動物のコレクションがあり、すべての動物の機能を呼び出しeatます。犬を食べるのか、猫を食べるのかは気にしません。継承と実装クラス以外から-しかし、同じクラス階層には、追加を持っている動物持ってAnimal、例えばmakeEggs、getBackFromTheFreezedStateようにしています。そのため、関数の一部のケースでは、追加の動作を呼び出す特定のタイプを知りたい場合があります。 たとえば、朝の時間で、動物だけの場合はを呼び出しますeat。それ以外の場合は、人間の場合は最初washHandsに呼び出し、次に呼び出しgetDressedますeat。この場合の対処方法は？多型が死ぬ。コードの匂いのように聞こえるオブジェクトのタイプを調べる必要があります。このケースを処理する一般的なアプローチはありますか？

14 design-patterns  object-oriented  polymorphism  subtypes 

JavaのReactiveX （RxおよびReactive Extensionsとも呼ばれます）の実装であるRxJavaを始めたばかりです。本当に私を襲った何かがの巨大な大きさだったRxJavaのフロアブルクラス：それは460個のメソッドを持っています！ 公平であるために： オーバーロードされたメソッドが多数あり、メソッドの総数が大幅に増えます。 おそらくこのクラスは分割されるべきですが、RxJavaに関する私の知識と理解は非常に限られています。RxJavaを作成した人々は確かに非常にスマートであり、それらは作成するために選択するための有効な引数を、おそらくを提供することができますフロアブル剤を非常に多くの方法で。 一方： RxJavaはのJava実装であるMicrosoftの反応性の拡張機能、およびそれがさえ持っていないフロアブルクラスを、ので、これは盲目的に既存のクラスを移植し、Javaでそれを実施する場合ではありません。 [ 更新：イタリック体の前のポイントは事実正しくありません。マイクロソフトの観察可能な 400以上のメソッドを持つクラスは、RxJavaのための基礎として使用された観察可能なクラス、および流動性は、に似て観察可能な大量のデータのためではなく、ハンドル背圧。そのため、RxJavaチームは既存のクラスを移植していました。この投稿は、元のデザインに挑戦されている必要があり、観察可能マイクロソフトによってクラスではなく、RxJavaのフロアブルクラスを。] RxJavaはわずか3年以上前であるため、これは（Javaの初期リリースの場合のように）優れた（SOLID）クラス設計原則に関する知識が不足しているためにコードが誤って設計されている例ではありません。 Flowableほどの大きさのクラスでは、その設計は本質的に間違っているように見えますが、そうではないかもしれません。このSEの質問に対する1つの答えクラスメソッドの数の制限は何ですか？答えは「必要な数のメソッドを用意する」ことです。 明らかに、言語に関係なくそれらをサポートするためにかなりの数のメソッドを必要とするクラスがいくつかあります。それらは簡単に小さなものに分解されず、かなりの数の特性と属性を持っているからです。例：文字列、色、スプレッドシートセル、データベース結果セット、HTTPリクエスト。これらのことを表現するためのクラス用のメソッドをおそらく数十個用意することは、理不尽に思えません。 しかし、Flowableには460個のメソッドが本当に必要なのでしょうか、それとも非常に巨大なために、必ずしもクラスの設計が悪い例ですか？ [明確にするには：この質問は、具体的RxJavaのに関し、フロアブルクラスではなく、神は、一般的にオブジェクト。]

14 java  object-oriented  class-design  solid  reactive 

domain-speciifcオブジェクトとプレーンな文字列または数字を使用する場合の一般的なガイドラインまたは経験則は何ですか？ 例： 年齢階級と整数？ FirstNameクラスとString？ UniqueID vs String PhoneNumberクラスvs文字列vs Long？ DomainNameクラスとString？ ほとんどのOOP実践者は、間違いなくPhoneNumberとDomainNameの特定のクラスを言うと思います。それらを有効にするものとそれらを比較する方法に関するルールが増えると、単純なクラスをより簡単かつ安全に処理できるようになります。しかし、最初の3つについては、さらに議論があります。 私は「年齢」クラスに出会ったことはありませんが、非負でなければならないので理にかなっていると主張することができます（負の年齢について議論できることはわかっていますが、プリミティブ整数とほぼ同等である良い例です）。 文字列は「名」を表すのが一般的ですが、空の文字列は有効な文字列ですが、有効な名前ではないため、完全ではありません。通常、比較は大文字小文字を無視して行われます。空のチェック、大文字と小文字を区別しない比較などを行う方法はありますが、これを行うにはコンシューマーが必要です。 答えは環境に依存しますか？私は主に、おそらく10年以上にわたって存続し、維持されるエンタープライズ/高価値ソフトウェアに関心を持っています。 おそらく私はこれを考えすぎていますが、クラスとプリミティブのどちらを選択するかについてのルールがあるかどうかを知りたいと思います。

14 java  c#  object-oriented  domain-driven-design  domain-objects 

私は「並列配列」またはリストと呼んでいるものを使用するコード（新しいコード）を実行しています。つまり、関連データを含む2つの配列があり、配列内の位置（インデックス）によってリンクされています。 私はこれを混乱させ、あらゆる種類のエラーを起こしやすいと考えています。私が通常提案する解決策は、CompanyCompanyIdおよびCompanyNameフィールドで呼び出されるオブジェクトを作成することです。 非常に現実的な例： List<string> companyNames; List<int> companyIds; //...They get populated somewhere and we then process for(var i=0; i<companyNames.Count; i++) { UpdateCompanyName(companyIds[i],companyNames[i]); } これらの並列配列は悪い習慣と見なされていますか？

14 object-oriented  programming-practices  code-smell 

私はまだ見習いプログラマーであると考えているので、私はいつも典型的なプログラミングのための「より良い」方法を学ぼうとしています。今日、私の同僚は私のコーディングスタイルが不必要な仕事をしていると主張しており、他の人から意見を聞きたいと思っています。通常、OOP言語（通常はC ++またはPython）でクラスを設計するとき、初期化を2つの異なる部分に分けます。 class MyClass1 { public: Myclass1(type1 arg1, type2 arg2, type3 arg3); initMyClass1(); private: type1 param1; type2 param2; type3 param3; type4 anotherParam1; }; // Only the direct assignments from the input arguments are done in the constructor MyClass1::myClass1(type1 arg1, type2 arg2, type3 arg3) : param1(arg1) , param2(arg2) , param3(arg3) {} …

14 design  object-oriented  coding-style 

たとえば、コンソールとの間のあらゆる種類の入出力メソッドを備えたコンソールゲームプログラムがあるとします。でしょうが、すべてのシングルでそれらを保つためにスマートにinputOutputクラスなど、より具体的なクラスにそれらを打破startMenuIO、inGameIO、playerIO、gameBoardIO各クラスが1-5程度のメソッドを持っていることなど、？ また、同じメモで、それらを分解する方が良い場合は、IO名前空間に配置して、呼び出しをもう少し冗長にするのが賢明でしょうIO.inGameか？

14 design-patterns  object-oriented  class-design  solid  single-responsibility 

同じクラスを共有する2つ以上のオブジェクトのポイントは、振る舞いが同じ、つまりメソッドが同一であるということなので、これは奇妙な質問のように思えます。 ただし、フィールドに異なる値を割り当てるのと同じ方法でオブジェクトのメソッドを再定義できるOOP言語があるかどうか興味があります。結果は、まったく同じ動作を示さなくなった同じクラスから構築されたオブジェクトになります。 私が間違っていなければ、このJavaScriptを実行できますか？この質問とともに、なぜ誰かがこれをしたいのでしょうか？

14 object-oriented  programming-languages 

次のクラスがあります class Student{ int rollNumber; int marks; public void setResult(int rollNumber, int marks){ this.rollNumber=rollNumber; this.marks=marks; } public void displayResult(){ System.out.println("Roll Number= "+this.rollNumber+" Marks= "+this.marks); } } 次に、次のようにStudentタイプの2つのオブジェクトを作成します Student s1=new Student(); Student s2=new Student(); これで、2つの異なるメモリセットがインスタンスフィールドに割り当てられます。今私の質問は、メモリがメソッドに割り当てられているかどうかです（setResultそしてdisplayResult）に2回または1回です。 次の図を参照してください。どの図が正しい情報を提供しているかを教えてください。

14 java  object-oriented  memory  jvm 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新することがありますので、上のトピックソフトウェア工学スタックExchange用。 2年前に閉店。 OOPは、非OOP手続き型プログラミングとは対照的に、ソフトウェアの複雑さを管理する効果的な戦略と見なされることがよくあります。 この概念をテストする研究はありますか？OOPが大規模なプロジェクトの複雑さを管理するのに役立つことがしばしば証明されていますか？

14 object-oriented  case-studies 

私は、オープンクローズド原則の意図を理解しています。変更せずに拡張しようとするように指示することで、変更中に既に機能しているものを壊すリスクを減らすことを目的としています。 しかし、この原則が実際にどのように適用されるかを理解するのに苦労しました。私の理解では、それを適用するには2つの方法があります。変更前と変更後： 前：できるだけ抽象化して「未来を予測する」プログラムを作成します。たとえば、将来システムにsが追加されたdrive(Car car)場合、メソッドは変更する必要 Motorcycleがあるため、おそらくOCPに違反します。ただし、この方法drive(MotorVehicle vehicle)は将来変更する必要性が低いため、OCPに準拠しています。 ただし、将来を予測し、システムにどのような変更が加えられるかを事前に知ることは非常に困難です。 変更後：変更が必要な場合、現在のコードを変更する代わりにクラスを拡張します。 練習＃1を理解するのは難しくありません。しかし、適用方法を理解するのに苦労しているのは実践＃2です。 例（YouTubeのビデオから取得しました）：CreditCardオブジェクトを受け入れるクラスにメソッドがあるとします：makePayment(CraditCard card)。1日Voucherがシステムに追加されます。このメソッドはそれらをサポートしていないため、変更する必要があります。 そもそもメソッドを実装するとき、未来とプログラムをより抽象的な用語で予測することに失敗しました（たとえばmakePayment(Payment pay)、今、既存のコードを変更する必要があります）。 練習＃2では、変更するのではなく拡張することで機能を追加する必要があります。どういう意味ですか？既存のコードを単に変更するのではなく、既存のクラスをサブクラス化する必要がありますか？コードの書き換えを避けるために、何らかのラッパーを作成する必要がありますか？ または、原則は「機能を正しく変更/追加する方法」に言及するのではなく、「最初に変更を加える必要がないようにする方法」（つまり、プログラムを抽象化する方法）に言及していますか？

14 design  object-oriented  object-oriented-design  solid 

Webアプリケーションを開発しているとしましょう。私の最初の選択肢は、Fat-Free Framework（F3）およびMVCパターンでPHPを使用することです。来年、Zend Frameworkに切り替えるか、ASP.NET MVCに切り替えることを決定するかもしれません。フレームワークに疎結合されるような方法でアプリケーションを設計しようとするのは理にかなっていますか、それともフレームワークがあまりにも統合されすぎて現実的ではありませんか？ 私が尋ねる唯一の理由は、最近の仲間との会話の中で出てきたからです。仲間は、私のパイを空からF3に疎結合するというアイデアを批判しました。

14 design-patterns  object-oriented  frameworks 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 「フォトアルバムアプリケーションの設計方法を説明する」、「この特定のWebサイトのこの特定の機能を設計する方法を説明する」などのインタビューの質問を収集しましたブラックジャックの）。次に、このものが何百万ある場合はどうなりますか？何を変えますか？ これは、データベーススキーマまたはクラス定義の束（またはその両方）を想定しているようです。私は学校でデータベースについて学んだことがありますが、実際にアプリケーションを設計したことがなく、どこから始めればよいか、思いついた設計が「良い」かどうか、スケーラブルにするために何を変更できるかがわかりません。 これらのシステムを設計するとき、一般的なアプローチまたは思考プロセスはありますか？そして、私が回避しようとする必要がある設計で多くのように思われる一般的な問題/問題？誰かが私にこれらの1つ（または好ましくはすべて、それぞれのニーズを比較しながら）を見て、説明することができますか？ 1）どのエンティティが必要かをどのように思い付きますか？2）すべての関係をどのように決定しますか？3）パフォーマンスの最適化を設計にどのように組み込みますか？4）クラスまたはデータベースを使用してこれを行いますか？違いがありますか（つまり、実際にデータベーステーブルに変換できないクラスがあるでしょうか？） 私が質問している主な理由は、「コーディングインタビューをクラックする」ことを行っていたためであり、私の答えは著者のものとは完全に異なっていたためです。 私の試み： 写真共有アプリを使えば、クラスとテーブルが必ずあります：写真とユーザー。 次に、スキーマを作成しようとしている場合、写真の各人が写真にリンクされていると仮定すると、写真とユーザーをリンクするテーブルがあると思います（このテーブルは必要ですか？そうでない場合でも、それはまだ一般的な習慣ですか？多対多のリレーションシップ用に別のテーブルを作成するかどうか）。 しかし、オブジェクト指向のアプローチをとろうとしている場合は、代わりに、すべての作業を実行し、他の2つのテーブル/クラスからのすべての情報を保持するalbumというクラスを用意します。これは私が本で気づいた1つのことです-クラスの束があり、基本的にすべての情報を持ち、他のクラスを接続する1つのクラス-これは一般的ですか？たとえば、上記の私の例では、これは適用されるように見えますか？ 現時点では、大規模システムの優れたアーキテクチャがどのように見えるかを知る方法がわからないため、いくつかの一般的なルール/ガイドラインに従うことを望んでいます。

14 object-oriented  interview  database  web-applications  database-design 

私は単純な暗号化の演習用にRubyコードを書いていますが、このジレンマに頻繁に遭遇しています（この演習は、知っていなければならないソリティア暗号です）。反復を排除したり、エラーの機会を最小限にしたりする簡潔で高密度のステートメントの代わりに、関数を読みやすくする記述変数とシングルステップステートメントでロジックをパディングするかどうかの問題です。 私の最新の例：私のプログラムは入力を受け取り、厳格な形式のガイドラインのために、入力を暗号化または復号化する必要があるかどうかを簡単に判断できます。単純化するには、暗号化キーとメッセージが互換性があるように変換/生成されたら、暗号化されたメッセージからキーを減算するか、暗号化されていないメッセージにキーを追加して、目的の出力を取得します（キーを暗号化として考え、メッセージ+暗号化=コード、コード-暗号化=メッセージ）。DRYの位置は、暗号化されたメッセージを暗号化されていないメッセージとは異なる方法で変換する必要があることを示しています。これは、関数内にネストされたifステートメントが必要であることを意味しますが、ロジックはしっかりしているように見えます。ただし、このコードは簡単には読み込めません。 一方、アプリケーションが暗号化または復号化を決定するときに設定されるフラグに基づいて呼び出される2つの異なる関数を作成できます。これは読みやすくなりますが、暗号化キーをメッセージに適用する（メッセージを暗号化または復号化する）高レベルの機能を複製します。 読みやすいコード、または簡潔なコードに頼るべきですか？または、この機能を取得して両方の原則を満たす別の方法を逃しましたか？プロジェクトの目的を考慮し、その目的を果たすために最善の決定を下さなければならないスケールに沿った位置ですか？ これまでのところ、読みやすいコードよりも簡潔なDRYコードを強調する傾向があります。

14 object-oriented  coding-style 

私はゲームプログラミングの学位を取得しました。これはコンピューターサイエンスの学位ではないので、理論の多くは実用的なポートフォリオの構築と、ゲーム業界で明らかに重要なJIT学習と思われるものを優先します。最初の主題は「オブジェクト指向プログラミングの紹介」でした。 さまざまなプログラミングパラダイムについて学ぶまで、そのフレーズは気にしませんでした（https://en.wikipedia.org/wiki/Comparison_of_programming_paradigmsからこのリストを取得しています）。 命令的 機能的 手続き型 構造化 イベント駆動 オブジェクト指向 宣言的 オートマトンベース これは完全なリストではなく、これらの概念のすべてが同等ではなく、それらのほとんどが排他的でもないことがわかりますが、なぜそれらのほとんどが1つの単語だけを必要とするのか理解できません。機能的; 宣言的-しかし、オブジェクトを使ったプログラミングについて話すときは、それらのオブジェクトを中心に指向していることを明確にする必要があります。オブジェクトだけを使用することはできませんか？ただオブジェクトを持てないのですか？なぜ彼らは私たちをガイド星として方向づけなければならないのですか？ ここ（https://en.wikipedia.org/wiki/Object-oriented_programming）を見ると、独自の用語として「指向」という用語が使用されています。「オブジェクト」のみが説明されています。 また、イベントドリブンが使用されている実用的な理由を見ることができます。なぜなら、イベントプログラミングは既に会議を行っているときに行うことであり、オートマタプログラミングは、ロボット生産ラインをセットアップしているように聞こえるからです。そのため、そこに追加の明確な単語があると役立ちます。 オブジェクトプログラミングをフレーズとして、プログラミングでオブジェクトを使用するときの動作を説明するのに十分ではないのはなぜですか？ 私の口調から、明らかに「指向」という言葉はあまり好きではありません。弁護士が一種の口頭ダニとして「に関連して」というフレーズを使用した後、弁護士に耳を傾け、法廷記者としての時間を思い出させます。それは何の意味もありませんでした。彼らが次に何を言いたいかを考えている間に、彼らがかつて空気を満たしていた用語でした。しかし、私は言語の変更を提唱しようとはしていません。なぜそうなっているのかを尋ねているだけです。純粋に歴史的、痕跡的な理由でそのように知られるようになった理由を誰かが知っていれば、それが答えです。言語の変更を提唱することに時間を浪費することにした場合、それは弾薬になります。 一方、ツールやツールベルトに単にそれらを持たせるのではなく、他のすべての方向を除外して、言語やコードがオブジェクトを指す必要がある理由が実際にある場合、私は本当にそれについて学ぶことに興味があります。役に立つことを学ぶのが好きです。

14 object-oriented  terminology  history  grammar