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

SquareがRectangleのタイプである場合、なぜSquareはRectangleを継承できないのですか？それとも、なぜそれが悪いデザインですか？ 私は人々が言うのを聞いたことがあります： SquareをRectangleから派生させた場合、Squareは予想される任意の場所で使用できるはずです。 ここで問題は何ですか？そして、なぜSquareはあなたが長方形を期待するどこでも使えるのでしょうか？Squareオブジェクトを作成し、SquareのSetWidthメソッドとSetHeightメソッドをオーバーライドする場合にのみ使用できるのは、なぜ問題があるのでしょうか？ Rectangle基本クラスにSetWidthメソッドとSetHeightメソッドがあり、Rectangle参照がSquareを指している場合、SetWidthとSetHeightは、一方を設定するともう一方がそれに合わせて変更されるため、意味がありません。この場合、SquareはRectangleによるLiskov Substitution Testに失敗し、RectangleからSquareを継承させるという抽象化は悪いものです。 誰かが上記の議論を説明できますか？繰り返しますが、SquareでSetWidthおよびSetHeightメソッドをオーバーライドすると、この問題は解決しませんか？ 私も聞いた/読んだ： 実際の問題は、長方形をモデリングするのではなく、「再整形可能な長方形」、つまり作成後に幅または高さを変更できる長方形をモデリングすることです（それでも同じオブジェクトと見なします）。このように長方形クラスを見ると、正方形は「再成形可能な長方形」ではないことが明らかです。なぜなら、正方形は形を変えられず、依然として正方形であるためです（一般的に）。数学的には、数学的文脈では可変性は意味をなさないため、問題は見られません。 ここでは、「サイズ変更可能」が正しい用語だと思います。長方形は「サイズ変更可能」であり、正方形も同様です。上記の議論に何か欠けていますか？正方形は、任意の長方形と同様にサイズ変更できます。

105 object-oriented-design  inheritance  abstraction  solid 

最近、さまざまな抽象化技術に関連する多くの質問に気づきました。そして、基本的に問題の技術は「あまりにも賢い」と言っている答えがありました。プログラマーとしての私たちの仕事の一部は、解決するために与えられた問題に対する最良の解決策を決定することであり、そのためには賢明さが役立つと思います。 ですから、私の質問は、特定の抽象化手法が賢明さ自体にあまりにも賢明であると考える人たちですか、それとも異議の理由は他にあるのでしょうか？ 編集：このパーサーコンビネータは、私が賢いコードだと思うものの例です。これをダウンロードして、約30分間見ました。それから、私は紙の上でマクロ展開を進め、光を見ました。理解できたので、Haskellパーサーコンビネーターよりもはるかにエレガントに見えます。

89 abstraction 

私は独立した請負業者なので、新しいギグのために年に3〜4回インタビューしています。私は今、そのサイクルの真っin中にあり、インタビューがうまくいったように感じたにもかかわらず、機会を求めて断られました。今年も同じことが何度か起こりました。 今、私は完璧な人ではなく、すべての組織に適しているとは思っていません。とはいえ、バッティング平均は通常よりも低いので、最後の面接者に建設的なフィードバックを丁寧に尋ねると、彼は配達しました！ インタビュアーによると、主なことは、低レベルの有機的に成長したアルゴリズムではなく、抽象化（LINQなど）の使用に過度に傾いているように見えたということです。 表面的には、これは理にかなっています-実際、これらのインタビューでもLINQについて口説き、インタビュアーが.NETであってもLINQについてあまり知らなかったため、他の拒否も理にかなっていますみんな）。 だから今、この質問が残っています：「巨人の肩の上に立つ」ことになっていて、私たちが利用できる抽象化（LINQのような）を使用することになっているなら、なぜそれをタブーと考える人がいるのでしょうか？追加のコストなしで同じ目標を達成する場合、「既製」のコードをプルすることは意味がありませんか？ LINQは、それがあってもことを私には思われるで抽象化、単純にすべての抽象化で同じ 1は、まったく同じ目的を達成するために書くでしょうアルゴリズム。カスタムアプローチの方が優れているかどうかを確認できるのはパフォーマンステストだけですが、LINQのようなものが要件を満たしていた場合、そもそも独自のクラスを作成する必要はありません。 ここでLINQに注目するつもりはありません。私は、JAVAの世界には匹敵するものがあると確信しています。なぜ、一部の人々が抽象化を使用するという考えに非常に不快になり、彼ら自身が書いていないのかを知りたいのです。 更新 Euphoricが指摘したように、Javaの世界にはLINQに匹敵するものはありません。 したがって、.NETスタックで開発している場合、常にそれを使用してみてはどうでしょうか。人々がそれが何をするのかを完全に理解していない可能性はありますか？

