タグ付けされた質問 「abstraction」

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 機械言語（例：）は、0110101000110101一般にコンピューター言語がより高度な抽象化に進化してきたため、一般的に問題に適用されたときにコードを理解しやすくします。アセンブラーはマシンコードの抽象化であり、Cはアセンブラーの抽象化などでした。 オブジェクト指向設計は、オブジェクトの観点から問題をモデル化するのに非常に優れているようです。たとえば、大学の履修登録システムの問題は、Courseクラス、Studentクラスなどでモデル化できます。 OO言語では、責任を負う同様のクラスがあり、一般に設計、特にコードのモジュール化に役立ちます。この問題をOOメソッドで解決する10の独立したチームに与えた場合、通常、10のソリューションには共通して問題に関連するクラスがあります。これらのクラスの結合と相互作用を開始し始めると、多くの違いが生じる可能性があるため、「表現のギャップがゼロ」というものはありません。 関数型プログラミングの私の経験は非常に限られています（実際の使用はなく、Hello Worldタイプのプログラムのみ）。このような言語がOO言語のようにFPソリューションを問題に（低い表現のギャップで）簡単にマッピングできるようにする方法を私は見ていません。 並行プログラミングに関するFPの利点を理解しています。しかし、私は何かを逃していますか、またはFPは表現のギャップを減らすことではありませんか？ これを尋ねる別の方法：同じ現実の問題を解決する10の異なるチームのFPコードには多くの共通点がありますか？ 抽象化に関するウィキペディア（コンピューターサイエンス）から（強調鉱山）： 関数型プログラミング言語は一般に、ラムダ抽象化（用語を変数の関数にする）、高次関数（パラメーターは関数）、ブラケット抽象化（用語を変数の関数にする）など、関数に関連する抽象化を示します。 [一部の]実際の問題はこのような抽象化では簡単にモデル化されないため、表現のギャップは潜在的に拡大する可能性があります。 表現のギャップを減らすもう1つの方法は、ソリューション要素を問題にまでさかのぼることです。0さんと1マシンコードでSは一方で、バックトレースすることは非常に困難であるStudentクラスは、トレースバックに簡単です。すべてのOOクラスが問題空間に簡単にトレースできるわけではありませんが、多くのクラスがトレースしています。 FPの抽象化は、常に彼らが（離れてから解決されている問題空間のどの部分を見つけるために説明する必要はありません数学の問題）？OK-私はこの部分でいいです。さらに多くの例を見ると、FPの抽象化がデータ処理で表現される問題の一部に対して非常に明確であることがわかります。 関連する質問に対する受け入れられた回答UMLは、機能プログラムのモデル化に使用できますか？-「機能プログラマーは、ダイアグラムをあまり使いません」と言います。それがUMLであるかどうかは本当に気にしませんが、広く使用されているダイアグラムがない場合、FPの抽象化が簡単に理解/通信できるかどうか疑問に思います（この答えが正しいと仮定して）。繰り返しになりますが、FPの使用/理解のレベルはささいなものなので、単純なFPプログラムのダイアグラムの必要はないと理解しています。 OOデザインには、機能/クラス/パッケージレベルの抽象化があり、それぞれにカプセル化（アクセス制御、情報隠蔽）があり、複雑さの管理を容易にします。これらは、問題から解決策へと簡単に戻ることができる要素です。 多くの答えは、オブジェクト指向に類似した方法でFPで分析と設計が行われる方法について述べていますが、これまで高レベルのものを引用する人はいません（paulはいくつかの興味深いものを引用しましたが、低レベルです）。昨日はグーグルで多くのことをして、興味深い議論を見つけました。以下は、サイモン・トンプソンによるリファクタリング機能プログラムからのものです（2004）（強調の鉱山） オブジェクト指向システムの設計では、プログラミングよりも設計が優先されることは当然のことです。デザインは、EclipseなどのツールでサポートされているUMLのようなシステムを使用して作成されます。初心者のプログラマーは、BlueJのようなシステムを使用して視覚的な設計アプローチを学ぶことができます。関数型プログラミングのための同様の方法論に関する作業がFAD：Functional Analysis and Designで報告されていますが、他の作業はほとんどありません。これにはいくつかの理由があります。 既存の機能プログラムは、設計を必要としない規模です。多くの機能プログラムは小さいですが、Glasgow Haskell Compilerなどの他のプログラムはかなりのものです。 機能プログラムはアプリケーションドメインを直接モデル化するため、デザインは無関係になります。関数型言語はさまざまな強力な抽象化を提供しますが、これらが現実世界をモデル化するために必要なすべての抽象化のみを提供すると主張することは困難です。 機能プログラムは、進化する一連のプロトタイプとして構築されます。 上記で引用された博士論文では、分析と設計の方法論（ADM）を使用する利点が、パラダイムとは無関係に概説されています。しかし、ADMは実装パラダイムと整合する必要があるという主張がなされています。つまり、OOADMはOOプログラミングに最適であり、FPなどの別のパラダイムにはあまり適用されません。これは、私が表現ギャップと呼ぶものを言い換えていると思う素晴らしい引用です： どのパラダイムがソフトウェア開発に最適なサポートを提供するかについては長々と議論できますが、問題の説明から実装および配信まで単一のパラダイム内にとどまると、最も自然で効率的かつ効果的な開発パッケージを実現できます。 FADが提案する一連の図を次に示します。 実装で使用する関数を関数に提示する関数依存図。 型に同じサービスを提供する型依存図。そして、 システムのモジュールアーキテクチャのビューを表示するモジュール依存関係図。 FAD論文のセクション5.1にはケーススタディがあります。これは、フットボール（サッカー）リーグに関連するデータの生成を自動化するシステムです。要件は100％機能的です。たとえば、サッカーの結果の入力、リーグテーブルの作成、得点表、出欠表、チーム間での選手の移動、新しい結果の後のデータの更新などです。 、「新しい機能は最小限のコストで許可する必要がある」と述べることは別として、テストすることはほぼ不可能です。 悲しいことに、FADを除いて、FP用に提案されているモデリング言語（視覚）の最新の参照はありません。UMLは別のパラダイムなので、それを忘れてください。

