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

新しいコメント
 
Реter Konow:
なぜswitchがこの作業に適していないのか、よく理解できない。まあ、具体的な状況に応じてトレーリングストップの全パラメータを一度に計算する公式を作れない人が、100種類のバリエーションを書くとしたら、swtchが最適解なんですけどね......。

最適なソリューションがあるため、適切ではありません -ポリモーフィズムを 持つOOP - 必要なオブジェクトはiniteで作成され、ないバラストケースとif。100個のtrailingingにはifを使うべきで、ユーザーが1つのバリアントに制限されないように、2つまたは3つのバリアントを同時に含めることができます。そして、100ifで終了です。

 
Alexey Volchanskiy:

つまらないって...。

私は、「私も暇だから、楽しい友達を紹介してくれない？

- 心理学者の移植がある、彼らは学会から直行している、私はできる ))))

さて、私たちは同意し、私は、サーニャ、私たちの友人にいたずらしよう、と言いました。


さて、「濁音」の作業をしたところ、サーニャから電話があり、「アレクセイ、君は民間パイロットだろう？

私は、 - はい、何が問題なのでしょうか？

- バーで座っていた時、私は飲まなかったのに、パイロットは飲んだ。今度は喧嘩になり、飛行機は制御不能になった。

飛べない！勉強中です。

- よし、コースの舵取りをしよう。

 
Dmitry Fedoseev:

なぜなら、最適なソリューションがあるからです。ポリモーフィズムを 用いたOOPでは、必要なオブジェクトはiniteで作成され、バラストケースは存在しません。また、100 個の末尾の variant には if を使い、ユーザが 1 つの variant に制限されないように、2 つまたは 3 つの variant を同時に含むようにします。そして、100ifで終了です。

私の理解が正しければ、各トレーリングストップは別々の機能なのでしょうか？1つの機能にすべてを集約できる...

各トレーリングストップが別々の関数である場合、ユーザーの最初の選択や特定の状況に応じて呼び出されるのでしょうか？

 

OOP ポリモーフィズムを使えば、オブジェクトのメソッド呼び出しは、コスト的には10のifとほぼ同じになります。したがって、10種類以上のバリエーションがある場合は、OOPを使うのが合理的です。

 
Реter Konow:

私の理解が正しければ、それぞれの末尾の関数は別の関数なのでしょうか？ひとつの機能にまとめても...。

各トレーリングストップが別々の関数である場合、最初のユーザーの選択や特定の状況に応じて呼び出されるのでしょうか？


捨ててください。また、その有効化・無効化はどのように行うのでしょうか？

 
Dmitry Fedoseev:

消えろON/OFFはどのように行うのですか？

全体像が見えてきたユーザープログラムの設定方法について正確に教えてください。

そうして、100もの機能が、それぞれ異なる痕跡を残しているのです。

問題は、特定のトレーリングをどのように選択するかです - ユーザーによるものか、プログラムによるものか？

 
Реter Konow:

一般的な絵を描いているだけです。ユーザープログラムの設定方法について正確に教えてください。

そして、100の個別機能には、さまざまな軌跡があるわけです。

問題は、特定のトレイリングスイッチの選択をどのように行うかです。ユーザーによるものか、プログラムによるものか。


プロパティウィンドウにスイッチがあります。

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

課題を読む生産性も上がったのでしょうか？テストケースを書く生産性も上がったのでしょうか？ソフトウェア製品のマニュアルを書く生産性も上がったのでしょうか？また、試運転に要する時間も短縮されたのですね。

最新の開発方法論について知っていますか？タスクやバグ追跡システム、リポジトリ、ユニットテストやテストの自動化、最新のQAについて？

そして、異なる作者間の矛盾によるチーム内の解体？

バージョン管理システムによって、古臭さはほとんど解消される。

そして、誰も理解できないコードを書く、あらゆる種類の天才を追放すること？

チーム内でコードスタイルを厳守することで、読めないコードの存在を大きく減らすことができます。コードレビューの実践により、実質的に排除されている

真面目な開発者の隣に座ったこともあるのか？

そうです、私は真面目なポートフォリオを持っています、あなたのは全然違うでしょう。
 

Комбинатор:

そして、誰も理解できないようなコードを書くあらゆる種類の天才を追放すること？

チーム内でコードスタイルを厳守することで、読めないコードの存在を大きく減らすことができます。コードレビューの実践により、実質的に排除されている

まあ、これだけではなかなか難しいですね。スタイルの問題ではないかもしれません。タスクによっては、その最適解を得るために反対側から見ることが必要なものもあります。そして、見たままを歌うことしかできない人もいます。その人たちにとっては、もちろんコードは理解不能でしょう。
 
Alexey Volchanskiy:

一般に、私たちはムウクに取り組んでいました。サニアが私のところに来て、「アレクセイ、あなたは民間人のパイロットでしょう？

私は、 - はい、何が問題なのでしょうか？

- バーで座っていた時、私は飲まなかったのに、パイロットは飲んだ。今度は喧嘩になり、飛行機は制御不能になった。

飛べない！勉強中です。

- よし、コースの舵取りをしよう。


まあ、もちろんパイロットは行かず、30分ほど緊張の面持ちで休憩してましたが ))

サーニャは見事な仕事をこなしていたが、そんな不吉な小声で私に寄りかかってきた。「レク、パイロットのインコマンドは本当にどうかしている、私を乗せて行ってくれないか？

自分の席に戻ると、少女心理学者が盛んに緊張している。

乱気流ゾーンに入り、飛行機が大きく揺れ、子宮が落ちそうになる（笑)

とサーニャが言いながら、自動操縦がダウンした、レヒ、全ての望みは私たちに託された！と言って、そこにいた。シミュレーターで少し飛んでましたよ～。

とにかく、なぜかその時の心理学者の女の子を怒らせてしまったのです。正直、今でも恥ずかしいです。

1...121314151617181920212223242526...48
新しいコメント