60 algorithms  .net  abstraction  linq 

プログラマーとして、私たちの目標は、与えられたドメインモデルとビジネスロジックを適切に抽象化することだと思います。しかし、この抽象化はどこで止めるべきですか？抽象化とそのすべての利点（柔軟性、変更の容易さなど）と、コードとそのすべての利点の理解の容易さとの間でトレードオフを行う方法。 私は過度に抽象化されたコードを書く傾向があり、それがどれほど良いのかわかりません。私はよく、2つの部分で構成されるマイクロフレームワークのようなものを書く傾向があります。 マイクロフレームワークに接続されたマイクロモジュール：これらのモジュールは、単一ユニットとして理解、開発、および保守が容易です。このコードは基本的に、要件で説明されている機能的な機能を実際に実行するコードを表しています。 接続コード; 今ここに私は問題があると信じています。このコードは、時には非常に抽象化されていて、最初は理解しにくいため、複雑になる傾向があります。これは、純粋な抽象化、現実のベース、および提示されたコードで実行されるビジネスロジックにすぎないという事実により発生します1。この理由から、このコードはテスト後に変更されることはありません。 これはプログラミングの良いアプローチですか？多くのモジュールで非常に断片化されたコードの変更が非常に理解しやすく、抽象化POVからの変更のないコードは非常に複雑であるということですか？すべてのコードが均一に複雑である（つまり、コード1がより複雑で相互にリンクされ、コード2がより単純である）ため、コードを見ている人は合理的な時間内にそれを理解できますが、変更は高価であるか、上記のソリューションは優れています「コードの変更」は理解、デバッグ、変更が非常に簡単であり、「コードのリンク」は一種の困難です。 注：これはコードの可読性に関するものではありません！1と2のコードはどちらも読み取り可能ですが、2のコードにはより複雑な抽象化があり、コード1には単純な抽象化があります。

46 programming-practices  complexity  abstraction 

プログラマーが使用するような、プログラミングの抽象化とは何かについて一般的に合意された定義はありますか？[注意、プログラミングの抽象化は、「抽象化」という単語の辞書定義と混同しないでください。]明確な、または数学的な定義さえありますか？抽象化の明確な例は何ですか？

38 terminology  abstraction 

今日「Clean code」という本を読んでいて、関数ごとの抽象化のレベルについて著者が話している段落に出くわしました。彼はいくつかのコードを低/中/高レベルの抽象化として分類しました。 私の質問は、抽象化のレベルを決定するための基準は何ですか？ 本から段落を引用します。 関数が「1つのこと」を実行していることを確認するには、関数内のステートメントがすべて同じレベルの抽象化であることを確認する必要があります。リスト3-1がこのルールにどのように違反しているかは簡単にわかります。そこには、getHtml（）など、非常に高度な抽象化の概念があります。以下のような、抽象化の中間レベルにある他のもの：String pagePathName = PathParser.render（pagePath）; さらに、.append（ "\ n"）などの非常に低レベルのその他のものもあります。

35 abstraction 

プログラマーとして、私は自分のプログラムをできるだけ抽象的で一般的なものにするジレンマに陥っています。 そうすることで、通常、コードを再利用し、再び発生する可能性のある（または発生しない）問題のより一般的な解決策を得ることができます。 それから私の頭の中のこの声は、問題のダミーを簡単に解決するだけだと言います！なぜあなたが必要以上に多くの時間を費やしますか？ 実際、私たちは皆、この疑問に直面してきました。そこでは、抽象化があなたの右肩にあり、Solve-it-愚かな人が左に座っています。 どれを、どのくらいの頻度で聞くべきですか？これに対するあなたの戦略は何ですか？すべてを抽象化する必要がありますか？

33 time-management  problem-solving  abstraction 

