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

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

そこには、別の問題があるのです。核となる要素やパラメーターの制限。解決すべきことは分かっている。ただ、まだチャンスがないんです。

だから聞いているんです。カーネルに21本の糸が縫い込まれていたら、とてもじゃないけど直せないしね。

レグ・コノウ

いいえ、コンストラクタのために書かれた外部コードです。それで表が再現される。そして、ボタンをクリックすると、すべての接続ファイルとエンジンのブートカーネルがプリントされるのです。そうすれば、すべてがうまくいくのです。

私の理解では、これは自動接続コードとカーネルコードの一部を生成するオートジェネレータです。これは面白い解決策ですね。

 
Vasiliy Sokolov:

まだテストしていません。

私には効果的です。しかし、ストップがかかったときに行を閉じることに問題があるようです。列が残ることもあります。これは、私が書いたコードにおけるクローズドオーダーの検出の問題です。テーブルは関係ない。

 
Vasiliy Sokolov:

1.だから聞いているんです。カーネルに21行も入っていたら、まずいから直せばいいというものでもないでしょう。

2.オートコネクトコードに加え、カーネルコードの一部を生成するオートジェネレータだと理解しています。面白い解決策ですね。

1.その通りです。コンストラクタで指定できる要素の数は限られています。したがって、ダイナミックテーブルは限られた行数で構成され、同時に無制限であることが必要である。解決策は、追加したパラメータ用に特別な配列を作成し、その値をテーブルのセルで スクロールさせるだけです。

2.はい、コンストラクタは、引用されたコードに基づいてエンジンのカーネルを作成します。+は接続ファイルを表示します。そして、カーネルをエンジン（DRIVE）に乗せました。その後、エンジンは目的のGUIを再生することができます。インターフェースファイルは、EAに接続し、EAとの対話を開始します。

 

そこで、根拠のない話にならないように、最後に「カーネル」そのものの例を挙げます。より正確には、ブートファイルである。カーネルはいくつかあります。

KIBコードに基づき、自動的に印刷されることを念のためお伝えしておきます。その後、エンジンに搭載。さらに、エンジンが連動する。

ファイル:
D_r7impg07d2r_x6q8.mqh  9272 kb
 
Реter Konow:

ニコライ 話題を変えよう。例えば、すでに扱ったことのあるCCanvasクラスを見てみましょう。そこで、すべての機能を取り出してみました。クラスラッパーから独立させた。今はどう悪くなったのでしょうか？仕事がしやすくなった。これらの機能を使って、アニメーションを作ってみました。それまでは、このクラスでアニメーションを見ることはほとんどありませんでした。

では、なぜこのラッパーなのか？

あなたもキャンバスに描いているんですよ。特定の関数を呼び出して描画すればいいんじゃない？でも、ダメなんです。包んで包んで包んで包んで。では、なぜなのか、説明してください。

はい、メガ便利だからです。しかし、これは自分で使い始めてみないとなかなか理解できない。
そして、これは全くラッパーではなく、独立した多機能な要素であり、そのプロパティやパラメーターのリストが可視化されているため、エディターで使用するのに便利なだけでなく、特定のモジュールとして他のプログラムで編集して使用するのにも便利なものなのです。
 
Nikolai Semko:
そう、メガコンフォートだからです。でも、自分で使い始めてみないと、なかなか理解できないものなんです。
また、ラッパーではなく、独立した多機能な要素であり、プロパティやパラメーターのリストが可視化されているため、エディターで使用するのに便利なだけでなく、特定のモジュールとして他のプログラムで編集して使用するのに便利です。

自分の都合のいいように考えることができないのです。したがって、私にとっては不便です。包み込むように、オブジェクトの向きを描写する。必要なときとそうでないときの分類をするために...。

OOPが果たすべき役割の前に、OOP自体が立ちはだかる印象があります。つまり、機構は完全性を追求しなければならず、そのためにブロックの数を最小にしなければならない。しかし、OOPはこれらのブロックを何らかの理由で強制的に増殖させる。その結果、メカの構造がボロボロになり、うまく動かなくなるのです。そして、さらに悪い方向に発展していくのです。


