カップリングはプログラミングの習慣としては悪いようです。なぜOOPSはこのパラダイムを主張しているのですか？例として、Java、.net、Androidの長方形クラスを見た。それぞれは異なって定義されています。さらに、それを描くには長方形をインスタンス化する必要があります。oops、coupling and opengl
OpenGLでは、矩形描画は矩形オブジェクトに結合されません。このようにオブジェクトから矩形を描画することを切り離すことで、APIがより堅牢になります。矩形オブジェクトをまったく作成せずに、ラムダのような関数として矩形を描くことができます。
オブジェクトへのアクションの結合は、機能を抽象化するか、コンポーネントを作成する方法です。しかし、それは私には使用を制限し、すべてか何かを強制するようです。どちらかというと、私のオブジェクトとメソッドを使用するか、何も使用しない。そして、異なった方法で異なって定義された同じオブジェクトの拡散が続いた。
ライブラリは、オブジェクトのフィールドをタスクを達成するために必要なパラメータに分解する傾向があります。これは関数名にのみ追加されます。例えば。 oopsでは、それは "rectangle.draw（）"になるでしょう： "drawRectangle（x1、y1、x2、Y2）"。
なぜoopsは図形を図形に結合しますか？奇妙に思える。また、ハードウェアにアクセスする描画メソッドと新しいGPUが追加された場合、結合されていない場合は描画メソッドを変更するだけですべてのオブジェクトを変更する必要があります。
グラフィックスはoops抽象化が最良の方法ではないドメインですが、より洗練された問題です。
oopsでは、単に構造体のようなオブジェクトを定義するのではなく、オブジェクトでできることを大きく定義します。次に、オブジェクトと何ができるかをオブジェクトに結合します。これは、同じオブジェクトのさまざまな定義につながります。誰もがオブジェクトにできるすべてを知っていると仮定することはできません。
たとえば、長方形を2等分したい場合があります。 Rectangleオブジェクトに新しいbisectメソッドを追加するか、rectect構造をとるbisect関数を作成します。新しい機能が追加されると、構造は変更されませんが、オブジェクトのメソッドは密接に結合されているためオブジェクトを変更します。
構造上、コンセンサスに達することがあります。例えば。矩形は長さと幅が数値で表された構造体です。四角形でできることは、選択したライブラリによって異なります。
「OOPS」とは何ですか？また、OpenGLには 'drawRectangle'もありません。 –
Oopsはオブジェクト指向プログラミングシステムです。 OpenGLでは、長方形を描くために "glrectf（parameters）"のようなものです。 rectangle.gldrawf（）ではありません。 – Daryl
私はopenglがC++のようなoopsアプローチではなく、cのような機能的アプローチを取っているようだと強調していました。 OpenGL関数が明示的にオブジェクトに結びついていないという意味で、暗黙的にグラフィックドライバオブジェクトに結びついているかもしれません。 – Daryl