タグ付けされた質問 「patterns-and-practices」

これはしばらくの間私を困惑させてきました。 たとえば、システムに基本的なコンテンツを提供し、JSONを消費および生成するREST APIがあります。このエンドポイントでは、画像と説明へのURLを生成し、次のように検索されます：// localhost / myApi / pictures / 1 { id: 1, description: "This is a pretty picture of a daisy", URL: <OUR URL> } これで、OUR_URLは、たとえば// localhost / myApi / files / pictures / 1などのAPI上の場所を指す必要があります。これにより、JPGが返されます（APIの背後にあるアプリケーションがファイルの物理的なコンテンツを読み取り、それをクライアントにストリーミングします。 ）。これは、JSON応答を生成する他のAPIとは明らかに異なり、実際のファイルの読み取りとストリーミングによるオーバーヘッドが発生します。 または、OUR_URLがRESTサービスのスコープ外のURLを指すようにして、//localhost/files/pictures/1.jpgがファイルを直接読み取るようにする必要があります。 だから問題は： RESTful APIはファイルを返すことができるのでしょうか、それとも単なる場所を返すのでしょうか？

12 rest  patterns-and-practices 

データベース接続が共通メソッドを使用して一度取得され、使用される関連クラス全体に渡されるシステムがあります。データベース接続をパラメーターとして別のクラスに渡すと問題が発生するのではないかという疑念があるので、ここで実際に実行可能かどうかを確認していますが、それを行うためのより良いパターンはありますか？ 永続化を行うためのORMツールがいくつかあることは知っていますが、それについてはまだ説明できません。 フィードバックを歓迎します、ありがとう。

11 java  database  patterns-and-practices 

今週はソフトウェアパターン試験があり、研究対象のトピックの1つは、遠心性カップリングと遠心性カップリングです。 パッケージが他の多くのタイプに依存する場合、そのパッケージのCe（遠心性結合）が高いことを理解しています。 例えば： class Car{ Engine engine; Wheel wheel; Body body; } このクラスは、エンジン、ホイール、およびボディのタイプに依存するため、遠心性の高いカップリングになります。 一方、他のいくつかのパッケージ（車、飛行機、自転車）に依存している場合、タイプ「ホイール」のCa（求心性結合）は高くなります。 私たちの試験で考えられる質問の1つは、Efferent / Afferentカップリングがいつ良いか悪いかです。論理的には、プログラムが高いEfferent / Afferentカップリングのパッケージ/クラスを必要とするため、これは私には奇妙に思えます。 誰かが、高遠心性または求心性結合がいつ/どこで良い/悪いかの例を持っていますか?? ありがとう！

11 design-patterns  patterns-and-practices  coupling 

パラメーターの（長い）リスト（たとえば、8つのパラメーター）を受け取るGET操作を備えたREST APIがあります。この操作の目的は、要素を検索してフィルタリングすることです。 このシナリオを管理するためのベストプラクティスはどれですか。： （1）パラメータのリストを受け取りますか？： public ResultType Get(int p1, int p2, string p3...) { ... } （2）または、これらのパラメーターをカプセル化するオブジェクトを受け取りますか？： public class MyClass { public int X { get; set; } public int Y { get; set; } public string Z { get; set; } } public ResultType Get(MyClass parameter) { ... } 名前、説明、カテゴリ、ブランド、モデル、価格などで「製品」を検索およびフィルタリングするeコマースシナリオを考えてみてください。

11 rest  patterns-and-practices  web-api 

私のjarを使用するすべてのJavaプロジェクトは、ほぼ確実に、私のjarにも依存関係として含まれている別のjarへの追加の依存関係があります。 問題は、他のjarに複数のバージョンがあることです。 プロジェクトの2番目のjarのバージョンが私のjarの2番目のjarのバージョンと異なる可能性が高い場合に、発生する可能性のある問題を回避するにはどうすればよいですか？ 私のjarファイルを追加するために、ユーザーが特別なクラスローディングトリックを実行するという面倒なことをしたくありません。 その共通の依存関係のすべての可能なバージョンについて、jarのさまざまなバージョンの束を作成する必要がありますか？そして、あなたはちょうどあなたがたまたま持っている2番目のjarの同じバージョンを使用する私のjarのバージョンを選択するだけですか？ これを処理するよりスマートな方法はありますか、そして人々が衝突することなく私のjarをより簡単に使用できるようにしますか？

10 java  patterns-and-practices  versioning  project-structure  dependencies 

私はTypescriptでゲームを作成しており、オブジェクトの実装ではなく、インターフェイスに基づいてコードを作成する「インターフェイスベースのプログラミング」のアイデアに固執しようと決心しました。 私は十分な数のインターフェースとそれらを実装するクラスを作成し、一歩下がって、クラスが単純であることを認識しました。実装を変更する必要はおそらくないでしょう。クラスは（Phaser.Spriteタンクのように動作するように制限された方法でを移動します）。 次に、YAGNIのアイデアについて数年前に読んだことを覚えています。これは基本的に、コードを過度に設計して、決して使用しない可能性があるものを含めるべきではないということです。 ベストプラクティスに従って、すべてのクラスがインターフェイスを実装する必要がありますか、それとも将来的にスワップアウトされる可能性があると予想されるクラスに限定する必要がありますか？