18 object-oriented  object-oriented-design  functional-programming  abstraction 

グレッグヤングの講演7:20でDDD-Liteと呼ばれるものに言及したDDDプロジェクトが失敗する7つの理由に出会った。 要約すると、彼は基本的に、DDDに関連することを何もせずにパターン言語（エンティティ、リポジトリ、値オブジェクト、サービスなど）としてDDDを使用する人もいると言います。彼は、.Netのドメインモデルの60％以上がDDD-Liteであると仮定しています。彼は、DDD-Liteが基本的に依存性注入に関する言語を構築していると考えています。彼は、DDDを完全に実行するか、もっと簡単なことを行うと言います。そうでなければ、彼は、人が良い抽象化を構築するためにこの仕事のすべてを出しているが、本当の利益なしであると主張します。 私はDDDについてあまり知りたいとは思わないので、まだ使用しようとしていません。また、エリック・エヴァンの本も読んでいません。私はずっとエリック・エヴァンスDDD帳から、この主題の使用条件と参照概念に依存性の注入と、多くの、多くの書籍やブログに興味を持って。ここで、DDDの概念に触れました。私がこれを読んでいる本には以下が含まれます： .NETでの依存性注入 Microsoft .Net：企業向けアプリケーションの設計 .NETでのブラウンフィールドアプリケーション開発 依存性注入を実行したい場合、「DDD-Lite」を実行するより簡単な代替手段は何ですか？良い抽象化を構築することは、DDDの概念を「DDD-Lite」の方法で使用しているかどうかに関係なく、非常に役立つように思えます。（Mark Seemannのブログ投稿を参照してください。インターフェースは抽象化ではありません。より良い抽象化に向けて）。依存性注入を行っているすべての人が、本格的なDDDを実行している（または実行する必要がある）ことを信じるのは困難です。グレッグヤングのDDD-Liteについての議論を何らかの形で誤解しましたか？

