記事「DoEasyライブラリのグラフィックス(第83部): 抽象標準グラフィカルオブジェクトのクラス」についてのディスカッション

新しいコメント
 

新しい記事「DoEasyライブラリのグラフィックス(第83部): 抽象標準グラフィカルオブジェクトのクラス」はパブリッシュされました:

本稿では、抽象グラフィカルオブジェクトのクラスを作成します。このオブジェクトは、標準のグラフィカルオブジェクトのクラスを作成するための基礎として機能します。グラフィカルオブジェクトには複数のプロパティがあるため、抽象グラフィカルオブジェクトクラスを実際に作成する前に、多くの準備作業が必要です。この作業には、ライブラリ列挙型のプロパティの設定が含まれます。

EAを再コンパイルして起動します。

さまざまなグラフィカルオブジェクトがチャートに追加され、操作ログには新しいオブジェクトの追加に関するメッセージとその簡単な説明が表示されます。


ご覧のとおり、すべてが想定どおりに機能します。


作者: Artyom Trishkin

 
こんにちは、

あなたの記事をいくつか読みましたが、時々掲載されることもあり、概ねOKなのですが、いくつか混乱させられました......。

1.あなたの実装にはコードの重複が多すぎます。もちろん、後でリファクタリングがあるかもしれませんし、いくつかあるかもしれません)

2.標準的なオブジェクトを使うのであれば、ターミナルに付属している既成のクラスを使い、追加機能を持たせて、可能性を広げるのはどうだろう。
 
Daniil Kurmyshev #:
こんにちは、

あなたの記事をいくつか読みましたが、時折掲載されることもあり、概ねOKなのですが、いくつか混乱させられました...。

1.あなたの実装にはコードの重複が多すぎる。もちろん、後でリファクタリングがあるかもしれないし、いくつかあるかもしれない)

2.標準的なオブジェクトで作業するのであれば、ターミナルに付属している既製のクラスを使い、追加機能を持たせて、可能性を広げるのはどうだろう。
  1. もっと具体的に答えるために、重複の例を挙げてもらえますか？
  2. ライブラリ・オブジェクトを構築する構造とコンセプトは、標準ライブラリのコンセプトとは全く一致しません。ただ、お気づきかもしれませんが、ライブラリは標準のCObjectとCArrayObjをベースに構築されています。

とにかく、私は喜んで質問に答え、批判や提案を受け入れます。

ご興味を持っていただきありがとうございます。

 
Artyom Trishkin #:
  1. 具体的に重複の例を挙げてもらえますか？
  2. ライブラリーのオブジェクトを構築する構造やコンセプトは、標準ライブラリーのコンセプトとは全く衝突しません。しかし、お気づきのように、ライブラリは標準的なCObjectとCArrayObjの上に構築されています。

いずれにせよ、私は喜んで質問に答え、批判や提案を受け入れます。

ご関心をありがとうございました。

1.具体的には、「クラスのコードにさらに、オブジェクトのプロパティのセットとリターンへのアクセスを簡略化するためのメソッドを記述する：」で始まる部分についてです。

私の理解では、これは基底クラスの関数の説明です。つまり、すべてのオブジェクトに対して網羅的で、アクセスレベルはpublicです。このオブジェクトを使用するには、 CObjectから 直接ではなく、常に基底クラスを引きます。もちろん、基底クラスのすべての機能、ログ出力などを取得することは理にかなっているかもしれませんが、継承者を作成する際には、継承者のクラスに適用できないすべての関数を仮想化し、アクセスレベルprivateで非表示にする必要があります。

もしかしたら、これがあなたの実装のトリックかもしれません。）

ちなみに、関数によってはpublicよりも protectedレベルの方が適切なものもあるかもしれませんが、ここはもちろん、どのような意味が込められているかによって、あなたの方がよくご存知でしょう。

2.そうですね、あなたのコードをもう一度見直しましたが、ライブラリを構築するコンセプトが違いますね。

3.私はまた、あなたが+で文字列のマージを使用していることに気づいた、大きなマージで端末のいくつかのバージョンでは、このような実装では長い端末操作で予測できない状況)))

私はStringFormatとStringAdd関数を使用して、作業の信頼性が増加し、また、視覚的にコードがより読みやすくなります。

