OOPと手続き型プログラミングの比較 - ページ 41 1...343536373839404142434445464748 新しいコメント Alexey Volchanskiy 2017.08.16 07:56 #401 George Merts:渋滞の中に立っている車に近づいて、その設置の仕方を見て、運転手に「もっとカッコよく問題を混乱させる方法はないのか、100メートル先にあるんだぞ」と言うんです。私の経験上、このような「ややこしい問題」は、グローバル変数を すべて含んだ一つのテンプレートからコピーして作った「手間のかからない」EAよりもずっとわかりやすいと思うのですが、いかがでしょうか。 ジョルジュ 最近、私の古い友人に会ったんですが、彼女は会計士で、1Cを学ぼうとしているんです。2007年、彼女は飼料について考えていたのですが、その時にMQL4のことを知りました。その1Cを見て、気分が悪くなりました )) Dmitry Fedoseev 2017.08.16 07:57 #402 Реter Konow:2年間、途切れることなく働き続けた。 グラフィカルインターフェースの中核（ちなみに、プロトタイプの要素を含むプロトコアも存在する。2メガバイトを占有しています。引用したような表で構成され）、数千の変数が含まれている。カーネルを中心に、クラスや構造体に変数を分散させ、様々なアクセス制限で相互の通信を設定しなければ、私の課題に対処できたと思いますか？- 決して 自分一人の力ではありません。私のプログラムでは、エンティティの数を掛けたはずです。関数やクラスなどのコードのつながりが複雑になり、自分一人では作業が続けられなくなるのです。そうなると機構全体の効率は一気に落ちてしまいます。私ならもっと早く限界に達してやめていたでしょう。 何度も「もしOOPを使って いたらどうなっていたか」と自問し、そのたびに日々の実践を踏まえて「自分一人ではあそこまではできなかった」と実感しています。また、私の思考はすでに構造化されているので、この点ではOOPは必要ありません。記事の中にグラフィカルコントロールのライブラリがあるのですが（もちろん欠点もあります）、2週間で完成し、記事を書くのに2週間かかりました。数年後、別の記事を書くときに使いましたが、記事やコードを見ずとも、メソッドのドロップダウンリストを見れば、ほとんど瞬時にすべてが思い浮かびました。 Реter Konow 2017.08.16 08:05 #403 Dmitry Fedoseev: 私の記事にはグラフィカルコントロールのライブラリがありますが（もちろん欠点もあります）、これは2週間で作り、記事を書くのに2週間かかりました。数年後、別の記事を書くときに使いましたが、記事やコードを見ずとも、メソッドのドロップダウンリストを見れば、ほとんど瞬時にすべてが思い浮かびました。 あなたの作品をけなすつもりも、私の作品を特別視するつもりもありませんが、あなたはゾウとモジモジを比べているのです。スケールが違いますね。複雑さのレベルが違うのです。私は、ただ操作 性を重視するだけではありません。これは、独自のマークアップ言語で構築できる、全体のグラフィカルな環境なのです。しかも、オブジェクトベースではなく、ドローイングです。 Dmitry Fedoseev 2017.08.16 08:28 #404 Реter Konow: あなたの作品をけなすつもりも、私の作品を特別視するつもりもありませんが、あなたは象とモグラを比較しているのです。スケールが違いますね。複雑さのレベルが違うのです。私は、ただ操作 性を重視するだけではありません。これは、独自のマークアップ言語で構築できる、全体のグラフィカルな環境なのです。しかも、オブジェクトベースではなく、ドローイングです。しかし、2年がかりの仕事ではありません。作業量はグラフィックオブジェクトを使うのと同等ですが、もちろん適切なアプローチで。でも、2年もかけるなんて...。すみません、移動してください。キャンバスの作成を追加していますが、これは親クラスにあり、長方形を描くメソッドと、最も単純な幾何学的図形を描くメソッドをいくつか追加しています。それ以外はまったく同じです。それに、みなさんが私の作品を蔑ろにしたいのは、とっくに分かっていることですから、前置きは必要ありません。この図書館は不和の岩のようなもので、群衆をヒステリーに追い込んでいる。 Реter Konow 2017.08.16 08:36 #405 Dmitry Fedoseev: しかし、2年がかりの仕事ではありません。作業量はグラフィックオブジェクトを使うのと同等ですが、もちろん正しいアプローチで。でも、2年もかけるなんて...。すみません、移動してください。そして、みなさんが私の作品を貶めようとしていることは、とっくに理解していますので、前置きは必要ありません。この図書館は不和の岩のようなもので、群衆をヒステリーに追い込んでいる。 理由もなく人に恥をかかせるのは、私の性分ではありません。キレるなよ、わかってないだけだろ。たぶん、説明できないんです。だから、自分を「蛇のゴリ押し」）と思ってください。 Dmitry Fedoseev 2017.08.16 08:38 #406 Реter Konow: 理由もなく人に恥をかかせるのは、私の性分ではありません。そんなに自分を責めるな お前には分からないんだたぶん、説明できないと思います。だから、自分を「蛇のゴリ押し」）と思ってください。自分で考えるが、1ヶ月でできることを2年も書かない。 Реter Konow 2017.08.16 08:41 #407 Dmitry Fedoseev: 自分で考えるが、1ヶ月でできることを2年も書かない。 だからやれよ、何が問題なんだ？ Dmitry Fedoseev 2017.08.16 08:42 #408 Реter Konow: だからやれよ、何が問題なんだ？ 必要ない СанСаныч Фоменко 2017.08.16 09:59 #409 George Merts:あそこのSanSanychは、OOPをドキュメントに置き換えることを提案しています。あなたが言い出したんでしょう......私は提案していませんよ。私の実践からToRは400ページを優に超える文書である。ToRのレビューと承認続いて、技術プロジェクト。この資料は、40〜50人で作成したものです。職業は、経済学者、数学者、アルゴリズム開発者、シスアド、エレクトロニクスエンジニアなどさまざまである。続いてワーキングドラフト。ここで、プログラムと機能の内訳が表示されます。実際にコーディングやデバッグを行う。開発者、CPUの異なるユーザー、アプリケーションの異なるユーザー（管理職、中間管理職、派遣社員など）向けのドキュメントが作成されます。さらに、試運転もあります。主な指標は平均故障間隔です。もし、すべてが適切に行われ、文書化され、原始的なコーディングの原則が考慮されていれば、次のエラー捕捉から故障までの時間は指数関数的に 減少するはずです。もし、リニアであれば、全く動作しないことはないでしょう。ここでいうOOPとは、どこのことでしょうか？OOPは開発時の企業要件であり、最終的な成果にはほとんど影響しないが、一人の人間がプロジェクト全体のクラスを開発すれば、何も混ざらないし、クラスもプロジェクトの最終目的から自然になるし、非常に有用である（ように私には思える）......ということだ。 Vladimir Karputov 2017.08.16 15:32 #410 スレッドの話題から逸脱しないようにお願いします。 1...343536373839404142434445464748 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
渋滞の中に立っている車に近づいて、その設置の仕方を見て、運転手に「もっとカッコよく問題を混乱させる方法はないのか、100メートル先にあるんだぞ」と言うんです。
私の経験上、このような「ややこしい問題」は、グローバル変数を すべて含んだ一つのテンプレートからコピーして作った「手間のかからない」EAよりもずっとわかりやすいと思うのですが、いかがでしょうか。
ジョルジュ 最近、私の古い友人に会ったんですが、彼女は会計士で、1Cを学ぼうとしているんです。2007年、彼女は飼料について考えていたのですが、その時にMQL4のことを知りました。
その1Cを見て、気分が悪くなりました ))
2年間、途切れることなく働き続けた。
グラフィカルインターフェースの中核（ちなみに、プロトタイプの要素を含むプロトコアも存在する。2メガバイトを占有しています。引用したような表で構成され）、数千の変数が含まれている。カーネルを中心に、クラスや構造体に変数を分散させ、様々なアクセス制限で相互の通信を設定しなければ、私の課題に対処できたと思いますか？- 決して 自分一人の力ではありません。私のプログラムでは、エンティティの数を掛けたはずです。関数やクラスなどのコードのつながりが複雑になり、自分一人では作業が続けられなくなるのです。そうなると機構全体の効率は一気に落ちてしまいます。
私ならもっと早く限界に達してやめていたでしょう。
何度も「もしOOPを使って いたらどうなっていたか」と自問し、そのたびに日々の実践を踏まえて「自分一人ではあそこまではできなかった」と実感しています。
また、私の思考はすでに構造化されているので、この点ではOOPは必要ありません。
記事の中にグラフィカルコントロールのライブラリがあるのですが（もちろん欠点もあります）、2週間で完成し、記事を書くのに2週間かかりました。数年後、別の記事を書くときに使いましたが、記事やコードを見ずとも、メソッドのドロップダウンリストを見れば、ほとんど瞬時にすべてが思い浮かびました。
私の記事にはグラフィカルコントロールのライブラリがありますが（もちろん欠点もあります）、これは2週間で作り、記事を書くのに2週間かかりました。数年後、別の記事を書くときに使いましたが、記事やコードを見ずとも、メソッドのドロップダウンリストを見れば、ほとんど瞬時にすべてが思い浮かびました。
あなたの作品をけなすつもりも、私の作品を特別視するつもりもありませんが、あなたは象とモグラを比較しているのです。スケールが違いますね。複雑さのレベルが違うのです。私は、ただ操作 性を重視するだけではありません。これは、独自のマークアップ言語で構築できる、全体のグラフィカルな環境なのです。しかも、オブジェクトベースではなく、ドローイングです。
しかし、2年がかりの仕事ではありません。作業量はグラフィックオブジェクトを使うのと同等ですが、もちろん適切なアプローチで。でも、2年もかけるなんて...。すみません、移動してください。
キャンバスの作成を追加していますが、これは親クラスにあり、長方形を描くメソッドと、最も単純な幾何学的図形を描くメソッドをいくつか追加しています。それ以外はまったく同じです。
それに、みなさんが私の作品を蔑ろにしたいのは、とっくに分かっていることですから、前置きは必要ありません。この図書館は不和の岩のようなもので、群衆をヒステリーに追い込んでいる。
しかし、2年がかりの仕事ではありません。作業量はグラフィックオブジェクトを使うのと同等ですが、もちろん正しいアプローチで。でも、2年もかけるなんて...。すみません、移動してください。
そして、みなさんが私の作品を貶めようとしていることは、とっくに理解していますので、前置きは必要ありません。この図書館は不和の岩のようなもので、群衆をヒステリーに追い込んでいる。
理由もなく人に恥をかかせるのは、私の性分ではありません。そんなに自分を責めるな お前には分からないんだたぶん、説明できないと思います。だから、自分を「蛇のゴリ押し」）と思ってください。
自分で考えるが、1ヶ月でできることを2年も書かない。
自分で考えるが、1ヶ月でできることを2年も書かない。
だからやれよ、何が問題なんだ？
あそこのSanSanychは、OOPをドキュメントに置き換えることを提案しています。
あなたが言い出したんでしょう......私は提案していませんよ。
私の実践から
ここでいうOOPとは、どこのことでしょうか？OOPは開発時の企業要件であり、最終的な成果にはほとんど影響しないが、一人の人間がプロジェクト全体のクラスを開発すれば、何も混ざらないし、クラスもプロジェクトの最終目的から自然になるし、非常に有用である（ように私には思える）......ということだ。