タグ付けされた質問 「design」

今日、私の同僚が私のコードをレビューし、設定のみのプロパティを削除して、代わりにメソッドを使用することを提案しました。 私たち2人は他のことで忙しかったので、Property Design「フレームワークの設計ガイドライン」の本のセクションを見るように言われました。本の中で作家はただ避けようと言った： ゲッターよりも広いアクセシビリティを持つセッターを持つプロパティ そして今、私はなぜそれがセットオンリープロパティを持つことが推奨されないのか疑問に思っていますか？誰かが私のために明確にできますか？

9 design  code-quality  code-reviews  code-smell 

ここで問題に直面しています。顧客が正確なサイトをコピーするように私に頼みました、そして私が彼に新しいデザインに行くことを彼に説得しようとしているのに彼はそれを受け入れません。彼はこのデザインをとても愛しています（余談ですが、それは恐ろしくて時代遅れですが、私は彼にそれを言わないでしょう！） これについて話し合ってから数週間になりますが、どうすればよいかわかりません。同様の経験がありますか？私は顧客を失いたくありません、彼はよく支払い、彼の仕事は本当に簡単です。同時に、他人の作品に自分の署名をしたくありません。 助言がありますか？同様の経験？ありがとうございました！

9 design  ethics 

Webページのレイアウトには何を使用しますか？パーセンテージまたはピクセル？ いつ他のものを使うべきですか？

9 web-development  design  websites 

コードポイントや文字ではなく、Unicode書記素クラスタの文字列を表す文字列クラスがないのはなぜでしょうか。ほとんどのアプリケーションでは、プログラマーが必要なときに書記素のコンポーネントにアクセスする方が、コードポイントからコンポーネントを整理する必要があるよりも簡単であるように思えます。 （少なくとも理論的には）。内部的に文字列クラスは、UTF-8、UTF-16などの可変長エンコーディングを使用する場合があります。この場合、UTF-32も可変長です。または、それらすべてのサブクラスを実装します（オプションで、実行時に選択肢を構成して、さまざまな言語が最適なエンコーディングを使用できるようにします）。しかし、プログラマーが文字列を検査するときに書記素ユニットを「見る」ことができれば、

9 programming-practices  design  strings 