これらの用語を理解することは私にとって非常に困難です。私はグーグルで検索し、ウィキペディアで少し読みましたが、まだわかりません。私はこれまでのところ以下を決定しました： 抽象データ型は新しい型の定義であり、そのプロパティと操作を説明します。 データ構造は、ADTの実装です。多くのADTは、同じデータ構造として実装できます。 私が正しいと思うなら、ADTとしての配列は、要素のコレクションを意味し、データ構造として、それがメモリにどのように保存されるかを意味します。スタックはプッシュ、ポップ操作を備えたADTですが、アルゴリズムで配列として実装されたスタックを使用した場合、スタックデータ構造について言えますか？そして、なぜヒープはADTではないのですか？ツリーまたは配列として実装できます。

32 data-structures  abstraction 

バックグラウンド 私は抽象化の大ファンではありません。インターフェースの適応性、移植性、再利用性などの恩恵を受けることができると認めます。そこには本当の利点がありますが、それを疑いたくないので無視しましょう。 抽象化のもう1つの主要な「利点」があります。これは、この抽象化のユーザーから実装ロジックと詳細を隠すことです。引数は、詳細を知る必要はなく、この時点で独自のロジックに集中する必要があるということです。理論的には理にかなっています。 ただし、大規模なエンタープライズアプリケーションを保守しているときはいつでも、常に詳細を知る必要があります。それは、何かが正確に何であるかを正確に見つけるために、毎回、抽象化を深く掘り下げる大きな手間となります。つまり、使用されているストアドプロシージャを見つける前に約12回「宣言を開く」必要があります。 この「詳細を隠す」という考え方は、邪魔をしているようです。私は常に、より透明なインターフェースとより少ない抽象化を望んでいます。私は高レベルのソースコードを読むことができ、それが何をするのかを知ることができますが、それがどのように行われるのか、それがどのように行われるのかを知る必要はありません。 何が起きてる？私がこれまでに取り組んできたすべてのシステムは、（少なくともこの観点から）ひどく設計されていますか？ 私の哲学 ソフトウェアを開発するとき、私はArchLinuxの哲学と密接に関連していると思う哲学に従うように感じています： Arch Linuxは、GNU / Linuxシステムに固有の複雑さを保持しながら、それらを適切に組織化して透明性を保ちます。Arch Linuxの開発者とユーザーは、システムの複雑さを隠そうとすると、実際にはさらに複雑なシステムになるため、避けるべきだと考えています。 したがって、抽象レイヤーの背後にソフトウェアの複雑さを隠そうとはしません。私は抽象化を悪用しようとしますが、それの奴隷になることはしません。 心からの質問 詳細を隠すことには本当の価値がありますか？ 透明性を犠牲にしませんか？ この透明性は重要ではありませんか？

30 object-oriented-design  abstraction 

ソフトウェアに抽象化が多すぎて設計パターンが多すぎる、またはその逆を言うには、どうすればもっと多くの抽象化が必要かを知ることができますか？ 私が協力している開発者は、これらの点に関して異なる方法でプログラミングしています。 いくつかの小さな機能をすべて抽象化し、可能な限りデザインパターンを使用し、いかなるコストでも冗長性を回避します。 私を含む他の人は、より実用的であることを試み、すべての設計パターンに完全に適合するわけではありませんが、適用される抽象化が少ないため、理解がはるかに速いコードを記述します。 これはトレードオフであることを知っています。プロジェクトに十分な抽象化が行われていることをどのように確認できますか？ 例、Memcacheを使用して汎用キャッシングレイヤーを作成する場合。私たちは本当に必要ですかMemcache、MemcacheAdapter、MemcacheInterface、AbstractCache、CacheFactory、CacheConnector、...またはこれは、保守が容易とまだ良いコードは、これらのクラスの半分しか使用している場合ですか？ Twitterでこれを見つけました： （https://twitter.com/rawkode/status/875318003306565633）

