問題タブ [abstraction]

先日、Linus Torwalds によるかなり古い usenet の投稿に出くわしました。それは、より現代的なものではなくプレーンな C を Git に使用するという彼の選択を擁護する、悪名高い「あなたはブル****でいっぱいです」という投稿です。

特に、この投稿は、私が働いている場所で積み重ねられた膨大な量の抽象化レイヤーについて考えさせられました。私の環境は Windows .Net 環境です。私は C# と .Net 環境が好きだと言わざるを得ません。ほとんどのことが簡単になります。

現在、私は C のような Unix テクノロジと多数のスクリプト言語で構成された非常に異なるバックグラウンドを持っています。また、私にとって、OOP はただ 1 つのプログラミング パラダイムにすぎず、常に最高のプログラミング パラダイムであるとは限りません。 「あらゆる問題は、追加の抽象化レベルで解決できる」教会ですが、私は「シンプルに保つ」派です。異なる文化に触れることから生じる問題に対しては、非常に異なる精神的アプローチがあると思います。

非常に単純な例として、ここで行った最初のプロジェクトでは、アプリケーションの構成が必要でした。コロンで区切られたキーと値のペアを行ごとに 1 つずつ含む、プログラムのルート ディレクトリに配置される txt ファイルを読み込んで解析する 10 行のクラスを作成しました。出来た。

最後に、構成の問題へのアプローチを標準化するために、起動時に他の xml への参照を含む xml をロードするサービスを呼び出す各構成済みプログラムを実行するすべてのマシンにライブラリを配置する必要があります。アプリケーションごとに、構成自体が含まれています。

現在、それは拡張可能であり、洗練された再利用可能な抽象化、プロバイダー、およびすべてで構成されていますが、いつか実際にその一部を再利用して、それを構成するのに時間がかかった場合、必要なコードを作成できると思います最初から、または古いコードをコピー/ペーストして変更します。

それについてどう思いますか。問題を扱っている興味深い参考文献を指摘していただけますか?

ありがとう

以前のプロジェクトに似た新しいプロジェクトを開始しようとしています。古いデザインをコピーすることはできますが、古いデザインに満足しているわけではありません。

これは、バックエンドに Entity Framework を備えた .Net 3.5 (Winforms MDI) の上に構築された「標準的な」ビジネス システム (販売、棚卸、倉庫管理など) です。

すべてのフォームはベースフォーム (Windows.Form を継承) から継承します。このフォームは、最初の呼び出しで新しい ObjectContext をインスタンス化する ObjectContext というプロパティを公開します。これはかなり良い UnitOfWork を構成し、すべてのデータアクセスを各フォームで分離しています。

でも。

すべてのクエリと一般的な CRUD を「貧しい人々 のリポジトリ」にカプセル化しました。これらのリポジトリは、ObjectContext のプロパティとして公開されます。

したがって、フォームにバインドして注文する場合は、OrderLinesGrid = ObjectContext.OrderRepository.GetOrderLinesByID(orderID) を呼び出します。

OrderRepository は、このように、フォーム用に作成された objectcontext への参照を取得します。

(私の部分的な ObjectContext クラスで)

これについて私が気に入らない点は次のとおりです。

1. リポジトリへの呼び出しは、ObjectContext を通じて行われます。したがって、クエリと必要なデータアクセスレイヤーの間の抽象化が得られません。

2. ドメインの新しい型ごとに、ObjectContext にプロパティを作成する必要があります

OrderRepository への呼び出しは、ドメイン オブジェクトを返すだけで、それがどのように保持されるかを気にする必要はありません。また、各リポジトリに独自の ObjectContext を持たせることはできません。これは、Country を Order.Country プロパティに参照するときにオブジェクトをアタッチおよびデタッチする必要があるためです。

このデザインに関するアイデアやフィードバックをいただければ幸いです :)

オブジェクト自体に処理させるのではなく、フォームオブジェクトがどのような種類のコードを処理する必要があるかについて、厳格なルールを持っている人はいますか? たとえば、レースがある場合、レースをしているオブジェクトは馬と言うべきで、レースを馬であることの一部として扱うべきでしょうか、それともフォームオブジェクト内に配置する方が良いでしょうか? 私が求めているのは、メソッドと言うように馬のようなオブジェクトに何が入り、馬ではなくフォームオブジェクトに何が入るかをどのように決定するかということだと思います。この場合、コードを最適に抽象化する場所を特定するために使用するルールはありますか?

具体的なクラスに直接ではなく、インターフェイスに対するプログラミングを推奨するのはいつですか?

