私のアプローチコアはエンジンです。 - ページ 16

新しいコメント
 
Реter Konow:

今のところ、お客さまは1人です。私は彼のタスクをとても速く完了させます。3〜4時間で、完全に機能する新しいウィンドウが出来上がります。接続インターフェースと合わせてまた、エンジンのバグを素早く修正し、新しいバージョンを送っています。数日で9つのウィンドウズ＋エンジンの変更、バグフィックス、機能追加...。すべてにおいて非常に速い。

自由な時間が多いのでしょうね。

 
Vasiliy Sokolov:

自分一人では十分でないことを理解している。あなたのエンジンの質量は、他のプログラマーに気に入られるかどうかにかかっています（あなた一人ではすべての顧客に対して十分ではありません）。プロジェクターが嫌がるようなら嗚呼、あなたの創造物の運命は輝かしいものとなるでしょう。

プログラマーがエンジンコードに手を入れる必要はない。彼らは、ファイル内のそれへの接続インターフェイスを取得します。すでにテスト済みです。すべてがうまくいく。

 
Реter Konow:

今のところ、お客さまは1人です。私は彼のタスクをとても速く完了させます。3〜4時間で、完全に機能する新しいウィンドウが出来上がります。接続インターフェースと合わせてまた、エンジンのバグを素早く修正し、新しいバージョンを送っています。数日で9つのウィンドウズ＋エンジンの変更、バグフィックス、機能追加...。すべてにおいて非常に速い。

ちゃんと書いてあるのか？ウィンドウ作成に3〜4時間？分じゃないのか？

 
Реter Konow:

実はもう1年以上前からやっているんです。と混乱することもないのですが...))

比較のために、同じものをOOPで 実装する。もしかしたら、気に入っていただけるかもしれません。:)

 
Dmitry Fedoseev:

ちゃんと書いてあるのか？ウィンドウ作成に3〜4時間？分じゃないのか？

いいえ、別のウィンドウからコードをコピーして変更を加えれば、数分でできるようになります。でも、グラフィックを考えたり、スタイルを工夫したりと、ゼロから作るという話でした。

 
ところで、ピーターさん、ウィンドウズだけでインジケーターのようなあらゆる種類のグラフを追加し、いくつかのデータ形式（ジグザグのようなOHLCなど）をサポートすることを忘れないでください。あなたのプロジェクトで 簡単に実装できるものばかりだといいのですが。
 
Aliaksandr Hryshyn:
ところで、ピーターさん、ウィンドウズだけでインジケーターのようなあらゆる種類のグラフを追加し、いくつかのデータ形式（ジグザグのようなOHLCなど）をサポートすることを忘れないでください。あなたのプロジェクトで簡単に実装できるものばかりだといいのですが。

やってみます。

 
Реter Konow:

やってみます。

やらない、やります）。制作物の有用性を高める。

 
Dmitry Fedoseev:

ちゃんと書いてあるのか？ウィンドウ作成に3〜4時間？は、分ではない？

MQLで3つのウィンドウを作るには、MTツールキットのライブラリを使っても10分かかり、さらにボタン、編集、ラベルの高さとXYを合わせるのに20-30分かかる。

ペトルさんの作品が役に立つ理由は2つ考えられます。

- MQLのソースコード、つまりGUIコンストラクタを生成するための別のアプリケーションを作成し、それがどのように動作するかの詳細に入らないように、Visual MQL++と言う )))

- あるいは、自ら困難を作り出し、それを見事に乗り越えていく人たちがいる © Wingston Churchill

 

ピーターのOOPコンポーネントは、どれもディテールにこだわってばかりいるように思います。

そして、その問題の核心は、まさにシステムの哲学とアーキテクチャにあります。

ピーターにとって有利、相手にとって不利と思われる論点が何であるかは、前述した通りである。

- グローバルにアクセス可能な変数のヒープで、カプセル化されていません。

- 型崩れ

- データストレージの特定の実装に固執すること。

そしてPeterは、OOPのコンセプトは（少なくとも私の提案では）「プログラマの利便性に基づいて」単純化するように設計されていると正しく述べています。 カプセル化、型制御、インターフェース、これらすべてはまさにエラー、混乱、誤用の可能性を可能な限り排除するように設計されています。そうなんです。

ペテロのコンセプトはその逆です。すべてのデータはどこからでもアクセスでき、コードのどこからでもユーザーはプログラム内のすべてのオブジェクトを完全に制御でき、型の制限なしに（まあ、MQLの制限を除いて）好きなようにそれらを知覚することができます。

このコンセプトは、「最大限の発展を遂げることができる」とピーターさんは言います。ユーザビリティは二の次」。

個人的には、プログラマーとして、便利さが二の次になるのがもう嫌なんです。でも、実際に開発が進むとこれを犠牲にすることができるんです。さて、どんなものか見てみたい。制約とカプセル化を用いたOOPアプローチでは、巨大なサイズの配列に投げ込まれた膨大な数のプロパティにフルアクセスできるこのアプローチでは、このような開発に到達することはできません。(全部覚えるのはもちろんのこと）。

上記の通り、PascalのTurboVisionを彷彿とさせるアプローチである。ただし、そのライブラリには型制御やカプセル化制約がすでに実装されている。

1...91011121314151617181920212223...184
新しいコメント