OOPと手続き型プログラミングの比較 - ページ 36 1...293031323334353637383940414243...48 新しいコメント СанСаныч Фоменко 2017.08.15 17:42 #351 George Merts:1.どこまでも、です。収益性はAOPに依存しない。2.私見では、一桁（10倍）違う。しかし、OOPから得られる主なものは、コードサポートにあります。今は、1年以上前に書いたコードをすぐに確認することができます。私は、初期のANSI Cのプログラムを純粋に手続き型で理解したことをよく覚えています。もっと大変でした。 1.これが、OOPの必要性に対する主な答えです。2.チームでの経験の問題である。必要なものはすべて書きました。数年前、私はもう少し書いてみようと思いました。すべてが読み込まれ、問題はありません。回答から一つ理解できたのは、OOPはプログラミングの規律を導入し、統一性を持たせ、その上で、当初はエラーが少なく、最も重要な、修正時の問題も本質的に少なくなる一定の基準であるということです。しかし、GOST、開発段階、文書化可能性を注意深く観察しても、同じ結果が得られました。 Georgiy Merts 2017.08.15 17:45 #352 СанСаныч Фоменко: なぜ、今までこのようなことに遭遇しなかったのか、理解できない。なぜ、それほど大きくない1つのプログラムで、ONEデベロッパーのアクセス差別化が可変になるという問題が発生するのでしょうか？100人の開発者がいて、それぞれが100の機能を書いている。理論的には、発明できるかもしれません。しかし、実質的には、プログラミングは40年近く前からOOPに進化し、山のようにコードが書かれてきましたが、そんな話は聞いたことがありません。まあ、最初のころはプログラムはまったくコードで書かれていなかったんですけどね。 OOPは、より複雑なプログラムをより速く書き、そしてより効率的に保守するための技術に過ぎません。 しかし、OOPが万能の解決策であるということではありません。Peterのようにメモリがあれば、OOPはまったく必要ありません。すべてをグローバルに宣言すればそれで終わりですから、すべてを記憶し、変数の衝突や混在を簡単に避けることができます。でも、記憶力はもっと悪いんですよ。そして、デリミテーション......非常によく使いますね。この数年、私は修飾子constがとても気に入っています - 以前はめったに使いませんでした。今ではとてもよく使っています。ただ、必要なものだけにアクセスでき、それ以上はない。このアクセスは、変更を意図しない場所では読み取り専用になるように。 Andrei01 2017.08.15 17:49 #353 George Merts:たしかに、突然、必要なデータがほとんど取れないことが判明する場面はありますね。それらは、いくつかの仮想インターフェースの背後に隠されています。しかし、この状況は、もともとシステムの設計が正しくなかったこと、このデータの転送を想定していなかったことを明確に示しています。この状況は実に不愉快です。急遽、インターフェイスを追加する形で「松葉杖」を作るか、システム全体を再構築するか、どちらかです。 さて...。プログラマがシステムアーキテクチャをより慎重に考える動機付けとなる。もしプログラマーが予言者であり千里眼であり、メインアイデアのあらゆる可能なバリエーションに必要なデータ 構造の詳細を先読みしているならば、おそらくあなたのやり方で行動することに意味があるのでしょう。あるいは、最終段階で、これらのアドオンを使用せずに、すべてがすでに動作し、コードがデバッグされているときに、それを行うか。 Georgiy Merts 2017.08.15 17:49 #354 СанСаныч Фоменко: 1.これが、OOPの必要性に対する主な答えです。2.チームでの経験の問題である。必要なものはすべて書きました。数年前、私はもう少し書いてみようと思いました。すべてが読み込まれ、問題はありません。OOPは、プログラミングの規律を導入し、統一性を持たせ、その上で、初期のエラーを少なくし、何よりも修正時の問題を根本的に減らす、ある種のスタンダードであることが、ご回答からよくわかりました。しかし、GOST、開発段階、文書化可能性を注意深く観察しても、同じ結果が得られました。1.いいえ。OOPは収益性を確保するためのツールではありません。また、採算性を見ながらOOPの必要性を語ることはできません。OOPは、コードの開発と保守を簡素化するためのツールです。 2.10年前のTCがまだ使えるとカッコいい。このままではいけないと、定期的に使えなくなり、常に修正しなければならないのです。そして、OOPはその点で私にとって大きな助けとなっています。 そして、OOPについてですが、いくつかの標準的なものは、そうですね、すべて正しいです。そして、それをずらして文書化すれば、同じ結果が得られることも事実です。しかし、OOPの場合よりも手間がかかるような気がします。 СанСаныч Фоменко 2017.08.15 17:49 #355 George Merts:当初は、プログラムはコードで書かれていた。 OOPとは、簡単に言えば、より複雑なプログラムをより速く書き、そしてより効率的にメンテナンスするための技術です。 しかし、だからといって、OOPが万能というわけではありません。Peterのようにメモリがあれば、OOPはまったく必要ありません。すべてをグローバルに宣言してしまえば、すべてを記憶しているので、変数の衝突や混在を簡単に避けることができます。でも、記憶力はもっと悪いんですよ。そして、デリミテーション......非常によく使いますね。この数年、私は修飾子constがとても気に入っています - 以前はめったに使いませんでした。今ではとてもよく使っています。ただ、必要なものだけにアクセスし、それ以上アクセスできないようにするためです。そのため、このアクセスは、変更を意図しない場所では読み取り専用となる。当初は、プログラムはコードで書かれていた。物事を捻じ曲げるのはやめましょうね。OOPとは、簡単に言えば、より複雑なプログラムをより速く書き、そしてより効率的にメンテナンスするための技術である。それは疑問だし、非常に疑問だ。より高速なプログラムが作成され、優れた設計文書により効率的に保守されます。この問題の反響は、TORに 大きな注目が集まっている市場にも見られる。TORがお粗末だと、どんなOOPも役に立ちません。 Ihor Herasko 2017.08.15 17:51 #356 СанСаныч Фоменко:優れたプロジェクト文書があるプログラムは、より迅速かつ効率的に文書化され、維持されます。この問題の反響は、TORに大きな注目が集まっている市場にも見られる。TORがお粗末だと、どんなOOPも役に立ちません。 要は、プログラムドキュメントとTORは別物だということです。この2つを混同するのはとても不思議なことです。最近のプログラムでは、実質的にドキュメントは不要で、すべてクラスのインターフェイスで示されます。 Georgiy Merts 2017.08.15 17:53 #357 Andrei:もしプログラマーが予言者で千里眼の持ち主で、メインアイデアの実装のあらゆる可能なバリエーションに必要なデータ 構造を先回りして細部まで見通しているなら、おそらくあなたのやり方で行動するのが理にかなっています。あるいは、最終段階で、これらのアドオンを使用せずに、すべてがすでに動作し、コードがデバッグされているときに、それを行うか。 まあ、インターフェイスで重要な情報を受け渡す可能性があることを予見していなかったという状況は、ほとんどないのですが。しかし、もうひとつ、私にとってより重要なことがあります。それは、上記のIgorが正しく述べているように、各クラスはそれ自身の変数にのみ責任があり、他のクラスに「干渉」することは不可能だということです。その結果、ほとんどの問題がコンパイル段階でカットされてしまうのです。 Andrei01 2017.08.15 17:55 #358 George Merts:OOPは、より複雑なプログラムをより速く書き、より効率的に保守するための技術に過ぎない。 以上のように、OOPはアドオンラッパーや中間上部構造、アダプターが多いため、本来、高速なコード記述やデバッグを目的としたものではありません...。最終的には、すべてが動作し、デバッグされ、データ構造が 最終形を獲得した段階で初めて意味があるのです......。つまり、その後の保管のためにレディコードを梱包する、純粋に美容のための手順です...。 Andrei01 2017.08.15 18:02 #359 George Merts: 各クラスはそれ自身の変数にのみ責任があり、そこから他の人の変数に「入る」ことは不可能なのです。その結果、ほとんどの問題がコンパイルの段階で切り捨てられることになります。クラスは内部変数しか持たず、入出力変数を持たない...。外界との接触がなく、自分の汁で沸騰するような物体を、プログラミングに使うというのは、どこで見たことがあるのでしょうか。 СанСаныч Фоменко 2017.08.15 18:08 #360 Ihor Herasko:....最近のプログラムでは、実質的にドキュメントは必要ありません。すべてクラスのインターフェイスで手のひらの上にあります。なぜ、端末や言語、そして一般的に、Cp...などのソフトウェア製品に膨大なマニュアルを書いたのだろうか？実際、ドキュメントのないソフトウェア製品はあるのだろうか？それがわからないのは不思議です。 1...293031323334353637383940414243...48 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
1.どこまでも、です。収益性はAOPに依存しない。
2.私見では、一桁（10倍）違う。しかし、OOPから得られる主なものは、コードサポートにあります。今は、1年以上前に書いたコードをすぐに確認することができます。私は、初期のANSI Cのプログラムを純粋に手続き型で理解したことをよく覚えています。もっと大変でした。
1.これが、OOPの必要性に対する主な答えです。
2.チームでの経験の問題である。必要なものはすべて書きました。数年前、私はもう少し書いてみようと思いました。すべてが読み込まれ、問題はありません。
回答から一つ理解できたのは、OOPはプログラミングの規律を導入し、統一性を持たせ、その上で、当初はエラーが少なく、最も重要な、修正時の問題も本質的に少なくなる一定の基準であるということです。しかし、GOST、開発段階、文書化可能性を注意深く観察しても、同じ結果が得られました。
なぜ、今までこのようなことに遭遇しなかったのか、理解できない。なぜ、それほど大きくない1つのプログラムで、ONEデベロッパーのアクセス差別化が可変になるという問題が発生するのでしょうか？100人の開発者がいて、それぞれが100の機能を書いている。理論的には、発明できるかもしれません。しかし、実質的には、プログラミングは40年近く前からOOPに進化し、山のようにコードが書かれてきましたが、そんな話は聞いたことがありません。
まあ、最初のころはプログラムはまったくコードで書かれていなかったんですけどね。
OOPは、より複雑なプログラムをより速く書き、そしてより効率的に保守するための技術に過ぎません。
しかし、OOPが万能の解決策であるということではありません。Peterのようにメモリがあれば、OOPはまったく必要ありません。すべてをグローバルに宣言すればそれで終わりですから、すべてを記憶し、変数の衝突や混在を簡単に避けることができます。でも、記憶力はもっと悪いんですよ。そして、デリミテーション......非常によく使いますね。この数年、私は修飾子constがとても気に入っています - 以前はめったに使いませんでした。今ではとてもよく使っています。ただ、必要なものだけにアクセスでき、それ以上はない。このアクセスは、変更を意図しない場所では読み取り専用になるように。
George Merts:
たしかに、突然、必要なデータがほとんど取れないことが判明する場面はありますね。それらは、いくつかの仮想インターフェースの背後に隠されています。しかし、この状況は、もともとシステムの設計が正しくなかったこと、このデータの転送を想定していなかったことを明確に示しています。この状況は実に不愉快です。急遽、インターフェイスを追加する形で「松葉杖」を作るか、システム全体を再構築するか、どちらかです。 さて...。プログラマがシステムアーキテクチャをより慎重に考える動機付けとなる。
もしプログラマーが予言者であり千里眼であり、メインアイデアのあらゆる可能なバリエーションに必要なデータ 構造の詳細を先読みしているならば、おそらくあなたのやり方で行動することに意味があるのでしょう。あるいは、最終段階で、これらのアドオンを使用せずに、すべてがすでに動作し、コードがデバッグされているときに、それを行うか。
1.これが、OOPの必要性に対する主な答えです。
2.チームでの経験の問題である。必要なものはすべて書きました。数年前、私はもう少し書いてみようと思いました。すべてが読み込まれ、問題はありません。
OOPは、プログラミングの規律を導入し、統一性を持たせ、その上で、初期のエラーを少なくし、何よりも修正時の問題を根本的に減らす、ある種のスタンダードであることが、ご回答からよくわかりました。しかし、GOST、開発段階、文書化可能性を注意深く観察しても、同じ結果が得られました。
1.いいえ。OOPは収益性を確保するためのツールではありません。また、採算性を見ながらOOPの必要性を語ることはできません。OOPは、コードの開発と保守を簡素化するためのツールです。
2.10年前のTCがまだ使えるとカッコいい。このままではいけないと、定期的に使えなくなり、常に修正しなければならないのです。そして、OOPはその点で私にとって大きな助けとなっています。
そして、OOPについてですが、いくつかの標準的なものは、そうですね、すべて正しいです。そして、それをずらして文書化すれば、同じ結果が得られることも事実です。しかし、OOPの場合よりも手間がかかるような気がします。
当初は、プログラムはコードで書かれていた。
OOPとは、簡単に言えば、より複雑なプログラムをより速く書き、そしてより効率的にメンテナンスするための技術です。
しかし、だからといって、OOPが万能というわけではありません。Peterのようにメモリがあれば、OOPはまったく必要ありません。すべてをグローバルに宣言してしまえば、すべてを記憶しているので、変数の衝突や混在を簡単に避けることができます。でも、記憶力はもっと悪いんですよ。そして、デリミテーション......非常によく使いますね。この数年、私は修飾子constがとても気に入っています - 以前はめったに使いませんでした。今ではとてもよく使っています。ただ、必要なものだけにアクセスし、それ以上アクセスできないようにするためです。そのため、このアクセスは、変更を意図しない場所では読み取り専用となる。
当初は、プログラムはコードで書かれていた。
物事を捻じ曲げるのはやめましょうね。
OOPとは、簡単に言えば、より複雑なプログラムをより速く書き、そしてより効率的にメンテナンスするための技術である。
それは疑問だし、非常に疑問だ。
より高速なプログラムが作成され、優れた設計文書により効率的に保守されます。この問題の反響は、TORに 大きな注目が集まっている市場にも見られる。TORがお粗末だと、どんなOOPも役に立ちません。
優れたプロジェクト文書があるプログラムは、より迅速かつ効率的に文書化され、維持されます。この問題の反響は、TORに大きな注目が集まっている市場にも見られる。TORがお粗末だと、どんなOOPも役に立ちません。
もしプログラマーが予言者で千里眼の持ち主で、メインアイデアの実装のあらゆる可能なバリエーションに必要なデータ 構造を先回りして細部まで見通しているなら、おそらくあなたのやり方で行動するのが理にかなっています。あるいは、最終段階で、これらのアドオンを使用せずに、すべてがすでに動作し、コードがデバッグされているときに、それを行うか。
OOPは、より複雑なプログラムをより速く書き、より効率的に保守するための技術に過ぎない。
以上のように、OOPはアドオンラッパーや中間上部構造、アダプターが多いため、本来、高速なコード記述やデバッグを目的としたものではありません...。最終的には、すべてが動作し、デバッグされ、データ構造が 最終形を獲得した段階で初めて意味があるのです......。つまり、その後の保管のためにレディコードを梱包する、純粋に美容のための手順です...。
各クラスはそれ自身の変数にのみ責任があり、そこから他の人の変数に「入る」ことは不可能なのです。その結果、ほとんどの問題がコンパイルの段階で切り捨てられることになります。
クラスは内部変数しか持たず、入出力変数を持たない...。外界との接触がなく、自分の汁で沸騰するような物体を、プログラミングに使うというのは、どこで見たことがあるのでしょうか。
....最近のプログラムでは、実質的にドキュメントは必要ありません。すべてクラスのインターフェイスで手のひらの上にあります。
なぜ、端末や言語、そして一般的に、Cp...などのソフトウェア製品に膨大なマニュアルを書いたのだろうか？実際、ドキュメントのないソフトウェア製品はあるのだろうか？それがわからないのは不思議です。