Если вы никогда не слышали про Алана Кэя, то как минимум слышали его знаменитые цитаты. Например, это высказывание 1971 года: The best way to predict the future is to invent it. Лучший способ предсказать будущее это изобрести его. У Алана очень яркая карьера в информатике. Он получил Премию Киото и Премию Тьюринга за работу над парадигмой...
同じ経験と知能を持つ2人のプログラマーが、同じような大きな プロジェクトを作り、競争しているとしたら。しかし、前者は関数しか使わず、後者は関数とクラスを使っている。間違いなく、勝利は2作目にもたらされるでしょう。しかし、繰り返しになりますが、ボリュームのあるプロジェクトであれば、後者の方がバグが少なく、秩序があるため、より早く仕上げることができます。そして、2番目の製品は、より読みやすく、保守しやすく、更新や補足がより簡単にできるようになります。これは私のイミフでもなく、ただの事実の表明です。こてよりもスコップで穴を掘る方が簡単です。関数だけでなく、クラスにも仕組みを実装すれば、より効率的になるはずです。さて、これが私のイメトレです。
まず、大きな仕組みを実装する際のクラスの必要性の問題から。クラスはいくつかの機能の集合のためのシェルであり、「大きなメカニズム」は一連のタスクを実装するコードのブロックである。私の実装では、「大きな仕組み」とは、ほとんどの場合、非常に大きな1つの機能と、それを提供する小さな機能の集合を指します。いわゆる「エンジン」です。一つのクラスに提供機能を詰め込んでも何も変わらないし、別のクラスに詰め込めば、クラス間のアクセスが複雑になり、機構効率も落ちる。
機構のサイズが大きくなると、コードを最適化したり、機能をファイルに分割したりする必要があります。十分ではないでしょうか？さらに、1ブロックのコードを定期的に最適化 することで、奇跡的な効率化を実現します。常に圧縮され、実装に必要な機能がどんどん増えていきます。つまり、逆に機能数が減ってしまうのです。これらは1つのブロックに集約され、そのコードは常に改良されています。これは 効率化への 近道です。
また、重要な変数をグローバルにすると、機構内のどこでも見えるようになり、作業がしやすくなりますし、スコープを定義すると、機構の効率化の観点から、余計な作業が発生します。ここでもアクセスの煩雑さがクラスオブジェクトの作成など...。機構を多数の機能に分割する傾向があるため、効率だけでなくコードブロックの普遍性も損なわれている。具体的なタスクにはそれぞれ別の関数が必要であることがわかり、コードブロックの普遍性は単純に改善されない。また、呼び出しや渡されるパラメータの数も増えていく。これでは機構の効率は上がらないが、実はこの傾向はOOPによって促進されている。
OOPは、プログラマーのチームでプロジェクトを進めると効率的です。この場合、これがないと困るのです。とはいえ、よくよく考えれば、こちらもなくてもいい方法はあるのですが......。
でも、もちろん、これらはすべて言葉です。実際にやってみると、私が言っていることがすぐに証明されます。
Nikolai Semko:
そして、Peter、あなたのコードを ざっと見たところ、canvas をフルに使っていることがわかりました（CCanvas クラスではありませんが、気にしないことにします）。では、なぜキャンバスについての質問があるのか、なぜ私がここでこれらのことを説明しようとするのか。:)).
))), kanvasの描画原理の説明にはちょっと驚きました。 私のkanvasはすべて描画されていることは、以前にもお話しましたし、お見せしたことがあります。）(まあほとんど全部ですが。)
このトピックを立ち上げたのは、なぜ今のところ誰も私と同じボタンを描かないのかが理解できないからです。結局のところ、そしてあなたの言葉を借りれば、それは簡単なことなのです。
)), 私も以前、何でもかんでも描くと言ったり見せたりしていたので、キャンバスに描く原理の説明には少し驚きました.）(まあほとんど全部ですが。)
このトピックを立ち上げたのは、なぜ今のところ誰も私と同じボタンを 描かない のかが理解できないからです。結局のところ、そしてあなたの言葉を借りれば、それは簡単なことなのです。
見ていないからといって、自分以外ができないわけではありません。それはちょうどあなたがそれを投稿する必要はありません - あまりにも些細なイベント -単なるボタンを 作成する - そのコードを投稿する、あなたが最高だからではない;)
皆さんは風車と競争しているわけですが、それは当然です、アナトリー。
見ていない人は、自分以外の人ができていないわけではありません。ただ、あまりにも些細な出来事なので、投稿する必要はありません。ボタンを作成しただけなのに、そのコードを投稿するなんて、あなたが一番だからというわけではありません;)
皆さんは風車と競争しているわけですが、それは当然です、アナトリー。
落ち着いて アルテムあなたが私を嫌っていることは、もうわかっています。どうやら、このリソースの他の多くの人も同じようです。正当な理由かもしれませんが、技術的な話をするときに、いきなり人格を変えるのはやりすぎです。
私は冷静だ、なぜそうじゃないと思うんだ？
人の好き嫌い - 議論するための技術的なフォーラムではありません。あなたは私にとって中立的な存在であり、それ以上のものではありません。同じように、他の人たちについても、そう思えるのです。
でも、「あ～あ...、あのドン・キホーテだ...、思い出した、思い出した...」というスタイルではなく、言及されるためには、せめて何か役に立つことをしなければなりませんね。
やりたいことをやるのもやらないのも、あなたの権利であり、誰もそれに異議を唱えてはいないのです。誰もあなたの言葉を必要としていない - あなたは最初の場所で自分自身にそれを与えるべきである;)
ある場面でOOPを使う のがいかにいいかを教えてくれたり、目の前で男がはりつき、何かで助けようとしてくれたり、よりわかりやすくするためにコーディングして見せてくれたり、とてもフレンドリーな雰囲気です。しかし、あなたの言葉からは、それが必要ないことがわかります。あなたはただ、他の誰と競争していいかわからず、「弱く」人に挑戦しようとしているだけなのです。
そして、何がまた私に思われる - あなたは、あなたが書かないし、OOPを勉強しないことを決めたので、あなたはすべてを計量し、手続き型プログラミングを使用して、はるかに良い、最適化されたコード（あなたがここで皆にそれを提示したように）書くことを理解したのではなく、単にあなたがそこに何かを理解していない、とあなたは言葉や挑戦でそれをサポートして皆に発表し、口実を発明したからです "のみ私を打つ彼を信じています" 。
エルーシブ・ジョー "というジョークを覚えていますか？
...
エルーシブ・ジョー "というジョークを覚えていますか？
全く同感です。
とらえどころのない作詞家／哲学者... :-) 「ジョー」と同じくだりで、「もう片方の手」だけ...。:-)
まず、大きな仕組みを実装する際のクラスの必要性の問題から。クラスは一連の機能のためのシェルであり、「大きなメカニズム」は一連のタスクを実装するコードのブロックである。私の実装では、「ビッグマシン」とは、ほとんどの場合、非常に大きな1つの機能と、それに奉仕する小さな機能の集合体です。いわゆる「エンジン」です。一つのクラスに提供機能を詰め込んでも何も変わらないし、別のクラスに詰め込めば、クラス間のアクセスが複雑になり、機構効率も落ちる。
機構のサイズが大きくなると、コードを最適化したり、機能をファイルに分割したりする必要があります。十分ではないでしょうか？さらに、1ブロックのコードを定期的に最適化 することで、奇跡的な効率化を実現します。常に圧縮され、実装に必要な機能がどんどん増えていきます。つまり、逆に機能数が減ってしまうのです。これらは1つのブロックに集約され、そのコードは常に改良されています。これは 効率化への 近道です。
また、重要な変数をグローバルにすると、機構内のどこでも見えるようになり、作業がしやすくなりますし、スコープを定義すると、機構の効率化の観点から、余計な作業が発生します。ここでもアクセスの煩雑さがクラスオブジェクトの作成など...。機構を多数の機能に分割する傾向があるため、効率だけでなくコードブロックの普遍性も損なわれている。具体的なタスクにはそれぞれ別の関数が必要であることがわかり、コードブロックの普遍性は単純に改善されない。また、呼び出しや渡されるパラメータの数も増えていく。これは機構の効率化には寄与しないが、実はこの傾向はOOPによって促進されている。
OOPは、プログラマーのチームでプロジェクトを進めると効率的です。この場合、これがないと困るのです。もっとも、考えてみれば、ここでも回避する方法は見つかるのだが......。
でも、もちろん、これらはすべて言葉です。実際にやってみると、私が言っていることがすぐに証明されます。
Peterさん、私も以前は関数だけでプログラミングをしていて、今のあなたとほとんど同じように推論していたのですが、ほとんど強制的に（習慣の力はすごいですから）クラスでプログラミングをするようになったんです。今、私は2つの状態を比較することができますが、応用授業を試していないあなたにはできません。悪気はないんです。ただ、別のシチュエーションを思い出しました。私はもう何年もベジタリアンをしています。また、うらやましいことに、ベジタリアンになったことがない人が、タンパク質や必須アミノ酸などについて、私にこき下ろすことがあります。私は肉食で、今はベジタリアンなので、この2つの状態を実践の面で比較することができます。あなたの知識は、実践とは無縁の机上の空論に過ぎないのです。
時間を無駄にしないために、OOPをマスターしましょう。
この掲示板では完全に出入り禁止ですよ。:))私も含めて。:( 絶望しないでください-死なないものは私たちを強くします。 あなたを信じています!!! :))
時間を無駄にしないために、OOPをマスターしましょう。
この掲示板では完全に出入り禁止ですぞ。:))私もです。:( 絶望しないでください。死なないことは、私たちを強くしてくれます。 あなたを信じています!!! :)
まず、大きな仕組みを実装する際のクラスの必要性の問題から。クラスは一連の機能のためのシェルであり、「大きなメカニズム」は一連のタスクを実装するコードのブロックである。私の実装では、「ビッグマシン」とは、ほとんどの場合、非常に大きな1つの機能と、それに奉仕する小さな機能の集合体です。いわゆる「エンジン」です。一つのクラスに提供機能を詰め込んでも何も変わらないし、別のクラスに詰め込めば、クラス間のアクセスが複雑になり、機構効率も落ちる。
機構の規模が大きくなると、コードの最適化や機能のファイル分割が必要になる。十分ではないでしょうか？さらに、1ブロックのコードを定期的に最適化 することで、奇跡的な効率化を実現します。常に圧縮され、実装に必要な機能がどんどん増えていきます。それは、逆に機能数が減ってしまうことです。これらは1つのブロックに集約され、そのコードは常に改良されています。これは 効率化への 近道です。
また、重要な変数をグローバルにすると、機構内のどこでも見えるようになり、作業がしやすくなりますし、スコープを定義すると、機構の効率化の観点から、余計な作業が発生します。ここでもアクセスの煩雑さがクラスオブジェクトの作成など...。機構を多数の機能に分割する傾向があるため、効率だけでなくコードブロックの普遍性も損なわれている。具体的なタスクにはそれぞれ別の関数が必要であることがわかり、コードブロックの普遍性は単純に改善されない。また、呼び出しや渡されるパラメータの数も増えていく。これは機構の効率化には寄与しないが、実はこの傾向はOOPによって促進されている。
OOPは、プログラマーの集団でプロジェクトを進めると効率的です。この場合、これがないと困るのです。もっとも、考えてみれば、ここでも回避する方法は見つかるのだが......。
でも、もちろん、これらはすべて言葉です。実際にやってみると、私が言っていることがすぐに証明されます。
そして、それには何かがある。OOPの生みの親であるアラン・ケイは、実は現在のOOPの意味とは全く異なる考えを持っていた。さらにビジョンに近いものがありますね。私は、1つのコアと、いくつかの機能のためにそれを呼び出すサービスからなるプロジェクトを作成するアイデアを持っています。そして、要素間のコミュニケーションは、イベント-メッセージを通じてのみ行われます。データでevent-requestを送ると同時に、結果でevent-replyを受信します。継承、多態性、包含はない。
ちなみに、この方法では、定義上すべての要素が互いに独立して動作するため、マルチスレッドを整理するのが容易である。
そこには何かがある。OOPの生みの親であるアラン・ケイは、現在のOOPの意味とは異なる考えを持っていた。さらにビジョンに近いものがありますね。私は、1つのコアと、いくつかの機能のためにそれを呼び出すサービスからなるプロジェクトを作成するアイデアを持っています。そして、要素間のコミュニケーションは、イベント-メッセージを通じてのみ行われます。データでevent-requestを送ると同時に、結果でevent-replyを受信します。継承、多態性、包含はない。
ちなみに、この方法では、すべての要素が定義上、互いに独立して動作するため、マルチスレッドを整理しやすくなります。