17 .net  dependency-injection  domain-driven-design  abstraction 

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

16 object-oriented  abstraction 

今日、私は組織の別の開発者とデータベースマップクラスにメソッドを追加する場所と方法について、激しい議論になりました。を使用しsqlalchemy、データベースモデルの既存のコードベースの大部分は、クラス名を持つマッピングされたプロパティのバッグ、データベーステーブルからpythonオブジェクトへのほぼ機械的な変換に過ぎません。 議論の中で、私の立場は、ORMを使用する主な価値は、マップされたクラスに低レベルの動作とアルゴリズムを付加できることだということでした。モデルは最初にクラスであり、2番目に永続的です（ファイルシステムでxmlを使用して永続的である可能性があるため、気にする必要はありません）。彼の見解では、すべての動作は「ビジネスロジック」であり、必然的に、データベースの永続化のみに使用される永続モデル以外のどこかに属します。 私は確かにビジネスロジックとは区別されていると思いますが、それは実装方法の下位レベルからある程度分離されているので、分離する必要があります前の段落で議論しましたが、私はそれが何であるかについて指を置くのに苦労しています。私は、彼らがしたいとのAPI呼び出しているユーザーには、（我々の場合には、HTTP「安らか」である、）APIが何であるかのより良い感覚を持っていません、彼らが行うことを許可されているものとは異なった、そしてどのように完了します。 tl; dr：ORMを使用する場合、マップされたクラスのメソッドにはどのような種類の要素を含めることができますか？

16 orm  abstraction  business-logic 

新しいコードベースを見るとき、ボトムアップのアプローチから始めたいと思います。 1つのファイルを理解してから、次の抽象化に移動します。 しかし、多くの場合、低レベルの抽象化が行っていることを忘れています。 だから、私はこの時点で、私が以前完全に理解していたファイルに戻って、それらを再学習しようとするほぼ無限のループにいることに気付くでしょう。私の頭の中で互いに接続する他の多くの抽象化をジャグリングしようとしながら。 この状況に対処するためのより良い戦略はありますか？ 下位レベルの詳細を忘れて、それを当然のことと考えるべきですか？しかし、それでも、現在の抽象化が何をしているのかを理解するには、以前に低レベルの抽象化を理解しておく必要が何度もあります。

15 programming-practices  abstraction  strategy  low-level  high-level 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または詳細な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 プログラミング言語は最初は連続して実行されるコード行のみを使用し、抽象化の最初のレベルの1つである関数を含めるように進化したため、さらに抽象化するクラスとオブジェクトが作成されました。次の抽象化レベルは何ですか？ クラスよりもさらに抽象的なものはありますか？

15 programming-languages  object-oriented  language-agnostic  abstraction 

ウィキペディアの記事「高レベルプログラミング言語」の引用： 高レベルのプログラミング言語は、コンピューターの詳細から強力に抽象化されたプログラミング言語です。低レベルのプログラミング言語と比較して、自然言語要素を使用したり、使いやすくしたり、プラットフォーム間で移植性を高めたりできます。このような言語は、メモリアクセスモデルやスコープの管理などのCPU操作の詳細を隠します。 つまり、プログラミング言語のレベルが上がると、プログラマーがプログラムを実行するハードウェアから離れるほどです。 今、私はレベル全体の言語使用の統計を知りませんが、より高いレベルの言語がより低いレベルの言語に取って代わりつつあると思うでしょう。もしそうなら、これはコンピューターアーキテクチャーの知識を持つプログラマーの不足につながることがありますか？これは業界にとって問題になりますか？

15 programming-languages  hardware  abstraction  industry  computer-architecture 

「ラッパー」と「シム」という言葉は多かれ少なかれ同義語ですか、それともおそらく意味合いのある区別がありますか？

15 abstraction  terminology 

