OOPと手続き型プログラミングの比較 - ページ 39

新しいコメント
 
Andrei:

このクラスは内部変数しか持たず、入出力はありません...。外界と一切接触せず、自分の汁で沸騰するような物体を、プログラミングに使うということをどこで見たことがありますか？


なんで見てないのに議論してんの？クラスのコンストラクタが 作成され、任意の数のパラメータを取得することができます。子クラスによって、コンストラクタに指定するパラメータは全く異なるものになる可能性があります。パラメータを設定するメソッドを書けばいいのです。

 
СанСаныч Фоменко:

1.これが、OOPの必要性に対する主な答えです。

2.チームでの経験の問題である。必要なものはすべて書きました。数年前、私はもう少し書いてみようと思いました。すべてが読み込まれ、問題はありません。


回答から一つ理解できたのは、OOPはプログラミングの規律を導入し、統一性を持たせ、その上で、当初はエラーが少なく、最も重要な、修正時の問題も本質的に少なくなる一定の基準であるということです。しかし、GOST、開発段階、ドキュメントを注意深く観察しても、同じ結果が得られたのです。


何回同じことを言わせるんだ？OOPはコードを構造化 する手段であるだけでなく、手続き型プログラミングにはない仕組みも含んでいます。

山を見ていない人が、「これは何だ」と言ってもわからないということなのでしょう。

 
Реter Konow:

私自身は、ソリューションの汎用性にこだわっています。そのためには、コード量を増やさずに、似たような機能を一つのブロックに「継ぎ足し」ていくことが必要です。これにより、機構の効率が上がり、過負荷や分割が不要になります。ちょっと頭を使えばいいんですよ（笑）。

つまり、20行ずつの関数が2つあったのです。どちらも似たような動作をしたり、似たような課題を解決したりします。私の目標は、20行以下のコードで、この2つの仕事をする1つの関数を作ることです。こうしてブロックを作っています。


いつからこのライブラリーに目を通すようになったのですか？

 

嬉しさのあまり、Rは「アクセスの区別がないオールインワンのゴミ箱」モードで書かれているのが、なんとも嫌らしい。20年前の古い手法で、可視化、保護、マルチセッションの領域がない。まるで自分だけがそうであるかのように書いています。そう、このプロジェクトは、プロではない開発者が一人の下で誕生させたものなのです。一から書き直さなければならない。少なくとも一度は。

MQL5からRで普通のインターフェースを作るというアイデアもあったのですが、深く掘り下げると、統合しないことを即決しました。データやセッションを保護することは、断固としてできない。

プログラマーは、要求の厳しい通常の開発チームで働くまで（少なくとも2〜3年は手を叩いて）、通常の意味での開発者にはなれない。候補者を検討する際にテストジョブを見るとき、私たちは90％の確率で頭をつかいます。開発業界全体のトータルホラー

だから、またしても、OOP反対派は、ある種のバカ騒ぎをしているのです。

またまたすみません。

 
СанСаныч Фоменко:

すげえええええええええええええええええええええええ

私が疑問に思ったのは、今のプログラミングで、卵レベルの問題を冷静に混乱させる方法は他にないのだろうか、ということです。

渋滞の中に立っている車に近づいて、その設置の仕方を見て、運転手に「もっと問題を混乱させる方法はないのか、ここを100メートル歩いてみろ」と言うのです。

私の経験上、このような「わかりにくい問題」は、グローバル変数を すべて含んだ一つのテンプレートからコピーして作った「問題のない」EAよりもずっとわかりやすいと思います。

 
Dmitry Fedoseev:

そして、なぜ見てもいないことをここで憶測しているのですか？クラスのコンストラクタが 作成され、任意の数のパラメータを取得することができます。

よく読むと、クラスのコンストラクタではなく、クラスについての話でした。

さらに、外部変数の場合は何もせずにパラメータにアクセスできたり、コンストラクタやデストラクタ、それに付随するすべてのメモリリークに頭を悩ませることなくパラメータを直接渡せるのに、またしても猿芝居をするようなことを言うのですね。

 
СанСаныч Фоменко:

私のOnInit()もほぼ同じで、十数行 です...

それで？

理由としては、私のEAではすべて10行（インクルードやコメントを含めない場合）あります。 

#include <MyLib\DebugOrRelease\DebugSupport.mqh>
#include <MyLib\Factories\ForTrade\EURGBP\B1H2C20T2_0001_EPF.mq5>
#include <MyLib\Factories\ForTrade\EURGBP\B2H2C20T4_0001_EPF.mq5>
#include <MyLib\Factories\ForTrade\EURGBP\B3H2C20T2_0001_EPF.mq5>

// Объявляем фабрики частей эксперта.
CB1H2C20T2_0001_EPF epfFact_0;
CB2H2C20T4_0001_EPF epfFact_1;
CB3H2C20T2_0001_EPF epfFact_2;

// Объявляем функцию получения указателя на фабрику.
CEAPartsFactoryT* CEAPartsFactoryT::GetAdvisorsPartsFactory(uint uiFactIdx = 0)
{
   if(uiFactIdx == 0) return(GetPointer(epfFact_0)); 
   if(uiFactIdx == 1) return(GetPointer(epfFact_1)); 
   if(uiFactIdx == 2) return(GetPointer(epfFact_2)); 
   return(NULL); 
};

#include <MyLib\TSTemplate\ExpertAdvisorT.mq5>

今回のケースでは、1つのEAに3つの全く異なるTSが存在します。それぞれが干渉することなく、同時に動作します。

適切なファクトリーを宣言し、それを返すコードを関数に追加することで、TCを追加することができる。

しかし、本当の問題は、コード行数が少ないか多すぎるかではない。問題は、メンテナンスと必要な改造がどれだけ容易かです。

SanSanych、Peterから提供されたテーブルファイルを簡単に把握することができますか？そして、簡単に改造できる？それなら、ピーターと同じように、OOPは必要ないですね。

 
Реter Konow:
OOPは、機構の一部を分離し、包み込み、隠すための手法である。これが必要かどうかは、開発者の判断に委ねられます。仕組みを効率化することとは全く関係ない。考え方の構造化ですね。正しく構成されているかは不明です。それが必要かどうかは、人それぞれだと思います。

その通りです。これがカプセル化の本質です。

また、継承やポリモーフィズムも ある。

 
Реter Konow:
OOPは、機構の一部を分離し、包み込み、隠蔽する手法である。それが必要なのかどうかは、人それぞれです。

その通り、個人差はありますね。統合失調症でもないプログラマーが、なぜ自分でデバッグしているコードの一部へのアクセスを必死に隠すのだろうか。自分の手を縛る方がいいのでは？:)

 
Renat Fatkhullin:

プログラマーは、通常の開発チームで厳しい条件を満たす仕事をする（最低でも2〜3年は手を動かす）までは、通常の意味でのデベロッパーにはなれません。候補者を検討する際にテストジョブを見るとき、私たちは90％の確率で頭をつかいます。開発業界全体のトータルホラー

この「おそろしさ」は何に現れるのだろう。

なぜなら、手続き型プログラミングでは、アルゴリズムが働くロジックに主眼が置かれ、OOP 的な外部アドオンには注意を払わないため、どんな難解な森でも簡単に構築できてしまうからです。

1...323334353637383940414243444546...48
新しいコメント
理由: