ソフトウェア工学

データベースにアクセスするために、約50のメソッドを持つ大きなインターフェースを使用しています。インターフェイスは私の同僚によって書かれました。これについて話し合いました： 私：50の方法は多すぎます。コードの匂いです。 同僚：それについて私は何をすべきか？あなたはDBアクセスを望んでいます-あなたはそれを持っています。 私：ええ、でもそれは不明確で、将来的にはメンテナンスが困難です。 同僚：わかりました、そうです、それは良くありません。インターフェイスはどのように見えるべきですか？ 私：それぞれ10個のメソッドを持つオブジェクトを返す5つのメソッドはどうでしょうか？ うーん、でもこれは同じでしょ？これは本当により明確になるでしょうか？努力する価値はありますか？ 時々、インターフェースが必要な状況にあり、最初に頭に浮かぶのは、1つの大きなインターフェースです。これの一般的なデザインパターンはありますか？ 更新（SJuanのコメントに対応）： 「メソッドの種類」：データベースからデータを取得するためのインターフェースです。すべてのメソッドの形式は（疑似コード）です。 List<Typename> createTablenameList() メソッドとテーブルは厳密には1対1の関係にあるわけではなく、常にデータベースから得られるある種のリストを取得するという事実に重点が置かれています。

9 design  c++  interfaces 

.NETにはIObservableおよびIObserverインターフェイスがあります（こことここも）。興味深いことに、IObserverの具体的な実装は、IObservableへの直接参照を保持していません。誰が購読しているかはわかりません。購読解除者のみを呼び出すことができます。「登録を解除するにはピンを抜いてください。」 編集：購読解除者はを実装しIDisposableます。この方式は、リスナーの失効問題を防ぐために使用されたと思います。 しかし、2つのことは完全に明確ではありません。 内部のUnsubscriberクラスはsubscribe-and-forget動作を提供しますか？誰が（正確にはいつ）登録IDisposable.Dispose()解除者を呼び出すのですか？ガベージコレクター（GC）は確定的ではありません。 [免責事項：全体として、私はC＃よりもCおよびC ++に多くの時間を費やしました。] オブザーバーKをオブザーバブルL1にサブスクライブし、オブザーバーが他のオブザーバブルL2にすでにサブスクライブしている場合はどうなりますか？ K.Subscribe(L1); K.Subscribe(L2); K.Unsubscribe(); L1.PublishObservation(1003); L2.PublishObservation(1004); このテストコードをMSDNの例に対して実行したとき、オブザーバーはL1にサブスクライブしたままでした。これは実際の開発に特有のものです。潜在的に、これを改善する3つの方法があります。 オブザーバーがすでにサブスクライブ解除インスタンスを持っている（つまり、すでにサブスクライブしている）場合、オブザーバーは新しいプロバイダーにサブスクライブする前に、元のプロバイダーから静かにサブスクライブ解除します。このアプローチにより、元のプロバイダーにサブスクライブされなくなったという事実が隠されます。これは、後で驚くかもしれません。 オブザーバーがすでにサブスクライブ解除インスタンスを持っている場合は、例外がスローされます。正常に動作する呼び出しコードは、オブザーバーを明示的にサブスクライブ解除する必要があります。 オブザーバーは複数のプロバイダーにサブスクライブします。これは最も興味深いオプションですが、IObservableとIObserverで実装できますか？どれどれ。オブザーバがサブスクライバオブジェクトのリストを保持することは可能です：ソースごとに1つ。残念ながら、IObserver.OnComplete()それを送信したプロバイダーに戻って参照を提供していません。したがって、複数のプロバイダーを使用するIObserver実装は、どのプロバイダーからサブスクライブを解除するかを決定できません。 .NETのIObserverは、複数のIObservableをサブスクライブすることを目的としていましたか？ テキスト形式のオブザーバーパターンの定義では、1人のオブザーバーが複数のプロバイダーにサブスクライブできる必要があるか？それともオプションで実装に依存していますか？

9 .net  observer-pattern 

適切に実行するために環境変数を設定する必要がある何かのためのパッケージを書いています。パッケージマネージャーのインストール手順でユーザーの環境を変更する必要がありますか、それともユーザーに自分で変更するように促すだけですか？私の直感は後者ですが、私は前者の議論を見ることができます。

9 installer  environment  package-managers 

マルチパートフォームを2回解析する必要があります。1回は入力フィールドを取得し、後でファイルのアップロードを処理します。 私は私のノードアプリ内で懸念の適切な分離を維持しようとしています： コントローラーは、入力フィールドの処理を担当します。 モデルは、ファイルのアップロードロジックを担当します。 新しいインスタンスを作成するためにフィールドデータをモデルに渡す必要があるため、ファイルのアップロードを開始する前にフィールドデータを利用できるようにする必要があります。 現在、すべてform.parse()または同等の関数がフィールドとファイルの両方を一緒に解析しています。例：req.pipe(busboy)ファイルとフィールドの両方を一緒に処理します。 私はnode-multiparty、手ごわい、busboy、multerなどのモジュールをチェックしました。これに対する解決策は誰にもないようです。 私が達成したいものの例はここにあります：https : //stackoverflow.com/questions/22336177/node-js-busboy-parse-fields-and-files-seperatly これは可能ですか？

9 data  node.js  upload 

私のWebアプリケーションの設計について深刻な疑いがあります。 ビジネスロジックをインターフェイスから分離したかったので、データベースへのすべての要求を処理するWeb APIを作成しました。 これは、エンティティフレームワークと作業ユニットおよび汎用リポジトリパターンを備えたASP.NET Web APIです。これまでのところ、すべてが良好です。 問題 ヘルプが必要なのは、APIとアプリケーションの間でオブジェクトを共有する効率的な方法がわからない場合です。 エンティティオブジェクトを直接シリアル化したくありません。エンティティモデルが変更された場合、理由もなく大きなオブジェクトをシリアル化してしまう可能性があるため、これは悪い習慣だと思いました。 現在どのように実装されているか インターフェイスはC＃のASP.NET Webアプリケーションであり、APIはC＃であるため、共有したいすべてのクラスの定義を含む共通ライブラリを作成しました。 私はAndroidアプリを開発するときにソリューションが機能しないことを知っています。Javaでクラスを再度作成する必要がありますが、それは私の最大の問題ではありません。 問題は、常にオブジェクトを変換しているような気がすることです。 例 これが私のワークフローの例です： すべてのオブジェクトとフォームのデータ注釈を含むモデルから始め、ユーザーはそのモデルをコントローラーにPOSTします。 コントローラーでは、このモデルを共通ライブラリーのクラスに変換してから、そのオブジェクトをAPIに送信する必要があります。 次に、私のAPIのコントローラーが呼び出しをキャッチし、そのオブジェクトをエンティティオブジェクトに変換して、データベースを更新します。 だから私は3つのクラスを持っています 検証用のすべてのデータ注釈を含むビューのモデル（クライアント） オブジェクトを共有するための共通ライブラリクラス（DLL） エンティティークラス（API） 何か間違ったことをしているような気がします。よりエレガントなものはありますか？プロジェクトが大きくなりすぎる前に、この問題に対する適切な解決策があることを確認したいと思います。

9 design  design-patterns  web-development  web-api 

次の拡張メソッドがあります。 public static IEnumerable<T> Apply<T>( [NotNull] this IEnumerable<T> source, [NotNull] Action<T> action) where T : class { source.CheckArgumentNull("source"); action.CheckArgumentNull("action"); return source.ApplyIterator(action); } private static IEnumerable<T> ApplyIterator<T>(this IEnumerable<T> source, Action<T> action) where T : class { foreach (var item in source) { action(item); yield return item; } } シーケンスの各アイテムにアクションを適用してから、それを返します。 このメソッドにPure（Resharperアノテーションからの）属性を適用する必要があるかどうか疑問に思っていました。そのためと反対の引数を確認できます。 長所： …

9 c#  pure-function 

通常、イベントリスナーは、それらを登録したオブジェクトよりも長く存続するべきではありません。 それは、イベントリスナーがデフォルトで弱参照によって保持されるべきであることを意味しますか（オブジェクトリスナーが登録されている弱コレクションに格納されます）？ リスナーがその作成者よりも長生きする必要がある有効なケースはありますか？ それとも、そのような状況は間違いであり、許可されるべきではないのですか？

9 api-design  event 

一部のコンテンツ（テキスト、料金プランなどのビジネスロジック）を社内で簡単に編集できるようにしたいDjangoベースのWebサイトがあるため、コードベースの外部に保存することにしました。通常、理由は次のいずれかです。 これは、技術者でない人が編集したいものです。1つの例は、Webサイトのコピーライティングです。プログラマーは、デフォルトで "Lorem ipsum ..."になるテキストを含むテンプレートを準備し、実際のコンテンツは後でデータベースに挿入されます。 これは、新しいコードをデプロイする必要なく（現在は週に2回）迅速に変更できるようにしたいものです。例としては、さまざまな価格階層の顧客が現在利用できる機能があります。これらをハードコーディングする代わりに、データベースから読み取ります。 説明されているソリューションは柔軟ですが、私がそれを気に入らない理由がいくつかあります。 コンテンツはデータベースから読み取る必要があるため、パフォーマンスのオーバーヘッドがあります。 キャッシングスキームを使用してこれを軽減しますが、これによりシステムが多少複雑になります。 コードをローカルで実行する開発者は、本番環境での実行方法と比較して、システムを大幅に異なる状態で認識します。自動テストでは、システムを別の状態で実行します。ステージングサーバーでの新機能のテストなどの状況も複雑になります。ステージングサーバーにデータベースの最新のコピーがない場合、それは本番環境とは予期せず異なる場合があります。 新しい状態をリポジトリにコミットすることで（たとえば、データの移行を追加することで）軽減できますが、それは間違ったアプローチのようです。それは...ですか？ これらの問題を解決するための最良のアイデアはありますか？私が見落としているコンテンツを処理するためのより良いアプローチはありますか？

9 django  repository  content-management 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 5年前休業。 私はオブジェクトの概念を理解しており、Javaプログラマーとして、OOパラダイムは実際にはかなり自然に生まれてくると感じています。 しかし最近、私は自分自身が考えていることに気づきました。 ちょっと待ってください、実際に静的クラスを使用するよりもオブジェクトを使用することの実際的な利点は何ですか（適切なカプセル化とOOプラクティスで）。 オブジェクトを使用することの2つの利点を考えることができます（どちらも重要で強力です）。 ポリモーフィズム：実行時に動的かつ柔軟に機能を交換できます。また、システムに新しい機能「パーツ」と代替手段を簡単に追加することもできます。たとえばCar、Engineオブジェクトを操作するように設計されたクラスがあり、Carが使用できるシステムに新しいエンジンを追加したい場合、新しいEngineサブクラスを作成して、 このクラスのオブジェクトをオブジェクトに渡すだけで済み Carます。について何かを変更しCarます。そして、実行時にそうすることを決定できます。 「機能を渡す」ことができる：システムの周りにオブジェクトを動的に渡すことができます。 しかし、静的クラスよりもオブジェクトに他の利点はありますか？ 多くの場合、新しい「パーツ」をシステムに追加するときは、新しいクラスを作成し、そこからオブジェクトをインスタンス化します。 しかし、最近立ち止まって考えたところ、静的クラスは、オブジェクトを通常使用する多くの場所で、オブジェクトとまったく同じように機能することに気付きました。 たとえば、アプリにファイルの保存/読み込みメカニズムを追加する作業をしています。 オブジェクトを使用すると、コードの呼び出し行は次のようになります。 Thing thing = fileLoader.load(file); 静的クラスを使用すると、次のようになります。 Thing thing = FileLoader.load(file); 違いは何ですか？ かなり古いことですが、私は、昔ながらの静的クラスがまったく同じように動作するときに、オブジェクトをインスタンス化する理由を考えることができません。しかし、OOシステムでは、静的クラスはほとんどありません。だから私は何かを逃しているに違いない。 リストした2つのオブジェクト以外のオブジェクトには、他に利点がありますか？説明してください。 編集：明確にします。機能を交換したり、データを渡したりするときに、オブジェクトは非常に便利です。たとえば、メロディーを構成するアプリを作成しました。MelodyGenerator異なる方法でメロディーを作成するいくつかのサブクラスがあり、これらのクラスのオブジェクトは交換可能でした（Strategyパターン）。 メロディーもオブジェクトを渡すことができたので便利です。コードとスケールもそうだった。 しかし、システムの「静的な」部分についてはどうですか？それは渡されません。たとえば、「ファイルを保存する」メカニズムです。静的クラスではなくオブジェクトに実装する必要があるのはなぜですか？

9 design  object-oriented  class  static 

私は個人的なプロジェクトにgitを使用しているので、Gitで問題に遭遇したことはありませんが、今日は職場で議論があり、そのことについて私は考えていませんでした。 TFSでは、変更セットをシェルブセットに格納できます。このシェルブセットは、他の開発者、たとえばピアレビューのために表示できます。 私がgithubで理解していることから、あなたはリポジトリのローカルコピー（おそらく、異なる機能のカスタムブランチを使用）に取り組んでおり、ピアレビューのポイントになります。ローカルリポジトリの特定の変更を他の人とどのように共有しますか？

9 git  team-foundation-server 

私の理解では、デイリースクラムミーティングは非常に迅速で、親しみやすい方法で開催する必要があり、すべてのチームメンバーが出席する必要があります。なぜなら、それは他の誰もが行っていることを誰もが最新の状態にすることであるからです。 そのように開催されるスクラムデイリーミーティングが好きです。 私の最新のプロジェクトでは、デイリースクラムはステータス更新会議のようなものです。立場は私たちがスクラムを保持し、適切なアジャイルを実践しているということですが。 私たちは2つの異なる国に分散したチームであり、同じ国にいる人々は同じオフィスにいません。結果として、仮想スクラムがあります。 問題は、ミーティングが常に時間どおりに開始され、実際の開始時間の前に多くの人が電話をかけるため、実際にはミーティングの最初の1秒から開始されることです。小さな遅延に対する許容度なし。 たとえば、前回電話に出たときに、会議の調整担当者が全員がオンかどうかを確認し、チームメンバーの1人がまだオンではないが、彼が電話していたと言いました。そして、チームメンバーを待たずに共有を開始するように言われました。 また、誰もが多くの会議を行っており、スクラム会議と連続していることもあるため、会議の最初または2分の間に到着したかどうかは理解できます。 デイリースクラムを練習しているチームにとってそれは正常ですか？初めてのことです。 それについて直接書誌を見つけることはできません。すべてのチームメンバーの存在が強調されますが、会議は常に同時に開始する必要があることも強調されます。しかし、私は少しの許容誤差があると想像します。 私は誰かが "5秒"遅れて到着した場合にスクラムマスターがペナルティを課すことができることを示唆している誰かをブログで読みました。私はスクラムは友好的であるはずだと思っていました、そしてそのようなペナルティを持つことは逆効果に思えます。 このような状況で推奨されるアプローチは何ですか？

9 agile  scrum 