10 object-oriented-design  interfaces  patterns-and-practices 

：私はクラスの持っているA、小さなクラスの数の複合体であるB、CとD。 B、C、およびDインターフェースを実装IB、ICおよびIDそれぞれ。 以来Aのすべての機能をサポートB、CおよびD、A実装IB、ICおよびID同様に、しかし、多くのこの残念ながらリードの実装で再ルーティングA そのようです： interface IB { int Foo {get;} } public class B : IB { public int Foo {get {return 5;}} } interface IC { void Bar(); } public class C : IC { public void Bar() { } } interface ID { string Bash{get; set;} } public …

10 c#  design-patterns  patterns-and-practices  composition 

設計している次の機能のパターンまたはアーキテクチャガイダンスを探しています。基本的に、これは複数のエクスポートターゲットを備えたエクスポート機能であり、新しいエクスポートターゲットをプラグインする際に多くのコア変更を必要としない場合に十分に汎用的にする方法を探しています。エクスポートターゲットでは、PDF、PowerPointプレゼンテーション、Wordドキュメント、RSSなど、さまざまな種類の出力を単に参照しています。JSONとXMLで表されるデータの基本セットがあります。このデータは、画像（任意の数またはエクスポートタイプ（PNG、JPG、GIFなど）を使用）、グラフ、テキスト表現、表などを作成するために使用されます。 私は、すべてのレンダリングとレイアウトを、さらにエクスポートターゲットの追加を処理するある種のレンダリングまたはレイアウトエンジンに抽象化する方法を見つけようとしています。これにどのように取り組むかについてのヘルプ/提案/リソースは大歓迎です。前もって感謝します。 私が達成しようとしていることを図で表したもの。

10 patterns-and-practices  architectural-patterns 

私の新しいプロジェクトでは、TDDを試すことにしました。そして、最初に問題が発生しました。アプリケーションで最初にしたいことは、データソースからデータを読み取る機能を提供することです。この目的のために、私はリポジトリパターンを使用したいと思います。そしていま： テストがリポジトリー・インターフェースの実際の実装を対象としている場合、私はデータベースにアクセスできるクラスをテストしますが、それは避けなければならないことを知っています。 テストがレポジトリパターンの実際の実装ではない場合、私はうまくテストします...ただ模擬します。これらの単体テストでテストされる製品コードはありません。 私はこれを2日から考えていますが、それでも適切な解決策を見つけることはできません。私は何をすべきですか？

10 tdd  patterns-and-practices  repository 

私のプログラムの一部は、データベース内の多くのテーブルと列からデータをフェッチして処理します。一部の列はである可能性がありますがnull、現在の処理コンテキストではエラーです。 これは「理論的には」発生しないはずなので、発生する場合は、不良データまたはコード内のバグを示しています。エラーの重大度は、フィールドによって異なりnullます。つまり、一部のフィールドでは処理を停止して誰かに通知する必要があり、他のフィールドでは処理を続行して誰かに通知するだけにする必要があります。 まれですが可能なnullエントリを処理するための優れたアーキテクチャまたは設計原則はありますか？ ソリューションはJavaで実装できるはずですが、問題は言語にとらわれないため、タグを使用しませんでした。 私自身が持っていたいくつかの考え： NOT NULLの使用 最も簡単なのは、データベースでNOT NULL制約を使用することです。 しかし、データの元の挿入がこの後の処理ステップよりも重要である場合はどうなりますか？そのため、挿入がnull（バグまたは何らかの正当な理由のために）テーブルに挿入される場合、挿入が失敗しないようにします。プログラムのさらに多くの部分が挿入されたデータに依存しているが、この特定の列には依存していないとしましょう。そのため、挿入ステップではなく、現在の処理ステップでエラーが発生する危険を冒したいのです。それが、NOT NULL制約を使用したくない理由です。 単純にNullPointerExceptionに依存 常にそこにあると期待しているかのようにデータを使用し（実際にそうであるはずです）、結果のNPEを適切なレベルでキャッチします（たとえば、現在のエントリの処理は停止しますが、処理全体は進行しません） ）。これは「フェイルファースト」の原則であり、私はしばしばそれを好みます。少なくともバグの場合、ログに記録されたNPEを取得します。 しかしその後、さまざまな種類の欠落データを区別する能力が失われます。たとえば、一部の欠落しているデータについては除外することができますが、他の場合は処理を停止して管理者に通知する必要があります。 null各アクセスの前に確認し、カスタム例外をスローする カスタム例外を使用すると、例外に基づいて正しいアクションを決定できるため、これは進むべき道のようです。 しかし、どこかで確認するのを忘れた場合はどうなりますか？また、私はコードを、まったくまたはほとんど期待されない（そしてビジネスロジックフローの一部ではない）nullチェックで混乱させます。 この方法を選択した場合、どのパターンがアプローチに最適ですか？ 私のアプローチについての考えやコメントは大歓迎です。また、あらゆる種類の優れたソリューション（パターン、原則、私のコードまたはモデルの優れたアーキテクチャなど）。 編集： 別の制約があります。ORMを使用してDBから永続オブジェクトへのマッピングを行うため、そのレベルでnullチェックを実行しても機能しません（nullが害を及ぼさない部分で同じオブジェクトが使用されるため）。 。これまでに提供された回答の両方がこのオプションについて言及したため、これを追加しました。

