OOPと手続き型プログラミングの比較 - ページ 13 1...67891011121314151617181920...48 新しいコメント Реter Konow 2017.08.12 19:55 #121 Alexey Navoykov:ソリューションの効率化とはどういうことですか？ソリューションの効率とは、メカニズム（ソフトウェアも間違いなくメカニズムです）が最も安定的に機能するようなソリューションの質を意味します。その仕組みは、明確で一貫性があり、生産性の高いものでなければなりません。エンジンの機能は、割り当てられたすべてのタスクを実行する必要があります。この機構は余計なものを受け付けないし、この機構の開発においては、余計なものは切り捨てるべき。 そうでなければ、発展は望めないし、効率も悪くなる。 これはあくまでも私の意見であり、誰かに押し付けるものではありません。 Реter Konow 2017.08.12 19:59 #122 Комбинатор:私はOOPが好きではありません。しかし、保守性、拡張性、サードパーティーの使い勝手という点では、TC（カルプトフではなくピーター）が推すものは石器時代としか言いようがないのです。私は、プログラマーは 4人以上のチームで仕事をするのが理想だと考えています。 なぜ、「良い」けれども必ずしも効率的ではないコードが必要なのでしょうか？プログラミングは「詩」ではないし、「芸術」の価値もゼロだ。機構は、美しさではなく、効率で評価される。コードは仕組みです。 Nikolay Ivanov 2017.08.12 20:21 #123 Реter Konow:ここで大合唱するつもりはありませんが、OOPの支持者は、OOPなしの解決策よりもこの解決策がより効率的であることが明確にわかる、問題を解決するコードを提出できないでしょうか？私はOOPなしで問題を解決する達人であり、OOPで問題を解決する達人と戦いたいと思っています。あなたがやり手で、いつも仕事をくれるお客さんがいるとします。そして、5〜6回目の指令で、彼の仕事はどれもどこか似ていることに気づく......。そして、それらを組み合わせてパターンを作ることができると...。そして、お客様もこのテンプレート同士を大量に組み合わせるのがお好きなようで・・・。そして、クライアントから再び難しい仕事を依頼されたら、このテンプレート（クラス）のインスタンスを必要な数（例えば10個）作成し、それぞれにクライアントに発生したプロパティを（コンストラクタで）設定すればよいのです......。結局、注文を出すかどうかの判断は、10個のインスタンスのそれぞれで結果を見るというループで済んでしまう...。そんな注文を5分でリベット留めして...。でも、OOPがないとインスタンスは作れないし、今あるものが壊れないことを祈りながら、ほとんどすべてをやり直さなければならない...その結果、多くの時間を費やすことになる...」。結論：OOPを知っているプログラマーは、（OOPに適した）問題をより速く、より少ないミスで解決することができる...。 Реter Konow 2017.08.12 20:28 #124 Nikolay Ivanov:説明しますと、例えば、あなたが演奏家で、いつも仕事をくれるお客さんがいるとします...。そして、5、6回目のオーダーで、彼の仕事がある意味同じであることに気づくのです...。そして、それらを組み合わせてパターンを作ることができると...。そして、お客様もこのテンプレート同士を大量に組み合わせるのがお好きなようで・・・。そして、クライアントから再び難しい仕事を依頼されたら、このテンプレート（クラス）のインスタンスを必要な数（例えば10個）作り、それぞれにクライアントの頭に浮かんだプロパティを（コンストラクタに）設定すればよいのです......。結局、注文を出すかどうかの判断は、10個のインスタンスのそれぞれで結果を見るというループを踏むだけで、それだけなのですが......。そんな注文を5分でリベット留めして...。でも、OOPがないとインスタンスは作れないし、今あるものが壊れないことを祈りながら、ほとんどすべてをやり直さなければならない...その結果、多くの時間を費やすことになる...」。結論：OOPに熟達したプログラマーは、（OOPに適した）問題をより速く、より少ないミスで解決することができる...。その通りかもしれません。オーダーをやった ことがないので、お客さんが何を求めているのかわからない。ルーティンワークのように見えますが、私がここで言っているのは開発なのです。おそらく、ルーチンワーク（これもチームで行う）には、OOPはかけがえのないものでしょう。私はそのような経験がなく、単に知らないだけです。 そして、これらのシングルタイプのタスクのうち、OOPを使わない方が良いという具体的な例を挙げてください。 Alexey Volchanskiy 2017.08.12 20:29 #125 Комбинатор:私はOOPが好きではありません。しかし、保守性、拡張性、サードパーティーの使い勝手という点では、TC（カルプトフではなくピーター）が推すものは石器時代としか言いようがないのです。私は、すべての プログラマーは、理想的には4人以上のチームで仕事をしなければならないと固く信じています。ただ、コードの効率や汎用性が良いということは、コードが良いということではないことを理解するためです。あ、チームでの仕事は別歌です！（笑）。そして、プログラマーのチームを率いることは、参加者の数と同程度の歌になるのです。ある土曜日の夜の話です。昔、うちの会社が鉄の世界に浸かっていた頃の話。もし繰り返しになるようでしたら、申し訳ございませんが、すでに少し前の話になだれ込んでいるかもしれません。上司に呼び出され、「仕事が忙しすぎるんじゃないか？と言ったら、「そうでもない」と言われました。-ところで、これからどうするんだ？欠勤が続くなど、個人的なスケジュールを自分で立ててしまうので、課長は私の仕事ぶりを知らないのです）。私は、「ああ、うちの機器のテストパッケージを書いてるところだよ」と言いました。チーフは「素晴らしい、シベリアで試すのにちょうどいい」と大喜びだった。アレクセイ、私たちは上空を飛ぶ必要がある。彼らはそこで立ち往生している、彼らはそれを理解することはできません。出張は大好きで、完全に自由でした。クラスノヤルスクに飛ぶと、部下が出迎えてくれて、みんな後ろめたそうな顔をしている。カフェに行って、お酒を飲んで、話をした。どうしたんですかと聞いたら課長は困惑していましたね、3カ月も出張していたのに、ある地点で立ち往生していたんですね。振り込みの時間しかないそうです。まあ、表に出ているんですけどね。車でシベリアの村に行き、宿屋に泊まると、そこに若い姉妹が2人いた。だから、誰も怒らないように、愛を紡ぎ、仲間を巻き込んでいったのです。あなたを警察に突き出さないって言ったのよ、私も同じだから。でも、この調子でやっていかないと。花輪を全部調整しよう、残りはデタラメで500マイルだ、そしたらボーナスを出す、ボスの金を絞る、お前とこの仲間で新年を祝おう、いいな？今なら女性は怒り狂うだろうが、レカは「妻が出産すればいい、私はしばらくここにいたい」と真っ先に同意したのだ。みんな結婚しているのに、なぜか誰も帰りたがらない（笑)。一方で、若くて美しいシベリアの女の子たちが待っていると、男たちがどれだけ頑張れるか、直感で理解できた（笑)。 Alexey Oreshkin 2017.08.12 20:29 #126 これはまったく論外です。 どんなタスクも、OOPがあってもなくても解決できる。また、OOPでなければ、何度も使うような統一された関数を簡単に作ることができ、プログラムを変更しても、プログラム全体が壊れることはない。OOPでは少しコードが多くなります。OOPを 使うと可読性が良くなるのですか？ わかりません。 私は、各クラスを別のファイルに保存し、各関数も別のファイルに保存しています。ただ、習慣と利便性の問題です。 Nikolay Ivanov 2017.08.12 20:31 #127 もうひとつ、最もシンプルな例として、ごく表面にあるのは......。MetaEditorのEAジェネレータ...プログラミングができなくても、膨大な数のインジケータとコンディションを含むEAを10秒で組み立てることができる )))そして、これらはすべてOOPである )) Dmitry Fedoseev 2017.08.12 20:37 #128 Alexey Oreshkin:議論することはまったくない。 どんなタスクも、OOPがあってもなくても解決できる。また、何度も使うような統一的な関数をOOPなしで簡単に作ることができ、プログラム全体に変更を加えても壊れることはありません。OOPでは少しコードが多くなります。OOPを 使うと可読性が良くなるのですか？ わかりません。 私は、各クラスを別のファイルに保存し、各関数も別のファイルに保存しています。ただ、習慣と利便性の問題です。このスレッドでは、OOPでなくても解決できる問題の例がありましたが、非常に非合理的な方法で解決しています。 Реter Konow 2017.08.12 20:38 #129 Alexey Oreshkin:これはまったく論外です。 どんなタスクも、OOPがあってもなくても解決できる。また、OOPでなければ、何度も使うような統一された関数を簡単に作ることができ、プログラムを変更しても、プログラム全体が壊れることはない。OOPでは少しコードが多くなります。OOPを 使うと可読性が良くなるのですか？ わかりません。 私は、各クラスを別のファイルに保存し、各関数も別のファイルに保存しています。ただ、習慣と利便性の問題です。 個人的な開発ではOOPは必要ないと断言できますが、大きなプロジェクトでのチームワークはどうでしょう。異なるプログラマーが作成したコードを開発し、リンクさせるということは、これまで思いつかなかったし、自分なりにどのように実装すればいいのか分からない。これが、私が現在受け入れている、開発におけるOOPの唯一の主張です。 Dmitry Fedoseev 2017.08.12 20:39 #130 Реter Konow: 個人的な開発ではOOPは必要ないと断言できるのですが、大きなプロジェクトでのチームワークについては自信がありません。異なるプログラマーが作成したコードの開発やコミュニケーションは、これまで思いつかなかったし、自分なりにどう実装すればいいのか分からない。これが、私が現在受け入れている、開発におけるOOPの唯一の主張です。これは本論ではありません。手続き型プログラミングには、ポリモーフィズムに 相当するものはありません。 1...67891011121314151617181920...48 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
ソリューションの効率化とはどういうことですか？
ソリューションの効率とは、メカニズム（ソフトウェアも間違いなくメカニズムです）が最も安定的に機能するようなソリューションの質を意味します。その仕組みは、明確で一貫性があり、生産性の高いものでなければなりません。エンジンの機能は、割り当てられたすべてのタスクを実行する必要があります。この機構は余計なものを受け付けないし、この機構の開発においては、余計なものは切り捨てるべき。
そうでなければ、発展は望めないし、効率も悪くなる。
これはあくまでも私の意見であり、誰かに押し付けるものではありません。
私はOOPが好きではありません。
しかし、保守性、拡張性、サードパーティーの使い勝手という点では、TC（カルプトフではなくピーター）が推すものは石器時代としか言いようがないのです。
私は、プログラマーは 4人以上のチームで仕事をするのが理想だと考えています。
ここで大合唱するつもりはありませんが、OOPの支持者は、OOPなしの解決策よりもこの解決策がより効率的であることが明確にわかる、問題を解決するコードを提出できないでしょうか？
私はOOPなしで問題を解決する達人であり、OOPで問題を解決する達人と戦いたいと思っています。
あなたがやり手で、いつも仕事をくれるお客さんがいるとします。そして、5〜6回目の指令で、彼の仕事はどれもどこか似ていることに気づく......。そして、それらを組み合わせてパターンを作ることができると...。そして、お客様もこのテンプレート同士を大量に組み合わせるのがお好きなようで・・・。そして、クライアントから再び難しい仕事を依頼されたら、このテンプレート（クラス）のインスタンスを必要な数（例えば10個）作成し、それぞれにクライアントに発生したプロパティを（コンストラクタで）設定すればよいのです......。結局、注文を出すかどうかの判断は、10個のインスタンスのそれぞれで結果を見るというループで済んでしまう...。そんな注文を5分でリベット留めして...。
でも、OOPがないとインスタンスは作れないし、今あるものが壊れないことを祈りながら、ほとんどすべてをやり直さなければならない...その結果、多くの時間を費やすことになる...」。
結論：OOPを知っているプログラマーは、（OOPに適した）問題をより速く、より少ないミスで解決することができる...。
説明しますと、例えば、あなたが演奏家で、いつも仕事をくれるお客さんがいるとします...。そして、5、6回目のオーダーで、彼の仕事がある意味同じであることに気づくのです...。そして、それらを組み合わせてパターンを作ることができると...。そして、お客様もこのテンプレート同士を大量に組み合わせるのがお好きなようで・・・。そして、クライアントから再び難しい仕事を依頼されたら、このテンプレート（クラス）のインスタンスを必要な数（例えば10個）作り、それぞれにクライアントの頭に浮かんだプロパティを（コンストラクタに）設定すればよいのです......。結局、注文を出すかどうかの判断は、10個のインスタンスのそれぞれで結果を見るというループを踏むだけで、それだけなのですが......。そんな注文を5分でリベット留めして...。
でも、OOPがないとインスタンスは作れないし、今あるものが壊れないことを祈りながら、ほとんどすべてをやり直さなければならない...その結果、多くの時間を費やすことになる...」。
結論：OOPに熟達したプログラマーは、（OOPに適した）問題をより速く、より少ないミスで解決することができる...。
その通りかもしれません。オーダーをやった ことがないので、お客さんが何を求めているのかわからない。ルーティンワークのように見えますが、私がここで言っているのは開発なのです。おそらく、ルーチンワーク（これもチームで行う）には、OOPはかけがえのないものでしょう。私はそのような経験がなく、単に知らないだけです。
そして、これらのシングルタイプのタスクのうち、OOPを使わない方が良いという具体的な例を挙げてください。
私はOOPが好きではありません。
しかし、保守性、拡張性、サードパーティーの使い勝手という点では、TC（カルプトフではなくピーター）が推すものは石器時代としか言いようがないのです。
私は、すべての プログラマーは、理想的には4人以上のチームで仕事をしなければならないと固く信じています。ただ、コードの効率や汎用性が良いということは、コードが良いということではないことを理解するためです。
あ、チームでの仕事は別歌です！（笑）。そして、プログラマーのチームを率いることは、参加者の数と同程度の歌になるのです。
ある土曜日の夜の話です。昔、うちの会社が鉄の世界に浸かっていた頃の話。もし繰り返しになるようでしたら、申し訳ございませんが、すでに少し前の話になだれ込んでいるかもしれません。
上司に呼び出され、「仕事が忙しすぎるんじゃないか？と言ったら、「そうでもない」と言われました。
-ところで、これからどうするんだ？欠勤が続くなど、個人的なスケジュールを自分で立ててしまうので、課長は私の仕事ぶりを知らないのです）。
私は、「ああ、うちの機器のテストパッケージを書いてるところだよ」と言いました。チーフは「素晴らしい、シベリアで試すのにちょうどいい」と大喜びだった。アレクセイ、私たちは上空を飛ぶ必要がある。彼らはそこで立ち往生している、彼らはそれを理解することはできません。出張は大好きで、完全に自由でした。
クラスノヤルスクに飛ぶと、部下が出迎えてくれて、みんな後ろめたそうな顔をしている。カフェに行って、お酒を飲んで、話をした。どうしたんですかと聞いたら課長は困惑していましたね、3カ月も出張していたのに、ある地点で立ち往生していたんですね。振り込みの時間しかないそうです。
まあ、表に出ているんですけどね。車でシベリアの村に行き、宿屋に泊まると、そこに若い姉妹が2人いた。だから、誰も怒らないように、愛を紡ぎ、仲間を巻き込んでいったのです。
あなたを警察に突き出さないって言ったのよ、私も同じだから。でも、この調子でやっていかないと。花輪を全部調整しよう、残りはデタラメで500マイルだ、そしたらボーナスを出す、ボスの金を絞る、お前とこの仲間で新年を祝おう、いいな？
今なら女性は怒り狂うだろうが、レカは「妻が出産すればいい、私はしばらくここにいたい」と真っ先に同意したのだ。みんな結婚しているのに、なぜか誰も帰りたがらない（笑)。
一方で、若くて美しいシベリアの女の子たちが待っていると、男たちがどれだけ頑張れるか、直感で理解できた（笑)。
これはまったく論外です。
どんなタスクも、OOPがあってもなくても解決できる。また、OOPでなければ、何度も使うような統一された関数を簡単に作ることができ、プログラムを変更しても、プログラム全体が壊れることはない。OOPでは少しコードが多くなります。OOPを 使うと可読性が良くなるのですか？ わかりません。
私は、各クラスを別のファイルに保存し、各関数も別のファイルに保存しています。ただ、習慣と利便性の問題です。
もうひとつ、最もシンプルな例として、ごく表面にあるのは......。MetaEditorのEAジェネレータ...プログラミングができなくても、膨大な数のインジケータとコンディションを含むEAを10秒で組み立てることができる )))そして、これらはすべてOOPである ))
議論することはまったくない。
どんなタスクも、OOPがあってもなくても解決できる。また、何度も使うような統一的な関数をOOPなしで簡単に作ることができ、プログラム全体に変更を加えても壊れることはありません。OOPでは少しコードが多くなります。OOPを 使うと可読性が良くなるのですか？ わかりません。
私は、各クラスを別のファイルに保存し、各関数も別のファイルに保存しています。ただ、習慣と利便性の問題です。
このスレッドでは、OOPでなくても解決できる問題の例がありましたが、非常に非合理的な方法で解決しています。
これはまったく論外です。
どんなタスクも、OOPがあってもなくても解決できる。また、OOPでなければ、何度も使うような統一された関数を簡単に作ることができ、プログラムを変更しても、プログラム全体が壊れることはない。OOPでは少しコードが多くなります。OOPを 使うと可読性が良くなるのですか？ わかりません。
私は、各クラスを別のファイルに保存し、各関数も別のファイルに保存しています。ただ、習慣と利便性の問題です。
個人的な開発ではOOPは必要ないと断言できるのですが、大きなプロジェクトでのチームワークについては自信がありません。異なるプログラマーが作成したコードの開発やコミュニケーションは、これまで思いつかなかったし、自分なりにどう実装すればいいのか分からない。これが、私が現在受け入れている、開発におけるOOPの唯一の主張です。
これは本論ではありません。
手続き型プログラミングには、ポリモーフィズムに 相当するものはありません。