私のアプローチコアはエンジンです。 - ページ 18

新しいコメント
 
jdjahfkahjf:
またOOPについての議論ですか。

いや、カジュアルプログラミングについて議論している間、私はOOPに毛布を引きずっているのですが、トピックスターターはまだしがみついています！彼は、すべては頭の中に入れておくことができると書いています - まあ、カジュアルプログラミング)))

 

コア・エンジン

 
Igor Makanu:

カジュアルなプログラミング )))

カジュアルなプログラミング :)

 
jdjahfkahjf:

カジュアルなプログラミング :)

数ヶ月前、別のフォーラムでカジュアルプログラマと名乗る人がいて、その意味を明らかにしようとしたのですが、私のカジュアルという言葉の知識はAndroidゲーム「Zuma」しか連想できないので、ランダムにプログラムするプログラマということが分かりました。）

 
Vasiliy Sokolov:

OOPは非常に柔軟な方法論なので、「カーネル」という概念のような先験的な考え方はありません。しかし、ここで問題になっているカーネルモデルは、OOPを使って構築することも十分に可能です。したがって、この文は完全に正しいとは言えません。

いや、OOPはまったく関係ない。カーネルはUnixで、カーネルを中心にすべてを組み立てます。シェルはWindowsのようなもので、余計なものを取り除き、残りで仕事をします。一般的には、オペレーティングシステムについてです。

 
jdjahfkahjf:

ケイジャン・プログラミング :)

カジュアルの方、ご安心ください。

 
Реter Konow:

私がOOPに嫌悪感を抱くのは、コードの書き方が硬直化していることです。ご覧のように、私は大きなデータ表を作ることが多いので、とても実用的だと思います。OOPでは、たくさんのルールに従わなければならないので、個人的にはとても窮屈に感じています。

要するに、私は違うOOPでプログラミングをしているのです。自分のです。ルールはほとんどなく、自由度が高い。機能そのものは大きなブロックに積み上げられ、データはカーネルで整理されています。特別に構造まで考えているわけではありません。すべては自ら発展していくものです。直感的なレベルでは

ピーター そのルールは、あなた自身に必要なものなのです。だから「凝り性」なんですね。うっかり失敗して、想定外のことに巻き込まれないようにね。実は、OOPスタイルは「交通ルール」なのです。もちろん、ドライバーを制限するものです。しかも、3ヤードの村では......誰も見向きもしないので、楽だし、早い（効率的）です。しかし、大都市では逆に、交通ルールがあるからこそ、最も効率的な交通機関の接続が可能になるのです。 AOPも同じです。大規模で複雑なシステムを最も効率的に構築するためのルールなのです。

あなたのシステムでは、まだ変化がないだけで、使用用途は非常に限定されており、改造の必要はありません。だからこそ、頭の中に入れておくことができるのです。システムがユーザーを獲得し、修正が必要になっても大丈夫です。コントロールとカプセル化の欠如は、かなりのストレスになるでしょう。

それ以外はすべて同じで、OOPとあなたのスタイル（あなたは手続き型スタイルも持っていますが、グローバル変数や 型制御の欠如など、同じ欠点に悩まされています）は、それ以外は近いです。

あなたのスタイルを守るためには、システム全体を巨大なグローバル配列にして任意のアクセスを可能にすることが、プログラムをポリモーフィックアクセスの継承チェーンに入れ子にしてカプセル化で隠した小さな部品の束に分割することよりも良いということを証明する必要があります。

ちなみに、この掲示板には相続が嫌いな人もいるのですが、その人たちはあなたを支持するかもしれませんね。

 

また、Peterの方法とは異なり、OOPを使用 する利点もあります。OOPでは、プログラマは基本クラスのソースコードを必要とせず、その仕組みを理解する必要もない。 基本クラスの機能を拡張したり変更したりするには、このクラスの継承者を作れば十分である。

ピーターの方式だと、プログラマーが長いコードを全部理解する必要があるし、ソースコードがない場合は一から書かなければならない。

 
Georgiy Merts:

それ以外の点では、OOPとあなたのスタイル（すでに述べたように、あなたは手続き型のスタイルを持っていますが、グローバル変数、型制御の欠如など、同じ欠点に悩まされています）は、それ以外はほぼ同じです。

間違っているかもしれませんし、ググるのも面倒ですが、手続き的なスタイルは、手続き（関数）の論理的な完全性を意味し、ソースから「ねじ外し」、他のコードで使用します。と、ここでピョートルが両足で転倒 ))))- グローバルに宣言された変数による交換は、コードの移植性を低下させ、追跡困難なバグを可能にします ;)

 

わかりました。納得したとしましょう。

  1. OOPは、プログラマーのチームが大きなプロジェクトに 取り組むために必要なものです。
  2. OOPは、プログラムを組織化し、構造化する。
  3. OOPはプログラミング能力を向上させるために多くのツールを提供しています。

原理的には、以前からすべて理解していました。そして、私もそれに賛成です。しかし同時に、私なりのアプローチも好んでいます。なぜ？

そこには、ある特別な理由がある。

プログラム開発。

//---------------------------------------

OOPと私のアプローチでは、プログラムの開発スピードはどのくらいになるのでしょうか？メカニズムの成長や複雑化には、どちらのアプローチが有利なのでしょうか？

私は、私のアプローチとコード内の母国語（ロシア語60％、英語40％）により、プログラムを最大限に速く成長さ せることができると結論付けました。

まさに、この急成長こそが私の必要としているものなのです。細かいところを掘り下げない。コードの一行一行に目を通すだけでなくプロフェッショナルなアプローチではありません。

プログラムを早く発展させ、複雑なものにしたかったのです。その機能を果たすために、機構が作られるのです。素早く、簡単に。

数行のコードで新機能を追加できるように。

私のアプローチは、この特定のタスクを解決する上で、OOPよりも優れています。

1...111213141516171819202122232425...184
新しいコメント