0

私は、画像の読み込み/キャッシュシステムの多くの試行/エラーバージョンに取り組んできました。Delphiである私は、常にオブジェクト指向プログラミングに慣れています。しかし、私はいくつかのマルチスレッドの実装を開始して以来、このシステムは代わりに手続きベースで機能するはずだと考えていました。

これらのプロセスがスレッドプールにキックインされ、イメージのダーティなロード/保存を実行し、それらを解放するためです。プロシージャ/関数、レコード、イベント、およびグラフィックスを使用できるときに、これらのスレッド化されたプロセスをオブジェクト内にラップしようとしてきました。すべてがユニット内にある場合、すべてをクラス内にラップする必要はありません...そうですか？

今私が尋ねている主な理由の1つは、このシステムがユニットの下部で初期化されているためです。OmniThreadLibrary（OTL）を使用する場合、すでに初期化された独自のスレッドプールがあり、私も初期化する必要はありません。

では、このシステムにはどちらのアプローチが適しているのでしょうか。オブジェクト内にラップされているのか、ユニット内で機能しているだけなのか、そしてその理由は何ですか。オブジェクト内ではなく、ユニット内で何もラップしないマルチスレッドの例はありますか？

4

3 に答える 3

3

あなたがシングルトンを持っているなら、それは個人的な好みの問題に要約されます。これが私の考えです：

  • コードベースの残りの部分でOOPを使用している場合は、手続き型を使用すると、このコードの外観と雰囲気がおかしくなる可能性があります。
  • OOPを使用する場合は、プロパティ、デフォルトプロパティ、配列プロパティを使用できます。それはあなたのインターフェースをより使いやすくするかもしれません。
  • 機能をクラスに入れると、追加の名前空間レベルが得られます。あなたはそれを感謝するかもしれないし、しないかもしれない。
  • グローバルスコープで多くの状態を維持する必要がある場合は、おそらくそれをレコードにまとめます。そして、このグローバルレコードインスタンスを操作する関数があります。その時点で、コードはオブジェクト構文で記述された方が読みやすくなります。

結論としては、それは実際には問題ではなく、プロジェクトに最適なものを選択する必要があるということです。

于 2012-01-28T11:54:49.513 に答える
1

OOP は、すべてに対して新しいオブジェクトを作成する必要があるという意味ではありません。既存のオブジェクトから単純に継承することもできます。(OTLのwhatever threadオブジェクトのように)

とにかく、どこでも OO を導入することに熱狂しているわけではありませんが、手続き型が必要な理由があなたのテキストには見当たりません。

于 2012-01-28T10:45:09.223 に答える
-1

それは決してイエス/ノーの決定ではありません。

私は、クラスの一部ではない関数やプロシージャを使用する傾向があります。それらの作業が状態とは関係がない場合や、ユーティリティ文字列関数の場合のように、それらが有用であり、個別に再利用されることを目的としている場合です。独自のユーティリティユニット。「画像ユーティリティ関数」が必要であり、クラスに含まれている必要がない場合があります。

関数がバックグラウンドスレッドのコンテキストでのみ実行される場合、それはおそらくTThreadの子孫に属し、フォアグラウンドによって呼び出されない場合は、プライベートにすることができ、OOPとそのスコープ隠蔽機能を非常に高くします。スレッドプログラミングに適しています。

私の大まかなルールは次のとおりです。スタンドアロンの関数/プロシージャを実際の方法で作成してもメリットがない場合は、OOP以外のプロシージャに戻らないでください。

一部の人々はOOPに夢中になっているため、OOP以外の関数やプロシージャを避け、すべてのクラスラッパーを使用したいと考えています。私はそれを「Javaコードの臭い」と呼んでいます。しかし、OOPを回避する理由はありません。それは単なるツールです。意味のある場所で使用してください。

于 2012-01-28T13:02:36.973 に答える