29 design-patterns  architecture  clean-code  abstraction  architectural-patterns 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 私は1年弱のプログラミングを行っており、企業/組織向けのシステムアプリケーション、Webアプリ、およびスクリプトの記述経験があります。ただし、Django、Rails、Zendなどのフレームワークを使用することは、私が実際にやったことがありません。 Djangoフレームワークを見ると、フレームワークでどれだけ抽象化されているかに少しイライラしています。私はDRYと最小限のコードの中核的な目標を理解していますが、さまざまなモジュールへの過度の依存とコア機能の重い抽象化の一部は次のように感じます。 モジュール/フレームワークの絶えず変化する性質のため、プログラムの日付を非常に速くします。 多数のフレームワークとモジュールが利用可能であり、すべての特異性があるため、コードを理解しにくくします。 すべてのドキュメントを読んでいない限り、コードを論理的にしません。つまり、リストの内包表記と条件付きロジックを読んでプログラムの動作を理解することができますが、任意の文字列と辞書を渡す必要がある関数を見ると、すでに第一人者でない限り、物事を理解するのは少し難しくなります指定されたモジュール。そして： フレームワークを切り替えるのが難しく、面倒です。言語の切り替えはすでに課題ですが、その中核となる機能/哲学を十分に理解している場合は管理しやすくなります。フレームワーク間の切り替えは、暗記の問題であるように思われます。これは、いくつかの点で、これらのフレームワークが排除するように設計された非常に非効率性を助長するようです。 MySQLクエリのような単純なものの上に50層の抽象化を実際に配置する必要がありますか？準備されたステートメント/入力テストは処理されますが、普遍的に理解可能なSQLクエリは依然として関数の一部であるPHPのPDOインターフェイスのようなものを使用しないのはなぜですか？ これらの抽象化は本当に便利ですか？機能が肥大化することで無駄になり、フレームワークを使用せずに作成された同様のアプリケーションと比較して、アプリケーションが難しくなりませんか？

24 web-development  python  frameworks  abstraction 

私は最近、原始的な強迫観念をコードの匂いとして説明する記事をたくさん読みました。 原始的な強迫観念を回避することには2つの利点があります。 ドメインモデルをより明確にします。たとえば、郵便番号を含む文字列ではなく郵便番号についてビジネスアナリストと話すことができます。 すべての検証は、アプリケーション全体ではなく1か所で行われます。 いつコードの匂いがするかを説明する記事がたくさんあります。たとえば、次のような投稿コードのプリミティブな強迫観念を取り除くことの利点を見ることができます。 public class Address { public ZipCode ZipCode { get; set; } } ZipCodeのコンストラクタは次のとおりです。 public ZipCode(string value) { // Perform regex matching to verify XXXXX or XXXXX-XXXX format _value = value; } 郵便番号が使用されるすべての場所にその検証ロジックを置くDRY原則を破ることになります。 ただし、次のオブジェクトについてはどうですか： 生年月日：気づきよりも大きく、今日の日付よりも小さいことを確認します。 給与：ゼロ以上であることを確認します。 DateOfBirthオブジェクトとSalaryオブジェクトを作成しますか？利点は、ドメインモデルを説明するときにそれらについて話すことができることです。ただし、これは多くの検証がないため、オーバーエンジニアリングの場合です。いつ、いつ原始的な強迫観念を取り除くべきでないかを説明するルールはありますか、可能であれば常にそれを行うべきですか？ クラスの代わりに型エイリアスを作成できると思います。これは上記のポイント1に役立ちます。

22 c#  domain-driven-design  domain-model  abstraction  modeling 

それにはいくつかの理論的な理由（型チェックや型推論が決定不能になるなど）か、実際的な理由（適切に実装するのが難しすぎる）がありますか？ 現在、我々はに物事をラップすることができますnewtypeように newtype Pair a = Pair (a, a) そして、持っている Pair :: * -> * しかし、私たちのようなことはできませんλ(a:*). (a,a)。 （例えば、Scalaが持っているような、それらを持っているいくつかの言語があります。）

22 haskell  abstraction  type-systems  lambda 

メッセージを受信するIRCボットを実装し、そのメッセージをチェックして、呼び出す関数を決定しています。これを行うより賢い方法はありますか？20個のコマンドが好きになった後、すぐに手に負えなくなるようです。 おそらくこれを抽象化するより良い方法がありますか？ public void onMessage(String channel, String sender, String login, String hostname, String message){ if (message.equalsIgnoreCase(".np")){ // TODO: Use Last.fm API to find the now playing } else if (message.toLowerCase().startsWith(".register")) { cmd.registerLastNick(channel, sender, message); } else if (message.toLowerCase().startsWith("give us a countdown")) { cmd.countdown(channel, message); } else if (message.toLowerCase().startsWith("remember am routine")) …

20 java  design  abstraction 

次の場合、リスコフの置換原則に違反していると読みました。 前提条件が強化されている、または 事後条件が弱体化 しかし、これらの2つの点がリスコフの代替原則にどのように違反するかは、まだ完全にはわかりません。例を挙げて説明してください。具体的には、上記の条件のいずれかが、サブクラスオブジェクトをスーパークラスオブジェクトに置き換えることができない状況をどのように引き起こしますか？

19 object-oriented  inheritance  abstraction  liskov-substitution