4.私はまた、レンダリング時に 作成されたオブジェクトの長さの制限について警告したかった、それを心に留めて、名前からハッシュを生成し、それに基づいてオブジェクトを作成する方が良いです、制限は、私は正確に覚えていないが、おそらくResourceCreate...標準関数を持っています。

 
Daniil Kurmyshev #:

1.具体的に言うと、「クラスのコードをさらに進めると、オブジェクトのプロパティのセットとリターンに簡単にアクセスできるメソッドを書くことに なります。

私の理解では、これは基底クラスの関数の説明であり、すべてのオブジェクトに対して網羅的であり、アクセスレベルはpublicです。このオブジェクトを使用するには、 CObjectから 直接ではなく、常に基底クラスを引きます。もちろん、基底クラスのすべての機能、ログ出力などを取得することは理にかなっているかもしれませんが、継承者を作成する際には、継承者のクラスに適用できないすべての関数を仮想化し、アクセスレベルprivateで非表示にする必要があります。

もしかしたら、これがあなたの実装のトリックかもしれません。）

ちなみに、関数によってはpublicよりも protectedレベルの方が適切なものもあるかもしれませんが、もちろんその意味するところはあなたの方がよくご存知でしょう。

2.そうですね、もう一度あなたのコードを見直しましたが、ライブラリの構築のコンセプトが違いますね。

3.また、文字列を+で結合していることに気づきましたが、ターミナルのいくつかのバージョンでは、大きな組み合わせや長いターミナル操作で、そのような実装では予測できない状況が得られました))))

私はStringFormat関数とStringAdd関数を使用しています。

4.私はまた、レンダリング時に 作成されたオブジェクトの長さの制限について警告したかった、このことを覚えておいて、名前のキャッシュを生成し、それに基づいてオブジェクトを作成する方が良いです、制限は、私は正確に覚えていないが、おそらくResourceCreate...標準関数を持っています。

1.メソッドの公共性とその冗長性は、同じプロパティにアクセスするための多くの異なる方法を作りたいというコストです。しかし、メソッドの中には仮想的なものや、継承者のみに規定されているものもあります。しかし、これもライブラリ自体のオブジェクトにしか適用されない。ライブラリから継承する場合は、残念ながらすべてのパブリック・メソッドが継承されます。

2.考えてみる。しかし、実際には、トップレベルのアクセスは、ライブラリへのもう一つの入口になるでしょう。それは、ユーザー定義関数になるでしょう。ここでも、すでに実装されているライブラリの機能を繰り返しますが、一般的なユーザーにはより理解しやすいものになるでしょう。

3.私は（事前に考えたロジック以外は）何も最適化していませんし、何もプロファイリングしていません。これは最後の瞬間のためだ。

4.私のやり方でチェックした。長いオブジェクト名は可能です。でも、ありがとう、心に留めておきます。

 
Artyom Trishkin #:

1.メソッドをpublicにして冗長にすることは、同じプロパティにアクセスするさまざまな方法を作りたいがための代償である。しかし、メソッドの中には確かに仮想的なものや、継承者のみに規定されるものもあるだろう。しかし、これもライブラリ自体のオブジェクトにしか適用されない。ライブラリから継承する場合は、残念ながらすべてのパブリック・メソッドが継承される。

2.考えてみる。しかし実際には、トップレベルのアクセスは、ライブラリへのもうひとつの入口になるだろう。それはユーザー定義関数で、ここでもすでに実装されているライブラリの機能を繰り返すことになるが、一般的なユーザーにはより理解しやすいものになるだろう。結果を得るために関数を使うだけで、ロジックやハンドラーを考案する必要はない。これらはすべてライブラリ内部で行われ、出力は必要な情報を単純に得るためのユーザーケース関数になるだろう。

3.私は（事前に考えたロジック以外は）何も最適化していませんし、何もプロファイリングしていません。これは最後の瞬間のためです。

4.私のやり方でチェックした。長いオブジェクト名は可能です。でも、ありがとう、心に留めておいて見守るよ。

4.このエラーは解消されたかもしれませんが、確かではありません...関数は動作しているようですが、オブジェクトが作成されません。

 
それは事実で、私はこのコースに入るつもりで、そのためにインフォメーション・テクノロジーを選択した。
新しいコメント