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

Studentというカスタムオブジェクトがあるとします。 public class Student{ public int _id; public String name; public int age; public float score; } そして、生徒の情報を表示するために使用されるクラスWindow： public class Window{ public void showInfo(Student student); } 正常に見えますが、Windowを個別にテストするのは簡単ではありません。関数を呼び出すには、実際のStudentオブジェクトが必要だからです。そこで、Studentオブジェクトを直接受け入れないようにshowInfoを変更しようとしています。 public void showInfo(int _id, String name, int age, float score); ウィンドウを個別にテストする方が簡単です： showInfo(123, "abc", 45, 6.7); しかし、修正版には別の問題があることがわかりました。 生徒の変更（例：新しいプロパティの追加）には、showInfoのメソッド署名を変更する必要があります Studentに多くのプロパティがある場合、Studentのメソッド署名は非常に長くなります。 それでは、カスタムオブジェクトをパラメーターとして使用するか、オブジェクトの各プロパティをパラメーターとして受け入れますか？

49 design-patterns  object-oriented  parameters 

このブログ投稿は、いくつかの賛成票とともにHacker Newsに投稿されました。C ++から来るこれらの例のほとんどは、私が教えてきたものに反するようです。 例＃2など： 悪い： def check_for_overheating(system_monitor) if system_monitor.temperature > 100 system_monitor.sound_alarms end end 良い対： system_monitor.check_for_overheating class SystemMonitor def check_for_overheating if temperature > 100 sound_alarms end end end C ++でのアドバイスは、カプセル化を増やすため、メンバー関数ではなくフリー関数を好むことです。これらは両方とも意味的に同一なので、なぜより多くの状態にアクセスできる選択肢を好むのでしょうか？ 例4： 悪い： def street_name(user) if user.address user.address.street_name else 'No street name on file' end end 良い対： def street_name(user) user.address.street_name end …

49 c++  object-oriented  ruby 

私は、OOPの固い原則を理解しようとしていますが、LSPとOCPにはいくつかの類似点があるという結論に達しました（詳しくは言いませんが）。 オープン/クローズの原則には、「ソフトウェアエンティティ（クラス、モジュール、関数など）は拡張のために開かれているが、変更のために閉じられている必要があります」と記述されています。 簡単な言葉で言えば、LSPはのFooインスタンスをBar派生元のインスタンスに置き換えることができFoo、プログラムはまったく同じように機能することを示しています。 私はプロのOOPプログラマーではありませんが、LSPはBar、から派生しFooたものがその中の何も変更せず、拡張する場合にのみ可能であるように思われます。つまり、特定のプログラムのLSPはOCPが真の場合にのみ真であり、OCPはLSPが真の場合にのみ真です。それは、それらが等しいことを意味します。 私が間違っている場合は修正してください。これらのアイデアを本当に理解したいです。答えてくれてありがとう。

48 object-oriented  inheritance  solid  open-close  liskov-substitution 