9 design-patterns  object-oriented-design  database-design  patterns-and-practices  null 

ycombinatorによる最近の記事に、優れたプログラマーの原則を伴うコメントがリストされています。 #7.良いプログラマー：コードを最適化します。優れたプログラマー：データを構造化します。最高のプログラマー：違いは何ですか？ 主観的で論争のある概念を認める-これが何を意味するかについて誰かが立場を持っていますか？私はそうしますが、私は後でこの質問を自分の考えで編集して、回答の素因を作らないようにしたいと思います。

9 programming-practices  source-code  data  patterns-and-practices 

ある日、未使用の変数の警告を消去していましたが、熟考し始めました。それらの問題は何ですか？ 実際、それらの一部はデバッグにも役立ちます（例：例外の詳細を調べる、または返される前に戻り値を確認する）。 私はそれらを持っていることで本当の実際のリスクを見つけることができませんでした。 例 次のような他のプログラマーの注意を引く時間がかかる行を意味するのではありません。 int abc = 7; それは明らかな冗長性と注意散漫です。私は次のようなものを意味します： try { SomeMethod(); } catch (SomeException e) { // here e is unused, but during debug we can inspect exception details DoSomethingAboutIt(); }

9 programming-practices  coding-style  patterns-and-practices  warnings 

Haskellでは、タイプa -> Maybe bを使用して、タイプの値を返すかb、何も返さない（失敗する）関数をモデル化できます。 私がタイプしている場合a1, ..., a(n+1)や機能f1, ..., fnを持つ、fi :: ai -> Maybe a(i+1)すべてのためにi、1 <= i <= n私は使用して機能をチェーンできる>>=のオペレータMaybeモナドと書き込みを： f1 x >>= f2 >>= f3 >>=... >>= fn >>=各関数があれば、その前身は、意味のある値を返したように適用されていることをオペレータを確実にします。チェーン内の関数が失敗するとすぐに、チェーン全体が失敗し（戻り値Nothing）、チェーン内の以降の関数は評価されません。 同じ入力で複数の関数を試し、1つの関数が成功したらすぐに戻りたいという似たようなパターンがあります。すべての関数が失敗すると（return Nothing）、計算全体が失敗します。より正確には、私には関数がf1, ..., fn :: a -> Maybe bあり、関数を定義します tryFunctions :: [a -> Maybe b] -> a -> Maybe b tryFunctions [] …

9 functional-programming  haskell  patterns-and-practices 

私が以下を持っているとしましょう： package me.my.pkg; public interface Something { /* ... couple of methods go here ... */ } そして： package me.my; import me.my.pkg.Something; public class SomeClass implements Something { /* ... implementation of Something goes here ... */ /* ... some more method implementations go here too ... */ } つまり、インターフェースを実装するクラスは、実装するインターフェースよりもパッケージ階層のルートの近くにありますが、どちらも同じパッケージ階層に属しています。 …

9 java  api-design  patterns-and-practices  anti-patterns 

背景から始めるために、この投稿はCSRFトークンについてJeff Atwoodが述べたものです。このページで、彼は続けて言っています： さらに強力ですが、より複雑な防止方法は、サーバーの状態を活用することです。つまり、クライアントに送信するすべてのHTMLフォームに対して一意のランダムキーを生成（およびタイムアウト付きで追跡）します。Stack Overflowでこのメソッドのバリアントを使用して、大きな成功を収めています。 しかし、この投稿自体では、Jeffはトークンをいつ、どのように更新する必要があるかについて決してコメントしていません。 私が取り組んでいるWebアプリで同様のテクニックを使用していました。それはこのように動作します： ユーザーがPOSTサーバーにデータを送信するたびに、csrfトークンが送信されます。 このCSRFトークンは、ユーザーのセッションで暗号的に強力なCookieに保存されます。 トークンが有効な場合は、ユーザーのリクエストが処理され、逆の場合も同様です。 リクエストが有効な場合は、サーバー側の古いトークンを破棄し、新しいトークンを作成します。サーバーからの応答には、次の要求で使用される新しいcsrfトークンが含まれています。ページ上のすべてのフォームの古いトークンが新しいトークンで更新されるため、次のリクエストが適切に処理されます。 トークンを更新してからPOSTリクエストするのが賢明ですか、それともユーザーがGETリクエストを行ったときにのみ更新を行い、次のGETリクエストが行われるまで同じトークンを保持する必要がありますか？

9 web-development  programming-practices  security  patterns-and-practices