まず、私は初心者レベルのプログラマーです。実際、私は夏の最後の絶頂プロジェクトでASの学位を取得しています。私の新しい仕事では、私がやるべきプロジェクトがないとき（彼らはチームにさらに新しい採用をするのを待っています）、私は待っている間に読んで学ぶための本を与えられました-いくつかの教科書、他のそれほど多くはありません（コード完了など）。これらの本を読んだ後、できる限り多くのことを学ぶためにインターネットに目を向け、SOLIDとDIについて学び始めました（Liskovの代替原理についてはいくらか話しましたが、SOLIDのアイデアについてはあまり話しませんでした）。それで、私が学んだように、私はよりよく学ぶために座って、DIを手動で利用するためのコードを書き始めました（開発コンピューターにはDIフレームワークはありません）。 私がやっているように、それは馴染みのあることに気づきます...そして、ポリモーフィズムを使った抽象クラスの構成を使って過去にやった仕事に非常に似ているようです。ここに大きな画像がありませんか？DIについて（少なくとも手で）それを超える何かがありますか？再コンパイルすることなく物事を変更する限り、いくつかの大きな利点を持つDIフレームワークのコードに設定がない可能性を理解していますが、手動で行う場合、上記と異なるかどうかはわかりません...これに関するいくつかの洞察は非常に役立つでしょう！

13 dependency-injection  abstraction  polymorphism  composition 

特定の種類の例外をスローすることをドキュメントに記載するインターフェイスメソッドがあります。そのメソッドの実装は、例外をスローするものを使用します。内部例外がキャッチされ、インターフェイスコントラクトによって宣言された例外がスローされます。ここに、よりよく説明するための小さなコード例を示します。これはPHPで書かれていますが、簡単に理解できます。 // in the interface /** * @return This method returns a doohickey to use when you need to foo * @throws DoohickeyDisasterException */ public function getThatDoohickey(); // in the implementation public function getThatDoohickey() { try { $SomethingInTheClass->doSomethingThatThrowsAnException(); } catch (Exception $Exc) { throw new DoohickeyDisasterException('Message about doohickey failure'); } …

12 exceptions  abstraction 

これはかなり曖昧な質問ですが、適切な設計について読んだときに満足のいく方法で答えられたとは思っていませんでした。 一般に、オブジェクト指向プログラミング、抽象化、因数分解などについて学ぶとき、設計の聖杯-そして、あなたが問題の開発技術を使用していると常に主張する理由-は、プログラムを「変更しやすくする」ことです、「維持可能」、「柔軟」、またはそのような生産的な響きの概念を表現するために使用される同義語のいずれか。ivarをプライベートとしてマークし、コードを多くの小さな自己完結型のメソッドに分割し、インターフェイスを一般的な状態に保つことで、プログラムを完全に簡単かつ優雅に変更できるようになります。 比較的小さな変更の場合、これは私にとってはうまくいきました。クラスがパフォーマンスを向上させるために使用する内部データ構造の変更は大きな困難ではありませんでした。また、テキスト入力システムの再設計やゲームプレイ要素のグラフィックのオーバーホールなど、APIに依存しないユーザーインターフェイスエンドの変更もありません。 これらの変更はすべて、本質的に自己完結型のようです。それらのいずれも、外部コードに関する限り、変更されるプログラムのコンポーネントの動作または設計への変更を伴いません。手続き型であろうと大規模な機能であろうと小規模であろうとOOスタイルであろうと、これらはあなたが適度に良いデザインしか持っていなくても簡単に変更できます。 しかし、変更が大きくて毛深いものになったとき、つまりAPIに変更が加えられたときはいつでも、私の貴重な「パターン」はどれも助けになりません。大きな変化は大きなままで、影響を受けるコードは影響を受けたままで、何時間もバグを生み出す作業が私の前にあります。 だから、私の質問はこれです。適切な設計がどの程度大きな変更を促進できると主張していますか？私には未知の、または実装に失敗した、さらにスティッキーなサウンドの修正を本当に単純にする、またはその約束（非常に多くの異なるパラダイムによって行われたと聞いた）は単に素晴らしいアイデアである、いくつかのさらなる設計技術がありますか？ソフトウェア開発の不変の真実から完全に切り離されていますか？ツールベルトに追加できる「変更ツール」はありますか？ 具体的には、私がフォーラムに導かれた問題はこれです：私は解釈されたプログラミング言語（Dで実装されていますが、それは関係ありません）の実装に取り​​組んでおり、クロージャの引数は現在の位置ではなく、キーワードベース。これには、匿名関数を呼び出す既存のすべてのコードを変更する必要がありますが、幸いなことに、私は言語の開発の初期段階（2000行未満）であるため、かなり小さいですが、後の段階でこの決定を行った場合は非常に大きくなります。そのような状況では、設計の適切な先見によって、この変更を簡単にすることができたのでしょうか、それとも特定の（ほとんどの）変更が本質的に広範囲に及ぶのでしょうか？これが何らかの形で自分自身の設計スキルの失敗であるかどうかに興味があります-もしそうなら、私は 明確にするために、私はOOPや一般的に使用されている他のパターンのいずれにも決して懐疑的ではありません。ただし、私にとっては、それらの長所は、コードベースの保守ではなく、元の記述にあります。継承を使用すると、繰り返しパターンを適切に抽象化できます。ポリモーフィズムを使用すると、機械が理解する効果（switchステートメントのブランチ）ではなく、人間が理解する機能（クラス）でコードを分離できます。非常に快適な「ボトムアップ」スタイルで記述します。しかし、私は彼らの柔軟性の主張に懐疑的です。

