問題タブ [procedural-programming]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
boolean - OZプログラミング言語:ブールガード
私はモーツァルトプログラミングインターフェースを使用する必要がある学校で科目を取っています。今のところあまり考えていません。しかしとにかく、ここに質問があります:
OZでは、変数を割り当てることができるのは1回だけです(再割り当てすることはできませんが、現在のスコープで再宣言することができますか?)。ブールガードを使用したいという問題に遭遇しましたが、OZは私を許可しません。私は現在を持っています:
誰かがこれを行う方法について何かアイデアがありますか?御時間ありがとうございます。
algorithm - Diamond-Square アルゴリズムのスムージングの問題
ダイヤモンド スクエア アルゴリズムを使用して、ランダムな地形を生成しています。これらの大きな円錐形が地形から突き出ているか、地形に突き出ていることを除いて、うまく機能します。問題は、時々、ポイントが高すぎたり低すぎたりすることです。
これが問題の写真です
そして、滑らかさを非常に高く設定すると、よりよく見えるようになります
そして、ここに私のコードがあります -
php - 何千ものオブジェクトタイプを生成するときのPHPOOのパフォーマンス
私はMattZandstraPHPオブジェクト指向のデザインとパターンを読んでいて、アイデアがとても気に入りましたが、数百から数千もの作成時にPHPのパフォーマンスにどのように影響するのか疑問に思いました。
あなたは何千もの異なるタイプのタイルからなる地図を持っています(文明のように)。あなたは一般的なタイルを持っていて、他のタイルは10の異なるタイプの1つである可能性があります。
彼は基本的に、基本タイルを作成してから、他のタイルに次のようなプロパティを継承させると言っていました。
このマップを構成するさまざまなタイプの地形がすべてあり(第1世代の場合)、データベースをループして次のように構築します。
だから私の質問は...これはパフォーマンスとどのように関係するのでしょうか?PHPはすべてのタイルを大きなオブジェクトとして保存しますか、それともオブジェクト定義への参照を含むだけですか?
何千もの正方形でいっぱいのマップがループしていて、他のジャジーなことをしているとき、私はちょうど考えています。オブジェクト指向プログラミングはかなりかさばるといつも思っていたので、それは非常に遅くなりますか。
手続き型にしてから、正方形をループして関数を実行し、これらで何が起こるかを判断する方がはるかに速いでしょうか?
このようなOOデザイン/パターンを使用した場合のパフォーマンスは一般的にどのようなものか疑問に思っていますか?
編集:OOと手続き型ループの意味は次のようなものです:
ご覧のとおり、OOメソッドは本当に理にかなっています。マップにタイルを入力していますが、2つの山の場合、何らかの重複があります。または、それを呼び出すと、クラスの青写真を参照して何をしているのでしょうか。 。
コンストラクトメソッド(ある場合)を呼び出すだけで、必要なときに手元にあるメソッドがあるので、かなり迅速ですよね?
ありがとう、ドム
functional-programming - ステートフルプログラミングの利点は?
私はステートレスプログラミングの利点について疑問に思っていましたが、私の質問を共有している人を見つけました: ステートレスプログラミングの利点は?
しかし、答えを読んでいると、逆の質問に興味を持ちました。ステートフルプログラミングの利点は何ですか?最近はステートレスコードに注目が集まっているようですが、トレンドには警戒しています。
ステートフル(つまり命令型)プログラミングは、ステートレス(つまり関数型)プログラミングよりも特定のシナリオに適しているようです。ステートフルプログラミングで解決できる問題をよりよく認識できるようにしたいと思います。
sql-server - カーソルは本当に「正しい」選択ですか?
データを処理するときに、手続き型プログラミングが絶対に避けられない場合があります。
現在、いくつかのレガシー コードの最適化に取り組んでいます。カーソル、63 組のIF
/ELSE
ステートメントとBEGIN
/END
などを使用します。カーソルをリバース エンジニアリングして、手続き型のプロセスにしたいと考えていました。今、私はアルゴリズムの解読の最後にいて、 . . . おっと...レコードに対して行われた各選択は、先行するすべてのレコードに対するプロセスの結果に依存するため、手続き型でなければなりません。
だから今、私は引き裂かれています...手続き型コードをSQL Server処理(CLR SP、UDFなど)と混合するための他の選択肢があります。私は仕事に適したツールを使用することを強く信じているので、このために .NET CLR SP を作成することに傾倒しています。ただし、カーソルを少し単純化するだけで、カーソルを保持する方が高速で「簡単」です。
皆さんはどう思いますか?SQL Server 内から .NET モジュールにアクセスできるようになったので、カーソルを使用することはもはや適切でしょうか (私の意見では、最初はおかしな/回避策でした)。
c - 手続き型コードをリファクタリングするときのエラーの処理
基本的に大きなmain()関数で構成されるCコードが渡されました。私は現在、コードの意図を明確にするために、メソッドをより小さな関数に展開しようとしています。しかし、私はいくつかの問題を抱えています:
このコードの関数で4つの主な懸念事項を特定できます。
- 引数の数が正しいことを確認します。
- コマンドライン引数からポートを取得します。
- 呼び出し信号(SIGPIPE、SIG_IGN)。
- 実際にソケットとの接続を試みてください。
これを小さな関数にリファクタリングしようとするときの問題は、主にエラー処理に関連しています。たとえば、1のロジックを抽出しようとすると、次のようになります。
それを呼び出すと、このようなものになります
これは実際にはそれほど悪くはありません。さて、ソケットの場合、それは両方sockfd
とs_addr
も返される必要があるので、はるかに面倒であり、さらにステータスの戻り値があります。
これは、私のメインの方法をできるだけ単純で明確にしようとする目的を打ち破ります。もちろん、.c
ファイル内のグローバル変数に頼ることはできますが、それはあまり良い考えではないようです。
この種のことをCで一般的にどのように処理しますか?
php - OOP は PHP サイトに必要ですか? その概念を手続き型コードに適用することはできませんか?
OOP と手続き型の違い、いつどちらを使用するか、利点が余分なオーバーヘッド、構文の学習、継承の混乱などを上回るかどうかについて、数え切れないほどの質問があることを私は知っています。必要かどうかではありません。
私は通常、何をしているかに応じて、同じサイト スクリプト内で OOP とプロシージャルを混在させます。私はまだ OOP にかなり慣れていませんが、OOP のモジュール性と、それがもたらす利点は、多少のオーバーヘッドはあるものの、実際には非常に気に入っています。ただし、継承は時々少し混乱することがあります。
私にとって、主な利点は、コードの編成と保護の改善にあるように思えます。そのうち、開発者または開発者チームだけがそれを高く評価しています。展開速度にはケースがあると思いますが、他の誰かの鳥の巣を継承していない限り、ほとんどのサイトではそれほど多くはありません:)
ただし、特に実行速度がほとんどのサイトの聖杯である場合、ほとんどの PHP アプリで OOP は必要ですか? ミリ秒のオーバーヘッドは、頻繁に使用するサイトでない限り、実際には気付かないでしょうが、電子音楽の速度のファンとしては王様です!
ゲームやリアルタイム クラウド ソフトウェアなどの複雑なもので OOP を使用していますが、静的な Web サイトはありますか? データベースの重いものでも?
OOPの恩恵を受ける典型的なサイトの実際の例を誰かが持っていますか?その理由は?
両方のケースが適切に構成されていると仮定すると、ebay や monster.co.uk のような頻繁に使用されるサイトは、OOP または手続き型 () の速度向上からより多くの恩恵を受けるでしょうか? なぜ?
少なくともプロシージャルを使用すると、クラス、拡張機能、およびインターフェイスをチェックするためにスクリプトをあちこち移動することなく、トップダウンでデバッグできます。
明確な MVC と十分にコメントされたコードを使用して、OOP モジュラー思考を適用することはできませんか?
たとえば、再利用可能な関数をインクルード ファイルに保持し、関連する関数をグループ化します。私がしなければならないことは、クラス ファイルと同じようにファイルをインクルードし、関数を呼び出すことだけです。関数を変更する必要がある場合は、クラスと同様に 1 か所で変更されます。
そして、一種の継承は、宣言するためにフープをジャンプする必要なく、手続き型に既に存在します。あなたは同じレベルのコントロールを持っていませんが、仕事をうまく素早く終わらせます.
親関数内で関数をグループ化してクラスをシミュレートし、セレクター関数を使用してそれらにアクセスすることもできます。しかし、それは少し遠いです!
また、私が知っている限り、関数が呼び出されたときにメモリにとどまり、その後の使用が速くなります。一方、OOP では、2 つの異なる変数に対して同じ関数を使用するために、さまざまなメソッドの 2 つのオブジェクトを作成する必要があります。私が間違っている場合は修正してください。
手続き型で値を直接参照できるのに、なぜオブジェクトを作成し、メソッドを使用して値を「取得」するのですか?
ここまでたどり着いたのはよくできましたが、こんなにたくさんタイプしたことに気づきませんでした。とにかく、これ以上脱線する前に、ここで終了します。
したがって、OOP または手続き型の恩恵を受ける実際のサイトまたはサイトの一部の良い例があれば、明確にしていただければ幸いです。
oop - 手続き型プロジェクトをOOプロジェクトに移植する方法
私は小さなPHPプロジェクト(約3000行)を持っており、使用図、シーケンス図、状態図、おそらくクラス図から始めて、その基本的なUMLモデルを作成し、コラボレーション図で拡張する必要があります。
私はUMLモデリングに不慣れであり、逆ではなく実装からモデルを作成するのはこれが初めてです(リバースエンジニアリングに興味がない限り、あまり有用ではありませんが、それは割り当てです)
さて、私はこの問題にどのように取り組むべきですか?一部のUMLツールは、プロジェクトにOO実装がある場合、私の生活をかなり楽にすることができますが、そうではないので、プロジェクトをOOとして書き直す必要があるかどうか、およびその方法を考えています(つまり、いくつかの標準的な基本がありますか?ガイドラインまたは手順に従う必要がありますか?)、またはプロジェクトのモデルをそのまま作成する必要がある場合(その場合、どのモデリングツールが最適か)。
また、私のプロジェクトはEclipse IDEで書かれていますが、このUMLモデリングタスクを支援するプラグインを誰かが知っていますか?
oop - API -- CFC と cfinclude
そのため、私が働いている会社は、私たちのサイトに関しては、非常に組織化されていないアプローチをとっています. すべてのスクリプトは手続き型で、cfincludes がスローされます。私はこれを、他の Web 開発者が何かを行うために使用する内部 API に編成したいと考えていました (変更を行うと、変更を更新する必要がある他のすべてのインスタンスを見つけて見つける必要があるため)。
私はついに実例を手に入れ、上司に見せました。それは私が通常の方法であると仮定したことに従います(私のグーグルから)。サービス層 > ゲートウェイ & DAO > Beans。オブジェクトの作成を支援するいくつかのファクトリがあります。それはうまく機能し、私が達成したかったことを正確に実行します. 彼はそれに感銘を受け、コードを整理してよりよく整理する必要があることに同意しますが、同じことを達成するために cfincludes の大きなリストに対するオブジェクト指向 API 呼び出しのこの方法を使用する利点を理解していません。本質的に、彼が cfincludes を説明した方法から、それはメソッド呼び出しと同じように機能します。
彼は、私のアプローチとこの cfinclude の利点について尋ねられました。私の人生では、同様のデータをすべて 1 つのオブジェクト内にグループ化する以外に明らかな利点を見つけることができません。他に何かありますか、それとも cfinclude アプローチを使用する方が有利でしょうか?
c++ - C++ アプローチよりも C アプローチの方が有利な場合がありますか?
最近、頭の中であれこれ考えています。私たちのほとんどは、構造体を作成するために、オブジェクトを参照する前にキーワードを呼び出すことを避けるためC
に、通常、構造体の前に a を付けることをよく知っています。もちろん、C はクラスではなく構造体に限定されています。これを補うために、C は構造体専用のグローバル関数を使用してオブジェクト指向アプローチを作成する傾向があります。typedef
struct
例えば:
対。
AnotherStruct
struct
その型のオブジェクトが関数内で宣言されている場合、その前にprefix キーワードが必要です。例えば:
オブジェクト指向のアプローチに関しては、次のとおりです。
これらの関数は、ラッパーを使用せずに実装するのが非常に簡単です。例として使用しているだけです。typedef
私の要点は、キーワードなしで宣言する必要のない構造体を C++ で既に作成できstruct
、オブジェクト指向アプローチのためにこれらの構造体に関連するカプセル化されていない関数を使用できることを考えると、オブジェクトへのポインターを返すグローバル関数コンストラクターとともに、静的グローバル関数をプライベートメンバー関数として使用することを含む、C++ でコーディングする C アプローチには利点があります。
これは主に好奇心によるもので、C のアプローチを取るためだけに取りたくなることがありますが、これは単なる優先事項かもしれません。