ニコライさん、Kanvasクラスの10倍の大きさのメガ機構を作り始めると、どこでどうOOPが不便になるのか、理解できるようになりますよ。

 
Реter Konow:

どう考えたらいいのかわからない。ですから、私としては違和感があるのです。包み込むように、オブジェクト指向を描き出す。必要なときと必要でないときの分類...

OOPが果たすべき役割の前に、OOP自体が立ちはだかる印象があります。つまり、機構は完全性を追求しなければならず、そのためにブロックの数を最小にしなければならない。しかし、OOPはこれらのブロックを何らかの理由で強制的に増殖させる。その結果、メカの構造がボロボロになり、うまく動かなくなるのです。そして、さらに悪い方向に発展していくのです。

ニコライさん、Kanvasクラスの10倍の大きさのメガ機構を作り始めると、どこでどうOOPが不便になるのか、理解できるようになりますよ。

あなたの言葉は、ただひとつ。


 
昔々、あるところに素敵なプログラマーがいました。彼は自分のためにプログラミングをし、何の悲しみも知らず、幸せそうでしたが、彼はOOPの大反対者だったのです。
年月が経ち、プログラマーも年を取り、いよいよ自分の時代が来たと感じ、孫や親類を呼んで言うのです。
- ノートパソコンを持ってきてくれれば、OOPを使って 表計算ソフトを作りますよ
みんな驚いて言うんです。
- なんで、ずっとタブレットでOOPなしでやってるんだ。何があったんですか？
そして、プログラマーはこう答える。
- OOPでスプレッドシートを作ってから死ねば、OOP-erが一人減りますよ。
 
Nikolai Semko:

...

ニコライさん、あなたのOOPに対する愛情は、ほとんど抽象的な理由以外では正当化されないと思ったことはありませんか？

例えば、このOOPで巨大な機構を作るのであれば、なぜそこまで必要なのかは明らかでしょう。なぜOOPが必要なのか、具体的に正当化するのです。でも、比較的小さな機構を作るんですね。この手法の欠点や利点について結論を出すには、十分なコードがありません。しかし、あなたはとにかくOOPについて話し続けています。一方、OOPはあくまでツールであり、それ自体に意味はない。つまり、作るべき仕組みがなければ、OOPは必要ないのです。しかし、もしメカニズムがあるとすれば、それを作る際にOOPを必要とするほど重大なものでなければなりません。

OOPを掲げる人のほとんどは、まともなものは作らない。小さなことしかやらない。しかし、彼らのOOPに対する信念は揺るがない。また、もっと本格的な仕組みを作っている人は、OOPの素晴らしさを叫ぶことはあまりないでしょう。中には批判を口にする人もいる（何度かあった）。

ですから、あなたの主張は理論だけでなく、実践に裏打ちされたものである必要があるのです。例えば、GUI開発におけるOOPの利点について、Anatolyと議論することができます。なぜなら、ソリューションとそのニュアンスを実際に比較することができるからです。でも、あなたには理解できないから、私の主張を展開することはできない。そうだろうけど、理解できないだろうね（悪気はない）。アナトリーは逆に、よく理解できる。グローバルな仕組みづくりの経験の差が、誤解を生む主な原因です。

SZY：実務家として言わせてもらえば、プログラマーの頭脳のポテンシャルを最大限に 引き出すようなアプローチでなければなりません。そんなアプローチを自分自身で見つけてきました。

 
Реter Konow:


まあ、大きなものを出さなければ、大きなものがないというわけでもないのですが。ただ、小さなことしかシェアしていないんです。
また、私はOOPがまだなかった頃にプログラミングを学んだので、OOPのパラダイムに長い間抵抗がありました。そして、OOPは私にとって、大きなプロジェクトの 手続き型コードに埋没し始めた頃に、強制的に必要になったものです。そして、OOPの魅力とパワーをすべて実践で理解したとき、手続き型プログラミングで失った時間を悔やみました。
1...128129130131132133134135136137138139140141142...184
新しいコメント