この質問は主観的なものですが、ほとんどのプログラマーがこれにどのようにアプローチしているかに興味がありました。以下のサンプルは擬似C＃ですが、これはJava、C ++、およびその他のOOP言語にも当てはまります。 とにかく、クラスでヘルパーメソッドを記述するとき、静的メソッドとして宣言し、ヘルパーメソッドで必要な場合はフィールドを渡すだけです。たとえば、以下のコードを考えると、メソッド呼び出し＃2を使用することを好みます。 class Foo { Bar _bar; public void DoSomethingWithBar() { // Method Call #1. DoSomethingWithBarImpl(); // Method Call #2. DoSomethingWithBarImpl(_bar); } private void DoSomethingWithBarImpl() { _bar.DoSomething(); } private static void DoSomethingWithBarImpl(Bar bar) { bar.DoSomething(); } } これを行う私の理由は、ヘルパーメソッドが実装を読み取らなくても、他のオブジェクトに副作用がある可能性があることを（少なくとも私の目には）明らかにするからです。この手法を使用するメソッドをすばやく理解できるため、デバッグに役立ちます。 あなたはどちらか好む独自のコードでやってそうするためのあなたの理由は何ですか？

48 java  c#  design  object-oriented  programming-practices 

主にクラスベースの言語のコンテキストでOOPを扱った後にJavascriptのプログラミングを始めたとき、プロトタイプベースのOOPがクラスベースのOOPよりも優先される理由について混乱していました。 プロトタイプベースのOOPを使用する場合、構造的な利点はありますか？（たとえば、特定のアプリケーションでより高速であるか、メモリ集約度が低いと予想されますか？） コーダーの観点からの利点は何ですか？（たとえば、特定のアプリケーションをコーディングしたり、プロトタイピングを使用して他の人のコードを拡張したりするのは簡単ですか？） この質問を特にJavascriptに関する質問と見なさないでください（長年にわたってプロトタイプ作成とはまったく関係のない多くの欠点がありました）。代わりに、プロトタイピングとクラスの理論的な利点のコンテキストで見てください。 ありがとうございました。

47 design  object-oriented  language-agnostic 

私はSmalltalkの初期の歴史を読んでおり、その意味の理解に疑問を抱かせる「割り当て」についての言及がいくつかあります。 OOPは多くの動機から来ましたが、2つが中心でした。大規模なものは詳細の隠蔽を伴う複雑なシステムのためのより良いモジュールスキームを見つけることであり、小規模なものは割り当てのより柔軟なバージョンを見つけることであり、それからそれを完全に排除しようとしました。 （1960-66から-初期のOOPおよび60年代のその他の形成的アイデア、セクションI） Simulaから得たのは、バインディングと割り当てを目標に置き換えることができるということです。プログラマーに最後に望むことは、たとえ比fig的に提示されたとしても、内部状態を混乱させることです。代わりに、オブジェクトは、動的コンポーネントとしての使用により適した、より高いレベルの動作のサイトとして提示される必要があります。（...）残念なことに、今日「オブジェクト指向プログラミング」と呼ばれるものの多くが、より洗練された構成要素を備えた単純な古いスタイルのプログラミングである。多くのプログラムには、より高価な添付プロシージャによって実行される「割り当てスタイル」操作がロードされています。 （「オブジェクト指向」スタイル、セクションIVから） オブジェクトがファサードであり、オブジェクトにインスタンス変数を設定することを目的とするメソッド（または「メッセージ」）（つまり「割り当て」）が目的に反しているという意図を解釈するのは正しいですか？この解釈は、セクションIVの後半の2つのステートメントでサポートされているようです。 永続状態、ポリモーフィズム、インスタンス化、およびオブジェクトの目標としてのメソッドの4つの手法が一緒に使用され、多くの権限を占めています。これらのいずれも「オブジェクト指向言語」を採用する必要はありません--ALGOL 68はほとんどこのスタイルに変えることができます-そして、OOPLは単に特定の実りある方向にデザイナーの心を集中させます。ただし、カプセル化を正しく行うことは、状態の抽象化だけでなく、プログラミングから状態指向のメタファーを排除することを約束するものです。 ...そして： 割り当てステートメントは、抽象的なものであっても、非常に低いレベルの目標を表します。何かを成し遂げるためには、それらの多くが必要になります。一般に、シミュレートされているかどうかに関係なく、プログラマが状態をいじり回すことは望ましくありません。 ここでは、不透明で不変のインスタンスが推奨されていると言ってもいいでしょうか？または、推奨されていない単純な状態変更ですか？私が持っている場合たとえば、BankAccountクラスを、それが持ってOKだGetBalance、DepositとWithdrawインスタンスメソッド/メッセージ。SetBalanceインスタンスメソッド/メッセージがないことを確認してください？

47 object-oriented  immutability  smalltalk  functional-programming 

でブログの記事楽しさと利益のためにF＃上、それは言います： 機能設計では、動作をデータから分離することが非常に重要です。データ型は単純で「ダム」です。そして、別に、これらのデータ型に作用する多くの関数があります。 これは、動作とデータを組み合わせることを意図したオブジェクト指向設計の正反対です。結局のところ、それはまさにクラスです。実際にオブジェクト指向の設計では、振る舞い以外は何もありません。データはプライベートであり、メソッドを介してのみアクセスできます。 実際、OODでは、データ型の周囲に十分な動作がないことは悪いことと見なされ、「貧血領域モデル」という名前さえあります。 C＃では、F＃から借用し続け、より機能的なスタイルのコードを記述しようとしているようです。なぜデータ/動作を分離するという考えを借りず、それを悪いと考えるのでしょうか？定義がOOPを伴わないというだけなのでしょうか、それともC＃で悪いのに何らかの理由でF＃に適用されない（そして実際には逆になる）具体的な理由がありますか？ （注：私は、ブログ投稿のどちらかの意見に同意しない個人ではなく、善/悪の意見を変える可能性のあるC＃/ F＃の違いに特に興味があります）。

46 c#  object-oriented  functional-programming  paradigms  f# 

PHPのコンストラクターから例外をスローできることは知っていますが、それを行う必要がありますか？たとえば、パラメータの値が期待どおりではない場合。 または、メソッドが呼び出されるまで例外のスローを延期する必要があります。両方の場合の長所と短所は何ですか？

46 php  object-oriented  exceptions  exception-handling 

さて、タイトルは少しクリックされていますが、真剣に私は言いました、しばらくキックを求めないでください。私は、メソッドが真のオブジェクト指向の方法でメッセージとして使用されることを奨励する方法が好きです。しかし、これには頭の中のガタガタする問題があります。 よく書かれたコードは、オブジェクト指向の原則と機能の原則を同時に満たすことができると疑うようになりました。私はこれらの考えを調和させようとしています、そして、私が着陸した大きなこだわりポイントはreturnです。 純関数には次の2つの性質があります。 同じ入力で繰り返し呼び出すと、常に同じ結果が得られます。これは、不変であることを意味します。その状態は一度だけ設定されます。 副作用はありません。呼び出しによって引き起こされる唯一の変更は、結果の生成です。 それでは、return結果を伝える方法として使用することを誓った場合、どうすれば純粋に機能的になりますか？ TELLは、聞いていない、いくつかの副作用を検討するものを使用してアイデアの作品を。オブジェクトを扱うとき、その内部状態については尋ねません。何をする必要があるかを伝え、その内部状態を使用して、私がそれを行うように指示したことで何をすべきかを見つけます。一度言ったら、何をしたのかは聞かない。私は、それがするように言われたことについて何かをしたと思っています。 Tell、Den's Askは単にカプセル化の別の名前以上のものだと思います。私が使うとき、私はreturn何が私を呼んだのかわかりません。私はそれのプロトコルを話すことができません、私はそれが私のプロトコルに対処することを強制する必要があります。多くの場合、これは内部状態として表されます。公開されているものが正確な状態ではない場合でも、通常は状態と入力引数に対して実行される計算にすぎません。応答するインターフェースがあると、結果を内部状態や計算よりも意味のあるものにマッサージする機会が与えられます。それはメッセージパッシングです。この例を参照してください。 昔、ディスクドライブには実際にディスクが搭載されていて、指で触れるにはホイールが冷たすぎるときに親指ドライブが車で行っていたものでした。void swap(int *first, int *second)とても便利に見えましたが、結果を返す関数を書くことが奨励されました。それで私はこれを信仰で心に留め、それを追い始めました。 しかし、今では、オブジェクトを構築する方法によって結果の送信先を制御できるアーキテクチャを構築する人々がいます。以下に実装例を示します。出力ポートオブジェクトを注入することは、出力パラメーターの考え方に似ています。しかし、それが、tell-don't-askオブジェクトが他のオブジェクトに何をしたかを伝える方法です。 副作用について最初に学んだとき、それを出力パラメーターのように考えました。私たちは、仕事のいくつかを驚くべき方法で、つまりreturn result慣習に従わないことによって人々を驚かせないように言われていました。確かに、副作用が発生する並列非同期スレッドの問題が山積みになっていることはわかっていますが、戻り値は実際には単に結果をスタックにプッシュしたままにしておくため、呼び出されたものは後でポップオフできます。それだけです。 私が本当に求めていること： あるreturnすべてのその副作用の悲惨さを回避し、ロックせずに、スレッドの安全性を取得する唯一の方法は、など、または私は従うことができます聞いていない、言う純粋に機能的な方法で？

45 object-oriented  architecture  functional-programming  side-effect 

私は、ゲッターとセッターのメソッドとカプセル化に関する興味深いインターネットの議論に入りました。誰かがすべきことは、それらを「純粋」に保ち、カプセル化を確保するための割り当て（セッター）または変数アクセス（ゲッター）だけだと言いました。 これは、最初にゲッターとセッターを持つという目的を完全に無効にし、検証と他のロジック（もちろん、奇妙な副作用なし）を許可する必要があると思いますか？ 検証はいつ行われますか？ セッター内で値を設定するとき（オブジェクトが無効な状態になるのを防ぐため-私の意見） 値を設定する前、セッターの外側 オブジェクト内で、値が使用されるたびに セッターは値の変更を許可されていますか（有効な値を標準的な内部表現に変換する可能性があります）？

45 object-oriented  language-agnostic  encapsulation 

OOP言語を使用してデータ構造（キューなど）を実装する場合、データ構造の一部のメンバーはプライベートにする必要があります（キュー内のアイテム数など）。 キューは、structおよびで動作する一連の関数を使用して手続き型言語で実装することもできますstruct。ただし、手続き型言語では、メンバーをstructプライベートにすることはできません。手続き型言語で実装されたデータ構造のメンバーは公開されていましたか、それとも非公開にするためのトリックがありましたか？

44 object-oriented  data-structures  history 

Liskov Substitution Principleについてのこの質問に対する最も高い評価の答えは、サブタイプとサブクラスという用語を区別するのに苦労します。また、一部の言語はこの2つを統合しますが、他の言語は統合しないという点も重要です。 私が最もよく知っているオブジェクト指向言語（Python、C ++）の場合、「タイプ」と「クラス」は同義の概念です。C ++に関して、サブタイプとサブクラスを区別することはどういう意味ですか？たとえば、Fooサブクラスではなく、サブタイプであるとしFooBaseます。のfooインスタンスがの場合Foo、次の行になります： FooBase* fbPoint = &foo; 無効になりましたか？

44 object-oriented  c++  theory  liskov-substitution 

実行を停止してはならないいくつかのエラーを処理するためにerror、クライアントがチェックして例外をスローするために使用できる変数があります。これは反パターンですか？これを処理するより良い方法はありますか？この動作の例については、PHPのmysqli APIをご覧ください。可視性の問題（アクセサ、パブリックスコープとプライベートスコープ、クラス内の変数はグローバルですか？）が正しく処理されると仮定します。

44 design-patterns  object-oriented  exceptions  patterns-and-practices  anti-patterns 

任意のあるオブジェクト指向のプログラミング言語クラスのパラダイムに基づいていませんか？

44 programming-languages  object-oriented 

これはばかげた質問かもしれないし、そうでないかもしれないが、私はしばらくの間私を悩ませてきた何かに対する答えを本当に知りたい。 私は、プログラマーがacmeものを入れるために呼ばれるディレクトリを作成したプログラミングの例/慣例をよく見ます。 どういうAcme意味ですか？EmcaなどではなくAcmeを使用する理由 Acmeは、雑多なOOPクラスをグループ化する一般的なフォルダー名のようなものですか？ この用語は、プログラミング規則の観点からどこから来たのですか。私が見る限り、それはプログラマーUIとは何の関係もありませんhttp://plan9.bell-labs.com/sys/doc/acme.html

43 object-oriented  programming-practices