私のプログラムは、最初から最後まで一連のステップを実行する必要があります。ただし、異なる入力に基づいて開始点は異なります。たとえば、最初のステップから最後まで実行されるもの、2番目のステップから最後まで実行されるもの、3番目から最後まで実行されるものなどがあります。 シンプルなデザインが必要ですが、現在は次のようなフォールスルースイッチを使用しています。 switch (step) { case 1: //do the 1st step //fall through, so no break here case 2: //do the 2nd step //fall through case 3: //do the 3rd step //fall through ... } それは機能しますが、フォールスルーコードは常に私を不快にします。それを行うためのより良い簡単な方法はありますか？

9 design  design-patterns  coding-style  clean-code  switch-statement 

マイクロサービスアーキテクチャに基づいてアプリケーションを設計しています。 このアプリケーションでは、Authマイクロサービスが必要です。 また、おそらく複数のアドレス、アバター画像などの追加のユーザー情報を保存する必要があります これにより、2つのマイクロサービス（1つは認証用、もう1つはユーザー用）を持つというアイデアにつながります。 これまでのところ、私は次のアイデアを持っています： 認証サービスが、追加のアドレス（おそらくアバターなど）を含むユーザー情報を保持するリソースサーバーになることも許可します。これは、ユーザーに関連するすべてを1か所にまとめて、新規登録などの操作の複雑さを軽減できるので、便利なソリューションです。ユーザー、ユーザーの削除。ただし、このソリューションはマイクロサービスの概念と矛盾しているようですが、私にとっては、このソリューションが最も魅力的です 2つの異なるマイクロサービス-認証とユーザー。Authはトークンの処理のみを担当し、ユーザーに関連するデータは保存しません。トークンのリクエストが受信されると、Authサービスはユーザーを呼び出してユーザーデータを受信し、決定を行います 2つの異なるマイクロサービス-認証とユーザー。Authはトークンの処理を担当し、認証に関連するユーザー情報の一部（おそらくパスワード、ロール）も格納します。ユーザーサービスは、追加のアドレス、アバターなど、他のすべての情報を保持します。この方法は、複雑なユーザーの削除/新しいユーザーの作成操作を必要とするため、複雑すぎるようです さて、これらの解決策の1つを選択する必要がありますが、迷っていて、どれが正しい解決策なのかわかりません。 これに関するアドバイスをいただければ幸いです。 ありがとう

9 design  architecture  microservices  authentication 

多くのビジネスロジックを処理する新しいアプリケーションを設計しています。 時間の経過とともにこのようなシステムに潜入することが多い、さまざまなアプリケーションレイヤー間の通常の絡み合いを回避するために、最初から問題の明確な分離を実装したいと思います。大まかに言えば、私は分離したいです： プレゼンテーション層 ビジネスロジックレイヤー データストレージと永続化レイヤー 私が最も苦労しているのは、特にビジネス層とデータ層の間で、実際にエッジで動作をきれいに実装する方法です。データレイヤーがORMオブジェクトをコアレイヤーに渡し、ビジネスロジックをORMに効果的に密結合するアプリケーションが多すぎます。 ORMオブジェクトをシリアル化された形式（JSON？）に変換してから、ビジネスレイヤーでそれを非シリアル化して、そのレイヤー内部のデータ構造にする必要がありますか？それは多くのオーバーヘッドではありませんか？ 中規模アプリケーションの懸念の分離をきれいに実装するにはどうすればよいですか？何かアドバイス？

9 design  separation-of-concerns  modularization 

いくつかのイベントを解析してSTDIN「実行」するシミュレータを構築しています。私のバックグラウンドは、最近のほとんどが関数型プログラミングであるため、次のようなことをするのは自然なことのようです。 data Event = Thing1 String Int | Thing2 Int | Thing3 String String Int Parse :: String -> [Event] Simulate :: [Event] -> [Result] シミュレートする場所 case event of Thing1 a b => compute for thing one | Thing2 a => compute for thing two などJavaでこの種のことをする慣用的な方法は何ですか？グーグルで私はネストされたクラスとビジターパターンの方向を指摘されましたが、私の試みではそれはかなり重いようです。型消去は、私と一生懸命戦っているようです。正しく行われるように見えるものの概要を教えていただけますか？

9 java  design  visitor-pattern  pattern-matching 

多くの場合、MVCを使用してプログラムを設計すると、コントローラーが半分の時間無駄になります。 つまり、ビューで何かが発生します（ボタンのクリックなど）。次に、ビューはコントローラーに通知します。次に、コントローラーはモデルに直接委任し、何もする必要がないため、他に何もしません。 例えば： ユーザーはボタン「カラーブルー」を押します>ビューはコントローラーに通知しますcontroller.colorBlue()>コントローラーはモデルに通知しますmodel.colorBlue()>モデルの色が何か青いです。 この例では、コントローラーは役に立たないようです。それは何も追加しません。ビューはモデルに直接話しかけたかもしれません。 ただし、残りの半分の時間は、コントローラーがビューとモデルの間で何らかのメディエーションを行います。 私の質問はこれです：これはMVC構造でどのくらい一般的ですか？コントローラの半分の時間が不要であるように見えるのは理にかなっていますか？それともこれは問題ですか？これは一般的ですか？私はこれにどのように取り組むべきですか？ 私の質問が十分に明確でない場合は、そのように言ってください。

9 design  object-oriented  mvc 

私は現在、ロールバック機能を処理する必要のあるアプリケーション（基本的には、ユーザー定義のジョブを実行し、リアルタイムで出力を生成できる一種の実行エンジン）に取り組んでいます。それは奇妙に聞こえるかもしれませんが、アプリケーションでそのようなことをすることは可能ですか？レベル？たとえば、一部のユーザーがジョブJ1を実行しようとし、実行を開始した後、編集/変更したいと考えた場合、つまり、現在実行中のジョブを 強制終了する必要があることを意味します。これまでに実行されたすべてのアクションを元に戻し、再度実行する必要があります。 ジョブJ1を再度実行します 私の頭に浮かぶいくつかのことは、とにかくアプリケーションの状態をどこかで何らかの形で保存または維持してから、以前の保存ポイントと共にロールバックスタッフを呼び出す必要があるということです。私はDBレベルのロールバックに関する記事をいくつか読んでいましたが、リアルタイム環境で作業する必要があるため、シナリオはこの場合には適合しません。 しかし、どのように進めるか、他に何を考慮に入れるべきかについて、適切なアプローチを見つけることができません。これが不明瞭に聞こえる場合はお知らせください。可能であれば詳細をお知らせします。 ヘルプやアドバイスはありますか？

9 design 

一度だけインスタンス化されるクラスを作成するのは悪いコーディングの実践/設計ですか？ 私はいくつかの変数と関数をクラスの下でグループ化して「見栄え」を良くするために（より良い説明がないため）いくつかの変数と関数を持っていますが、それらは単にグローバル変数とグローバル関数にすることができます。 （ところで、私はJavaScript、AngularJS、Express、MongoDBを使用しています。）

9 design  design-patterns 

のclass XFactoryオブジェクトを作成するファクトリがありますclass X。のインスタンスXは非常に大きいため、ファクトリの主な目的は、クライアントコードに対してできるだけ透過的にインスタンスをキャッシュすることです。のオブジェクトclass Xは不変であるため、次のコードは妥当なようです。 # module xfactory.py import x class XFactory: _registry = {} def get_x(self, arg1, arg2, use_cache = True): if use_cache: hash_id = hash((arg1, arg2)) if hash_id in _registry: return _registry[hash_id] obj = x.X(arg1, arg2) _registry[hash_id] = obj return obj # module x.py class X: # ... それは良いパターンですか？（実際のファクトリーパターンではないことはわかっています。）変更すべき点はありますか？ …

9 design  design-patterns  python  caching  persistence 

UMLにはダイアグラムのジャングルがあります。 プロファイル図、クラス図、パッケージ図... ただし、（IMHであり、かつ経験不足ではない）Oでは、すべての図を実行するのはやり過ぎです。 したがって、どのUML図がWebコンテキスト、より具体的にはブログに適しているか（ゼロから作成したい）。 私がUMLダイアグラムを使用したからといって、コードが素晴らしくて見事であるとは限らないことを理解しています...

9 web-development  design  uml 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 8か月前に閉鎖。 私のマネージャーは最近私を「ソフトウェアデザイナー」に昇進させました。このタイトルが存在することを知りません。私の知る限り、SAは高レベルのコード設計を作成し、図を作成します。 高レベルのコード設計を理解するのに苦労しています。私のマネージャーによると、すべてのクラスとそれらのクラス内のすべてのメソッドを設計する必要があります。つまり、コード構造全体を設計し、チームに各関数またはクラスの機能を実装させます。たとえば、CRUDシステムでは、どの関数を使用するか、どのクラスを作成するかを計画できるはずです。 私のソフトウェア設計の経験を考えると、これを実行することは非常に不可能であることがわかりました。開発者として、私は常に自分のクラスを作成し、自分の関数を定義して実装しています。他の人のために機能を設計した経験はありません。 私の質問は： これは一般的ですか？非常に大規模なシステムの場合、コードベースは常に変更されませんか？ これはできますか？ ここでは明白で愚かな質問をしているのかもしれませんが、私はこれまで常に正規の開発者であり、システム全体の設計経験はありません。

8 design  teamwork  software  architect 

私はこの方法でこの質問をします-私のREST APIを「正しい」方法で実装しないことのソフトウェアエンジニアリングの懸念は何ですか？ 「正しい」方法とはどういう意味ですか？まあ、私が正しい方法についての私の認識を説明できるようにしてから、私がそれをどのように行っているかを説明します（また、JSON REST APIについて話していると仮定します）。 正しい方法 無国籍。これは私が得る部分です。クライアントは常に100％いつまでも状態を維持します。それはサーバーの仕事ではなく、クライアントの仕事です。 各動詞の予想されるアクションと応答： GET-完全に指定されたリソースを取得します。リクエストの承認またはクエリパラメータのいずれかによってのみ制限されます。これにより、プロセス内のリソースが変更されることはありません。 POST-リソースの説明全体（JSONオブジェクトなど）を指定すると、リソースを作成し、日付やIDなどのサーバー側のプロパティも作成してそのリソースを返します。 DELETE-指定されたリソースを削除し、応答として何らかの200 OKのみを与えます PUT -指定されたオブジェクト全体宣言入力として、入力で与えられたフィールドのそれぞれにリソースのすべてのフィールドを更新し、特定の場所でリソースを更新します。明確にするために、これはオブジェクト全体が入力として渡されることを期待しています。更新されたリソース全体が、すべてのフィールドとともに（許可またはその他の入力フラグに従って）返されます。 PATCH-リソースの変更が必要なフィールドのみを指定して、入力として指定された指定されたリソースのフィールドのみを更新します。（これは私が不明瞭なところです）：リソース全体が返されますか？（または、更新されたフィールドだけですか？Dunno。気にしないでください。） リソースパス。リソースの相互関係を考えると、リソースパスは次のいずれかになります。 / parentresource /：id / parentresource /：id / childresource / parentresource /：id / childresource /：childId / parentresource /：id / childresource /：childId / subresource /：subresourceId（この例では、サブリソースは、親リソースに属する子リソースに属しています）。 やりたいこと 上記は、REST APIがどのように機能するかについての私の理解です。次に、上記のバリエーションのいくつかをリストします。 PUT / PATCH-変更のためにリソース全体を渡すポイントは何ですか？リソースの変更にはPUTのみを使用し、更新するフィールドのみを渡します。その結果、パッチを使用する必要はありません リソースパス-アプリケーションでGUIDを使用しています。その結果、それらは世界的にユニークになります。単独でサブリソースを一意に参照できるのに、親リソースを含む完全なリソースパスが必要なのはなぜですか？以下のような： /サブリソース/：subresourceId ：もし私のような完全なパスが必要となるサブリソースを参照しようとし、それを「正しい」やり方をやっていた / parentresource …

8 design  rest  api  standards