構造のルール プログラムの構成方法を学び、可能性、エラー、解決策などを探る。 - ページ 3

新しいコメント
 
Urain:

おいおい、モデルなんて全くなかったのに、プロシージャから始めて、オブジェクトモデルに切り替えたんだぞ。

そして一般的に、デフォルトでMQはイベントベースのモデルを与えてくれます。私たちは最初に、すべてが起こるきっかけとなる事象を与えられます。

mq5の話ですか？

ということで、同じようなことを話しています。

 
MetaDriver:
Errors, Bugs, Questions"というブランチから。

設計の初期段階における典型的な問題として、プログラムのイベント処理をどのように整理（構造化）すれば、プログラム（プログラム）をさらに発展させることができ、同時に、すでに行われたことの手直しを最小限に抑えることができるかということがある。

オプションのご相談は？

これはもっとグローバルな問題で、有能なイベントモデルを編成するということだけではありません。言語そのものに依存する部分が多い。残念ながら、MQL5の言語手段は前世紀の80年代のレベルです。現代のプログラミング標準は、本来のOOPプログラミングの原則とはかけ離れている。今日では、継承よりも分解が好まれ、インターフェースレベルの水平非階層リンクによってポリモーフィズムが確保され、標準ライブラリの豊富なコレクション、分解設計、サードパーティアセンブリのプロジェクトへの透明な組み込みによってコードの再利用が保証されています。
 
C-4:
一般に、これはよりグローバルな問題であり、単に良いイベントモデルを企画すれば良いというものではありません。言語そのものに依存する部分が多い。残念ながら、MQL5の言語手段は前世紀の80年代のレベルです。現代のプログラミング標準は、本来のOOPプログラミングの原則とはかけ離れている。今日では、継承よりも分解が好まれ、インターフェースレベルの水平非階層的リンクによってポリモーフィズムが確保され、標準ライブラリの豊富なコレクション、分解設計、サードパーティビルドのプロジェクトへの透明な組み込みによってコードの再利用が保証されています。
現代性や使いやすさの面で）お手本にしたい言語はどれですか？
 
Urain:

たとえば、こんな文献はありませんか？

このテーマについて具体的に

 
Urain:
現代性や使いやすさの面で）お手本にしたい言語はどれですか？

Java/C#

これは私の偏見ではなく（偏見がないわけではありませんが）、これらの言語がプログラミング技術の長い進化の最終産物であるからです。彼らは、先人の経験をもとに、現代に生まれたのです。

 

大きなプロジェクトを 書く前に、プロジェクトをサポートするための確立されたインフラを明確に確立するのは良い考えです。

  • バックアップとセキュリティシステム。
  • バージョン管理システム。
  • プロジェクトの文書化システム（プロジェクトがセルフドキュメント化されていれば良い）。
  • 個々のモジュールとプロジェクト全体を対象としたテストシステムです。
 
Urain:

たとえば、こんな文献はありませんか？

もちろん、ありますよ。

// 文学について：文学的ソースを共有しよう。 しかし、生のコミュニケーションの方が、本（良い本でも）よりもはるかに（桁違いに）学習に有効な場合があることを忘れてはいけない。

--

一時期（90年代前半）、とても参考になった本です。

B.Liskov, J.Gatag."ソフトウェア開発における抽象化・仕様化の活用"

オブジェクト指向の要点は、プログラムを便利な「キューブ」に切り分けられることではなく、あくまで付随する利便性に過ぎない。 要は、データの抽象化 である。

サンユウク
あなたはオブジェクト指向で考え、私は機能指向で考える )
少し文章で説明させていただきます。

1. 手続き的（アルゴリズム的）抽象化は、関数型プログラミングの特徴である。 抽象化の主体は手続き（関数）である。アクションや計算を実行する要求とその実装を分離することができる。関数コードは別のブロック(手続き，関数)に分離され，このコードは形式的/実際的なパラメータの分離を介して参照されます(これが手続き的アプローチの本質であり主な特徴です)．計算や動作の方法（アルゴリズム）を変更する必要がある場合（例：ファイルへの書き込み）でも、プログラムは変更されないことが可能です。

しかし、もしプログラムが基本的なデータ構造（例えばグローバル配列）を変更する必要がある場合、このデータを扱う多くの手続きを書き換える必要が出てくるのです。-- これは手続き型プログラミングの基本的な限界です。

2) データの抽象化 - 基本的なデータ構造（およびそれに対する基本的な操作）を別の実体（「クラス」）にカプセル化する。 このとき、データ（カプセル化されたデータ）を直接参照するのではなく、そのデータ用に作成した同じクラスの関数（「インターフェース」）を介してのみ、排他的に参照するという基本ルールを守る。 これにより、データの保存形式とデータの処理方法を抽象化できるようにする。また、手続き型プログラミングでは、データの表現方法を事前に気にすることなくプログラムを開発できるという前例のない機会があります。 データは標準的な不変のインタフェースでアクセスされるので、 プロジェクト開発のどの段階でも データの表現方法を改善できますし、この変更によってプロジェクトの他の部分を変更する必要はありません。 手順型プログラミングでは、これは不可能でした。基本データ構造がその処理方法を厳密に決定していたのです。

 
sanyooooook:

プログラムを書く前に、アルゴ言語を簡略化した紙上スケッチも教わったが、慣れることはなかった。

いまや普通のプログラマーはブロックダイヤグラムを描かない。これはすべて、小学生に教えるための理論的なナンセンスであり、実際のプロジェクトで 働くためのものではありません。
 
C-4:
今どき、普通のプログラマーがフローチャートを描くことはない。それはすべて、小学生に教えるための机上の空論であり、実際のプロジェクトで働くためのものではありません。
確かにフローチャートは最悪ですが、開発には今でも紙を使い、いろんな人などを描いて、抽象的なものを視覚化しています。だから、編集者は私にとって窮屈なんです（何でも標準装備されている）。
 
Urain:

紙に描いた方が便利なので、時には50枚くらい描いて、構造をはっきりさせることもあります。もちろん、専用のエディタを使うこともできますが、私にはどれも違和感があり（限界があり）、空想の世界を実現することは不可能で、要するに作業のスピードが落ちてしまうのです。

また、プロジェクトの 途中、あるいは終了間際に、顧客が突然変わってしまったら、明確な構造はどうなるのでしょうか。

  • 当初の要求の5％。
  • 当初の要求の10％。
  • 当初の要求の25％。

これは、プロジェクトが変化に対してどれだけ準備ができているか、どれだけ回復力があるかを見るための良いテストです。実際には、常に初期要求の変更に対応しなければなりません。したがって、「Provide for everything」パラダイムから「Task - Solution」パラダイムに完全に移行することが望ましい。

12345678910...20
新しいコメント