ヘルパー関数の推奨アプローチは何ですか？1つの手法を選択し、それを実行して新しい「クラス」を作成します。 ここに私が考えたデザインオプションがあります： オプション1：外部スコープのヘルパー関数、インスタンスのコンテキストで呼び出す function createPane (pane) { // logic to create pane var proto = Object.create(this.paneList); $.extend(paneProto, pane); return paneProto; } Panes.prototype.initialize = function (panes) { var _this = this; _.each(panes, function () { _this.panes.push(createPane.call(_this, this)); }); } 長所：単純な構文。createPaneインスタンスで公開されていません。 短所： createPane他のスコープでアクセスできます。 オプション2：クロージャー内のヘルパー関数、インスタンスのコンテキストで呼び出す Panes.prototype.initialize = (function () { function createPane (pane) …

9 object-oriented  javascript 

JavascriptのアプローチのようなMVCを使用してキャンバスアプリケーションを構造化/構築する方法を理解するのが困難です。UIはかなり流動的でアニメーション化され、ゲームはかなり単純化されていますが、トゥイーンとアニメーションに重点が置かれています。MVCがどのように機能するかは原則的にわかりますが、実際には機能しません。私はこれからバガリーをグーグルで検索し、ひどいことを読んだので、始めたときと同じように混乱しています。 アプリケーション領域に関するいくつかの詳細： マルチスクリーンゲームフレームワーク-複数のゲームがこのフレームワーク内に配置されます。一般的なUI「スクリーン」には、設定、情報、難易度の選択、メインメニューなどがあります。 複数のインプットメソッド 一部の画面のトップメニューバーなどの一般的なUI要素 異なるレンダリング方法を使用する可能性（キャンバス/ DOM / webGL） 現時点では、AppModel、AppController、AppViewがあります。ここから、各「画面」を追加してAppViewにアタッチすることを計画していました。しかし、トップメニューバーのようなものはどうですか、それらは別のMVCトライアドである必要がありますか？コンポーネントを密結合せずにどこにどのように取り付けますか？ 1つのMVCトライアドを別のトライアド内に配置することは受け入れられている慣行ですか？つまり、各「画面」をAppViewに追加できますか？「トライアド」はMVC用語としても受け入れられますか？！ 私の心は選択肢の下で溶けています...私はここで基本的な何かを見逃しているように感じます。私はMVCアプローチを使用せずにすでに稼働しているソリューションを持っていますが、結局、密結合されたスープ-ロジックとビューを組み合わせて、現在組み合わせています。アイデアは、それを開いて、ビューを簡単に変更できるようにすることでした（たとえば、キャンバスビューをDOMベースのビューと交換するため）。 現在使用されているライブラリ：require.js、createJS、アンダースコア、GSAP、手動のMVC実装 特に物事の実際のデザイン、および「スクリーン」を適切なM、V、またはCに分割することに関して、ポインタ、例などをいただければ幸いです。 ...またはMVC以外のより適切な方法 [NB、他に2つの誤ったstackexchangeコミュニティで質問したことがある前にこの質問を見た場合...私の脳が機能しなくなった]

9 design-patterns  javascript  mvc  html5  canvas 

簡単な質問：C＃でのシリアル化にはデフォルトのコンストラクターが必要であることを理解しています。これは、コンストラクターで注入されたDIを使用する可能性を排除します（これは、私の読みでは、一般的に好ましいスタイルのDI です[引用が必要]）。それは本当にどちらか一方の状況ですか、それとも何か不足していますか？ （サイド質問）：IoCコンテナーはこのトレードオフをどうにかして回避しますか？

9 dependency-injection  serialization 

IFolderRepositoryそのようなメソッドを持つインターフェースを作成したとしましょう： IEnumerable<Folder> GetAllFolders(); Folder GetFolderWithId(int id); void AddFolder(Folder newFolder); void ModifyFolder(Folder folderToModify, Folder folderAfterModification); void RemoveFolder(Folder folderToRemove); と私は実装DatabaseFolderRepositoryして言ってみましょうCacheFolderRepositoryDecorator。ここで「数百行後」にSkyDriveフォルダーの機能を追加したいので、追加しSkyDriveFolderRepositoryます。残念ながら、DatabaseFolderRepository実装はデータベースと通信するために同期メソッドを使用していましたが、skydrive 1では多くのasyncおよびを使用していますawait。そのような場合はどうしますか？voidメソッドで非同期とマークされている場合は、解決策ではありません（例外処理が必要）。インターフェースを変更して返す必要がありますTask<T>か？確かに上記の例では機能しますが、これらは2つのインターフェース実装クラスにすぎません。それとも、ほとんどのインターフェイスにTask戻り値の型があるべきですか（規則を必要としないので）。

9 c#  async