11 design  object-oriented  maintenance  abstraction  changes 

私はフレーズが乱れているのを聞いたし、私には議論が完全に正気ではないように聞こえます（ここでわざわざ言っているとすみません、それは私の意図ではありません）。 一般的なケースがわかる前に抽象化を作成したくない場合は、（1）属していないものを抽象化に入れるか、（2）重要なものを省略します。 （1）私にはこれはプログラマーが十分に実用的ではないように聞こえます、彼らは最終的なプログラムには存在しないものがあると仮定しているので、抽象化のレベルが低い状態で作業していますが、問題はありません時期尚早な抽象化、それは時期尚早な結着です。 （2）重要なことの省略は1つです。後で重要になることが仕様から省略されている可能性があります。これに対する解決策は、独自の結論を導き出してリソースを無駄にすることではありません。間違っていると思います、それはクライアントからより多くの情報を取得することです。 これは、抽象化から具体化に至るまで常に作業する必要があります。これは、最も実用的な方法であり、その逆ではないためです。 そうしないと、クライアントを誤解し、変更が必要なものを作成するリスクがありますが、クライアントが独自の言語で定義した抽象化のみを構築する場合は、このリスクにぶつかることはありません（少なくとも、いくつかの具体的な暗闇の中でのショット）、はい、クライアントは詳細について考えを変える可能性がありますが、本来彼らが望むものを伝えるために使用していた抽象化は依然として有効である傾向があります。 以下に例を示します。クライアントがアイテムバギングロボットの作成を希望しているとします。 public abstract class BaggingRobot() { private Collection<Item> items; public abstract void bag(Item item); } 私たちは、クライアントが使用した抽象化から何かを構築していますが、わからないことについては詳しく説明していません。これは非常に柔軟性があり、「時期尚早な抽象化」と呼ばれるのを見てきましたが、実際にはバギングがどのように実装されたかを想定するのは時期尚早です。複数のアイテムを一度にバギングすることをクライアントと話し合った後、 。クラスを更新するために必要なのはシグネチャを変更することだけですが、ボトムアップを始めた人にとっては、大規模なシステムのオーバーホールが必要になる可能性があります。 時期尚早な抽象化などはなく、時期尚早な結集だけです。このステートメントの何が問題になっていますか？私の推論のどこに欠陥がありますか？ありがとう。

10 design  design-patterns  object-oriented-design  development-process  abstraction 

