プログラミングでオブジェクトを表現すること。 - ページ 9

新しいコメント
 
JRandomTrader #:

付録」は何で書かれているのですか？

アプリケーション言語において。

 

第2部

前編では、「オブジェクト」の構成要素についてお話しましたが、今回は、その構成要素同士の関係について考えてみたいと思います。コンポーネント自体は、本格的なオブジェクトではなく、すべてのオブジェクトやシステムの一部である「ビルディング」エンティティを表すため、慣習的に「プロトブロック」と呼ばれます。彼らの最初のリストを思い出してみよう。

  • パラメータ - 特定の構造セットまたは値を、名前を付けて数値で圧縮した表現。
  • プロパティのセット - Objectに含まれるパラメータのリスト。
  • コンストラクタ関数- パラメータのリストに基づいてオブジェクトを再生成するアルゴリズム。
  • Shape- Objectに属する、2次元または3次元に存在するセットの種類を結合したものです。
  • 状態- Object の存在における 重要な「分岐点」、環境条件の変化やプログラムの独立した実行の過程で Object が通過 するパラメータの値。
  • イベント - オブジェクト自体またはその周囲に起こる意味のある変化。
  • プロセス - 外部環境の条件の変化やプログラムの独立した実行 の結果、対象物の状態が変化する様々なシーケンス。

フォーム、ステート、イベント、プロセスのパラメトリック「ボディ」に加えて、プロトブロックからオブジェクトのパラメトリックセットに値を「転送」するタスクを持つハンドラ関数（単に「ハンドラ」と呼ぶことにしましょう）を追加します。例：Labelのコンストラクタ関数には5つのパラメータがあり、この集合がそのパラメータの "本体 "となる。新しい状態を発明し、それを初期パラメータの異なる値として書いたとすると、ラベルを新しい状態に移動させる必要がある瞬間に、それらを状態のパラメトリック構造からラベルのパラメトリック「本体」に転送する関数を呼び出す必要があります。簡単に言うと、このハンドラは、そのプロトブロックの値でObjectパラメータを初期化します。Processと Formについては、Object本体に値を転送することで同様の原理が働きますが、実装が異なります。しかし、Eventを 処理するためには、値を転送する必要はなく、値をチェックする必要があるので、ハンドラとして条件文が必要です。

私のコンセプトには多くのハンドラーがあり、それらは別の分類に値するのですが、発表が複雑になりすぎるため、いくつかのグループに大別して、表面的に触れることにします。

  • 「トランスポーター」 - プロトブロックからObjectに値を転送するハンドラー（例：ステート、フォーム、プロセスからObjectのターゲットパラメータに転送する）。
  • 「バウンド」 - システムのバウンド（依存）パラメータの値を変更するハンドラ（例：放物線の運動軌跡は座標値の同期的な変更を意味し、これはバウンドx、yハンドラによって実装されています）。パラメータ関係の依存関係は、数式で表現したり、ハンドラ本体に含まれる条件によって定義することができる。
  • 「アセンブラ" - Objectのパラメトリックボディからプロトブロックを "アンパック "して、重要な現在の値で保存したり、他のプロトブロックを部分的または完全に "クローン "して、コピーに必要な変更を行うことによって、新しいプロトブロックを "構築 "するハンドラです。このとき、プロトブロックから表形式または階層構造を形成し、それらを格納する特別な「モジュール」の中に配置される。
  • "Modular" - プロトブロックが格納されているさまざまなタイプの モジュールのハンドラ。*プロトブロックの「モジュール」については、後述します）。

これは決して完全なリストではなく、ハンドラの名称も任意であるが、その専門性の区分は一般に次のようなものである。


ハンドラ関数の次に追加されるコンセプトは「モジュール」でしょう。作成されたプロトブロックはどこかに保存され、整理されなければならないと考えるのは論理的です。また、混乱を避け、ハンドラがオブジェクトの成長するコンテンツの中を簡単に「移動」できるように、異なるタイプのプロトブロックの保存を分けるのが最適であろうことは容易に想像できます。そこで、プロトブロックの「ストレージ」、あるいはより美しい「モジュール」を作成するのです。オブジェクトのState、Processes、Event、Formsについては、それぞれのモジュールが作成され、その中にプロトブロックが作成されます。

  1. 整然とした状態で保管されている。
  2. 掛け合わせる。
  3. 必要に応じてハンドラで回収する。
  4. 他のモジュールのプロトブロックにリンクする。

4点目の「異なるタイプのプロトブロックを "つなぐ"」というのは、まさに第1部でお話しした「プロセスには国家が含まれる」「...」という「構造的包含」に基づいています。イベントには、国家、...プロセスは、イベント、...を含む。StateはFormを含むことができるなど...。例えば、イベントモデルを 別のモジュールで構築した場合、その条件階層には「Event」モジュールに格納される「Event」が含まれ、その「Event」が「States」モジュールに格納される「State」が含まれることになる。このように、プロトブロックの保管と利用の効率的な順序を作るだけでなく、モジュール間のリンクでつなぐだけでその「構造的包含性」を実装しています。リンクを任意に、あるいは知的に変更することで、既存のプロトブロックから新しいプロトブロックを作成したり、オブジェクトの「振る舞い」におけるイベントやロジックモデルを変更したりすることができるのです。ロジックモデルのレベルで関係を変更すれば（その結果、そのモジュールに格納される）、プログラムを完全に変更することができ、その際、コードの中で何も書き換える必要がない。そこで、プロトブロックをモジュールで分離することのメリットを実感しています。

以上、今回はこの辺で。次に、イベントモデル、ロジックモデルに移り、その構築方法を考えてみる。

不明な点や気になる点があれば、質問してください。


 
何のためのコンセプトなのか？
 
Aliaksandr Hryshyn #:
何のためのコンセプトなのか？

このコンセプトは、プログラミングの次のレベルへの試みであり、私の考えでは、機能的なシステムを人間が書くのではなく、コンピュータ自身が「構築」することになると考えています。このソフトは、プログラムを作成することができるようになります。

今、githabのコードで学習させたニューラルネットワークがありますが、そういう意味では全くないんです。

 
一つわからないことがあります。トレンドラインのObjectCreate(...)に値を設定しても、画面に線が表示されないのです。オブジェクトを表示する方法を教えてください。
 
Реter Konow #:

このコンセプトは、プログラミングの次のレベルへの試みであり、私の考えでは、機能的なシステムを人間が書くのではなく、コンピュータ自身が「構築」することになると考えています。このソフトは、プログラムを作成することができるようになります。

今はgithabのコードで学習させたニューラルネットワークがありますが、そういうことでは全くありません。

ピーターさん、こんにちは。
OOPの他にDDD（ドメイン駆動設計）もある
一応、お知らせしておきます。

 
Nikolai Semko #:

ピーターさん、こんにちは。
OOPの他に、DDD（ドメイン駆動設計）がある
一応知っておいてください。

暖かいものと柔らかいものを混同している。

 
Andrei Trukhanovich #:

暖かいものと柔らかいものを混同している。

あなたもホットとコールドを混同している
 
Vladimir Baskakov #:

信号はどこだ、兄弟？

 
Andrei Trukhanovich #:

信号はどこだ、兄弟？

あなたのは？
1234567891011121314151617
新しいコメント