私が従うガイドラインは、コードが論理的/物理的境界を越える必要があるときはいつでも抽象化を作成することです。特にインフラストラクチャ関連の問題が関係している場合はそうです。

もう 1 つのチェックポイントは、追加の懸念コード (キャッシュ、トランザクション認識、インプロセス実行ではなく Web サービスの呼び出しなど) が原因で、依存関係が将来変更される可能性があるかどうか、またはそのような依存関係がインフラストラクチャ統合ポイントへの直接参照を持っているかどうかです。

コードが、論理的/物理的境界を越えるための制御を必要としないものに依存している場合、多かれ少なかれそれらと対話するための抽象化を作成しません。

何か不足していますか？

「どのJSライブラリを使用していますか」という投票でこのコメントを見たばかりです

「@Xanti-はい、はい、プログラミングにおけるモジュール化と抽象化はひどい習慣です。他の関数を呼び出す関数？無駄です。」

PHP用のKohanaフレームワークとjavascript用のJqueryライブラリを使用しているので、それは私に興味をそそられました。

なぜ一部の人々は抽象化とモジュール化の悪い習慣を考えるのですか？フレームワークとライブラリは、開発を容易にし、スピードアップするために作られていませんか？

ここに投票へのリンクがあります

クラスの開発に関する多くの記事を読みました (私は php を使用しています)。タグ行は「スケーラブル、堅牢、保守可能、拡張可能」です。

しかし、初心者として、私は「抽象化された」クラスを作成してきました。つまり、一連のコードまたは反復コードを分離してクラスに入れ、一般的なタスクにアクセスするためのメソッドを提供しただけです。

問題は、自分のクラスを拡張可能にする方法を見つけることができないということです (抽象クラスなどの概念は知っていますが、それらを使用していますが、他のクラスが従うメソッドを定義するためだけに使用しています)。問題は、機能を追加するためだけにコアクラスを編集していることに常に気付くことです。

クラスを拡張可能にするためのヒントはありますか? （私はこれについてグーグルで検索しましたが、飛び出すものはすべて抽象クラス、インターフェース、およびOOPの説明であり、ポインターに関する議論や拡張可能なクラスを作成するためのヒントはありません）。

ところで、私に気をつけてください、私は9か月前に「実際の」oopプログラミングを始めました（私が出身の大学は私にOOPの理論を進めさせましたが、彼らは私たちに手続き的に取り組んでいました.締め切り、それは私が卒業するまで 4 年間続きました)。

実装クラスが T のリストを実装する必要がある抽象クラスに取り組んでいます。問題は、これが機能しないことです。

私が見逃している明らかな答えがあると確信しており、リストに入れる抽象基本型を作成できることはわかっていますが、Linq コマンドを使用してリストを作成すると、抽象型 (ItemBase ) は .ToList() メソッドではうまく機能しません。私がやろうとしていることはとてもユニークですか？

プラットフォームに関係なく、PythonでSamba共有に接続できるようにする抽象化はありますか？

詳しくは

シェアをマウントしたくありません。smbclientのputなどのファイルを共有にアップロードしたいだけです。

ありがとう、ピート

私は次の2つのクラスを持っています、1つは他から継承します

次に、別のクラスで次のようになります。

これは常にA
を出力します。ベクトルに追加したものに応じてBまたはCを出力したいのですが、
どうすればよいですか？
抽象化を試しましたが、C ++での使用方法が完全にはわかりません。また、抽象化が機能していません。

.Net に数値のポリモーフィズムがないこと、つまり、bool、byte、uint、int などのさまざまな種類の数値型を統一する INumeric インターフェイスがないことは本当に残念です。極端な場合、抽象の完全なパッケージが必要です。代数型。

Joe Duffy には、この問題に関する記事があります。

http://www.bluebytesoftware.com/blog/CommentView,guid,14b37ade-3110-4596-9d6e-bacdcd75baa8.aspx

.Net や C# に影響を与えることなく、これを改良するために、C# でこれをどのように表現しますか?

最初に 1 つ以上の抽象型 (INumeric などのインターフェイス、またはそれ以上の抽象型) を定義してから、これらを実装する構造体を定義し、新しい型を返す操作を提供しながら int などの型をラップするという 1 つのアイデアがあります (例: Integer32 : INumeric; ここで加算は次のように定義されます

このコードの実行速度が少し心配ですが、少なくとも抽象的です。

良さをオーバーロードする演算子はありません...

他のアイデアはありますか？

.Net は、この種の抽象化がなく、効率的であることができない場合、実行可能な長期的なプラットフォームのようには見えません。

抽象化は再利用です。

アップデート：

これは、これまでの実装型シグネチャの例です。

共変の戻り値の型の欠如を補う。