PHPでページ生成を作成するとき、データベースクエリが散らかっている一連のファイルを作成していることがよくあります。たとえば、次のように、投稿に関するデータをデータベースから直接フェッチしてページに表示するクエリがあるとします。 $statement = $db->prepare('SELECT * FROM posts WHERE id=:id'); $statement->bindValue(':id', $id, PDO::PARAM_INT); $statement->execute(); $post = $statement->fetch(PDO::FETCH_ASSOC); $content = $post['content'] // do something with the content これらの迅速な1回限りのクエリは通常は小さいですが、データベースのやり取りコードの大部分が結局乱雑に見えることがあります。 場合によっては、ポスト関連のdbクエリを処理する単純な関数ライブラリを作成し、コードのブロックを単純なものに短縮することで、この問題を解決しました。 $content = post_get_content($id); そして、それは素晴らしいことです。または、少なくとも何か他のことをする必要があるまでです。たぶん、最新の5つの投稿をリストに表示する必要があります。ええと、いつでも別の関数を追加できます。 $recent_posts = post_get_recent(5); foreach ($recent_posts as $post) { ... } しかしSELECT *、それは結局クエリを使用することになります。これは通常、とにかく必要はありませんが、しばしば複雑すぎて合理的に抽象化できません。最終的に私は、すべての単一のユースケースのデータベース相互作用関数の大規模なライブラリ、またはすべてのページのコード内の一連の乱雑なクエリのいずれかになります。そして、これらのライブラリを構築した後でも、以前に使用したことがない小さな結合を1つ実行する必要があることに気づき、その仕事を行うために、突然別の高度に専門化された関数を作成する必要があります。 確かに、一般的なユースケースや特定のやり取りのクエリに関数を使用することはできますが、生のクエリを書き始めるとすぐに、すべてに直接アクセスできるようになります。それとも、怠惰になって、MySQLクエリで直接実行する必要があるPHPループで処理を開始します。 インターネットアプリケーションの記述に詳しい方にお願いしたいと思います。コードの追加の行と、抽象化によって導入される可能性のある非効率性に見合う保守性の向上はありますか。それとも、直接クエリ文字列を使用するだけで、データベースの相互作用を処理するための許容できる方法ですか？

10 php  database  sql  abstraction 

コードベースの抽象化が多すぎる（または少なくともそれを処理している）と感じている問題に直面しています。コードベースのほとんどのメソッドは、コードベースの最上位の親Aを取り込むように抽象化されていますが、この親の子Bには、これらのメソッドの一部のロジックに影響を与える新しい属性があります。問題は、入力がAに抽象化されているため、これらのメソッドでこれらの属性をチェックできないことです。もちろん、Aにはこの属性がありません。Bを異なる方法で処理する新しいメソッドを作成しようとすると、コードの重複のために呼び出されます。私の技術リーダーによる提案は、ブール型パラメーターを受け取る共有メソッドを作成することですが、これの問題は、これを「隠された制御フロー」と見なす人がいることです。 、また、この共有メソッドは、小さな属性に分割されたとしても、将来の属性を追加する必要がある場合、一度複雑になりすぎたり複雑になったりします。これはまた、カップリングを増やし、結束を減らし、チームの誰かが指摘した単一責任の原則に違反します。 基本的に、このコードベースの抽象化の多くはコードの重複を減らすのに役立ちますが、メソッドの拡張/変更が最高の抽象化を行うようになっている場合は難しくなります。このような状況ではどうすればよいですか？私は非難の中心にいますが、他の誰もが彼らが良いと思うことに同意することはできませんが、それは結局私を傷つけています。

9 object-oriented-design  class-design  abstraction  code-reuse  dry 

少し前に、メソッドパラメータの型、戻り値の型、およびプロパティの型の具体性についての「経験則」を読みましたが、覚えていません。 それはあなたの戻り値の型をできるだけ具体的にそしてあなたのパラメータ型をできるだけ抽象的に保つことについて何かを言った...またはその逆 実際に良いアドバイスなのか悪いアドバイスなのかはわかりませんので、ご自身の考えがあればコメントしてください。 乾杯。

9 object-oriented  programming-practices  interfaces  abstraction