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

幅広い質問であることは承知しておりますので、できるだけ具体的にお話しさせていただきます。この質問は、技術的な質問よりも「組織的な」質問です。 これらの主なコンポーネントを持つマルチサイドプロジェクトがあります。 コアビジネスロジック（データモデル）をホストするサーバー コアビジネスロジックを使用するクライアントのバックオフィス コアビジネスロジックも使用するアプリケーションAPI（REST） アプリケーションAPIを使用するスマートフォンアプリ（iOSおよびAndroid）があります。 スマートフォンとは別のタブレットアプリ（android）があり、同じアプリAPIを使用しています。 すぐに、私はアクティブなクライアントで生産されます。そして、どんなプロジェクトでも、私はすべての異なるコンポーネントを長期にわたって維持する必要があります。つまり、以下のすべてをアップグレードできます。 サーバーのコアビジネスロジックのコード（バックオフィス、API、および副作用としてモバイルアプリで使用） API自体（スマートフォンアプリとタブレットアプリの両方で使用） すべてのモバイルアプリ（appstore / googleplay経由） もちろん、サーバー側の部分（コアビジネスロジックコードとAPIコード）は自分ですぐに変更できます。ただし、新しいモバイルアプリはappstore / googleplayでクライアントがダウンロードする必要があり、それらが最新であるかどうかはわかりません。 これらのアップグレードをスムーズに行い、クライアントにリスクを与えないようにするためのガイダンス、優れた実践のヒントを教えてください。 どのバージョンの「バージョン」を作成する必要がありますか？クライアントがモバイルアプリをアップグレードしなくても、すべてが確実に機能するようにするにはどうすればよいですか？私に仕事を楽にするために彼にアップグレードを強いるべきですか？ つまり、マルチサイドプロジェクトを長期にわたってライブにするには、どのように整理すればよいですか？

14 design  architecture  project-management  deployment  release-management 

クラスLinkedListは、add_first（）、add_last（）、add_after（）、remove_first（）、remove_last（）、remove（）などの関数とともに存在します 現在、push（）、pop（）、peek（）、またはtop（）などの機能を提供するクラスStackがあり、これらのメソッドを実装するためにLinkedListクラスメソッドを拡張しています。これは、リスコフ代替原理の違反ですか？ たとえば、リンクリストのn番目の位置にノードを追加する場合のadd_after（）の場合を考えます。これは基本クラスで実行できますが、Stackクラスでは実行できません。ここで事後条件が弱くなっていますか、それともadd_after（）メソッドを変更してスタックの一番上に追加しますか？ また、違反ではない場合、これは悪い設計ですか？そして、LinkedListクラスを使用してStack機能をどのように実装しますか？

13 design  object-oriented  object-oriented-design  solid  liskov-substitution 

機能的には複数の言語で同じライブラリをサポートしている状況があります。多くの場合、これらの間で共有する必要がある定数があります（たとえば、jsonフィールド名キーまたはエラーコード）。 私が現在これを行う方法は、各言語の定数を定義するコードを持つことです。 問題はメンテナンスにあります。新しいエラーコードを追加する場合、すべてのライブラリで手動で更新する必要があります。少数の人にとってはこれで問題ありませんが、更新するのに5つのSDKを使用しなければならないのは面倒です。これらについても単一の真実の情報源があると便利です。 ある種のconfig-likeファイルについて考えてきましたが、それはすべてのデプロイされたパッケージに含まれる必要があり、ビルド/リリースプロセスが複雑になります。 複数の言語間で共有される定数のメンテナンスを処理するより良い方法はありますか？

13 design  packages 

私は、それぞれの作品は、独自のタイプ（のようであるジャワ、中（例えばチェスなど）ボードゲームを作成していますPawn、Rookなど）。アプリケーションのGUI部分では、これらの各部分の画像が必要です。やることは rook.image(); UIとビジネスロジックの分離に違反しているため、作品ごとに異なるプレゼンターを作成し、作品タイプを対応するプレゼンターにマッピングします。 private HashMap<Class<Piece>, PiecePresenter> presenters = ... public Image getImage(Piece piece) { return presenters.get(piece.getClass()).image(); } ここまでは順調ですね。ただし、getClass()メソッドを呼び出すと慎重なOOPの第一人者が眉をひそめ、次のようなビジターを使用することをお勧めします。 class Rook extends Piece { @Override public <T> T accept(PieceVisitor<T> visitor) { return visitor.visitRook(this); } } class ImageVisitor implements PieceVisitor<Image> { @Override public Image visitRook(Rook rook) { return rookImage; } } 私はこのソリューションを気に入っています（ありがとう、第一人者）が、1つの重大な欠点があります。新しいピースタイプがアプリケーションに追加されるたびに、PieceVisitorを新しいメソッドで更新する必要があります。私のシステムをボードゲームフレームワークとして使用して、フレームワークのユーザーがピースとそのプレゼンターの両方の実装のみを提供し、それをフレームワークにプラグインするだけの簡単なプロセスで新しいピースを追加できるようにします。私の質問：このような拡張性を可能にするinstanceof、getClass()などのないクリーンなOOPソリューションはありますか？

13 java  design  object-oriented 

SCRUMミーティングで、製品チームは、モバイルアプリで使用されるAPIの機能について議論していました。私たちは、画面がどのように見えるべきか、そしてどのキー要素を含むべきか（「レイアウト」）を示すモックアップを用意しました。 これと製品所有者との議論に基づいて、API応答のプロトタイプ（HAL + JSON）を作成しました。それは非常にシンプルで、HALに準拠したJSONであり、モックアップにあるものを表すことしかできませんでした。ビジネスマンは頻繁にアイデアを変更する傾向があるため、私は将来のアイデアに影響されることはなく、ミニマルなアプローチを取ることにしました。私の提案はチームによって却下され、7対1に投票されました。 チームは、レイアウトをより柔軟に配置できる、より複雑で非セマンティックな抽象json構造を使用することにしました。そのアプローチの欠点は、設計上、nullおよび空のプロパティを持つ可能性のある一連の均一なオブジェクトになってしまったことです。彼らはまた、A / Bテストを可能にすると良いと思っていましたが、そのような要件がなかったため、予測に基づいていました。 ほとんどの場合、スプリントの一部ではなく、モックアップで言及されていないことについて議論していました。説明された問題は、「将来のマーケティングがどうなるか...」、「ビジネスが私たちに望むならどうなるか...」でした。 私と製品所有者は経験豊富なプログラマーであり、過去にこの種の問題を見てきました。YAGNIとKISSの原則に従うよう努めています。チームの他のメンバーは少し経験が浅く、これらの原則を知っていますが、理解していないようです。 チーム全体が私たちにとってより重要であり、私たちはそれほど重要ではない何かをめぐって戦いたくなかったので、私たちは彼らの解決策に同意しました。しかし、そのようなことが今後のより複雑な議論の先例になり得るのではないかと心配していますか？そのような行動に対処する方法は？チームリーダーとして、私がもっとうまくできることはありますか？ 製品は初期段階のMVPであることに言及する価値があります。

13 design  scrum  team  leadership 

私はレイ・ウェンダリッヒのチュートリアルを進めていましたが、作者がクラス拡張機能を使用してデリゲートコールバックを保持していることに気付きました。 クラス拡張内のコールバックを委任する： extension LogsViewController : UIPopoverPresentationControllerDelegate { func adaptivePresentationStyleForPresentationController(controller: UIPresentationController, traitCollection: UITraitCollection) -> UIModalPresentationStyle { ... } } それをクラス内に含めるのではなく： クラス内のコールバックを委任する： class LogsViewController : UITableViewController, UIPopoverPresentationControllerDelegate { func adaptivePresentationStyleForPresentationController(controller: UIPresentationController, traitCollection: UITraitCollection) -> UIModalPresentationStyle { ... } } 私はこれを同時に奇妙で面白いと感じました。「LogsViewControllerExtension.swift」という名前のLogsViewControllerクラスの拡張機能専用のファイルがあり、デリゲートプロトコルごとに異なる拡張機能があります：UITableViewDataSource、UISplitViewDelegateなど。 それぞれ独自のファイル内でコールバックを委任する複数のクラス拡張機能： extension LogsViewController: UISplitViewControllerDelegate { ... callbacks } extension LogsViewController : UIPopoverPresentationControllerDelegate …

13 design  object-oriented  swift-language  extension-method 

例から始めましょう。 たとえば、exportDBスキーマに大きく依存するというメソッドがあります。また、「大きく依存する」ということは、特定のテーブルに新しい列を追加すると、頻繁に（非常に頻繁に）対応するexportメソッドが変更されることを知っています（通常、エクスポートデータにも新しいフィールドを追加する必要があります）。 プログラマーは、exportメソッドを変更することを忘れることがよくあります。これを確認する必要があるかどうかは明確ではないからです。私の目標は、プログラマーがメソッドを見るのを忘れたのか、エクスポートデータにフィールドを追加したくないだけなのかを明確に決定するようプログラマーに強制することexportです。そして、私はこの問題の設計ソリューションを探しています。 私には2つのアイデアがありますが、どちらにも欠点があります。 スマートな「すべてを読む」ラッパー すべてのデータが明示的に読み取られるようにするスマートラッパーを作成できます。 このようなもの： def export(): checker = AllReadChecker.new(table_row) name = checker.get('name') surname = checker.get('surname') checker.ignore('age') # explicitly ignore the "age" field result = [name, surname] # or whatever checker.check_now() # check all is read return result そのため、読み取られなかった別のフィールドが含まれてcheckerいるかどうかをアサートしtable_rowます。しかし、このことはすべて重そうに見え、（おそらく）パフォーマンスに影響します。 「その方法を確認する」unittest 最後のテーブルスキーマを記憶し、テーブルが変更されるたびに失敗するunittestを作成するだけです。その場合、プログラマーは「exportメソッドをチェックアウトするのを忘れないでください」のようなものを見るでしょう。警告プログラマーを非表示にするには、問題をチェックアウトしexport、手動で（別の問題です）新しいフィールドを追加してテストを修正します。 私には他にもいくつかのアイデアがありますが、それらは実装するのが面倒で、理解するのが難しすぎます（そして、プロジェクトをパズルにしたくないのです）。 上記の問題は、私が時々遭遇するより広範なクラスの問題の例です。いくつかのコードやインフラストラクチャをバインドしたいので、それらのいずれかを変更すると、すぐにプログラマに別のコードをチェックするよう警告します。通常、一般的なロジックの抽出や信頼性の高い単体テストの作成などの簡単なツールがありますが、より複雑なケースのツールを探しています。

13 design  design-patterns  architecture  unit-testing 

他の多くのクラスがコードのあらゆる場所で使用する一般的な静的メソッドを提供するユーティリティクラスがあるとします。 ユーティリティテストのいずれかが合格しなかった場合にテストが失敗するように、ユーティリティのコンシューマ向けのユニットテストをどのように設計しますか？あなたはそれを行うことができますか、ユーティリティクラスのテストがすべてグリーンであるかどうかを自分で確認する必要がありますか？ たとえば、メッセージパーサーによって使用される（またはその出力）メッセージスプリッターユーティリティがあります。メッセージパーサーがテストされる前に、メッセージスプリッターが正しく動作することを確認したいと思います。 両方のテストを作成しましたが、それらをリンクし、1つのテストを他のテストの結果に依存させる方法はありますか？ これに適したタグが見つかりませんでしたが、Visual Studioの単体テストエンジンを使用しています。

13 c#  design  unit-testing 

サードパーティのライブラリを使用しています。彼らは私たちの意図と目的のために、おそらく次のように実装されたPOJOを渡します： public class OurData { private String foo; private String bar; private String baz; private String quux; // A lot more than this // IMPORTANT: NOTE THAT THIS IS A PACKAGE PRIVATE CONSTRUCTOR OurData(/* I don't know what they do */) { // some stuff } public String getFoo() { …

13 java  design  third-party-libraries  constructors 

私はRails AntiPatternsという本を読んでいて、彼らはデメテルの法則を破らないために委任を使うことについて話しています。主な例は次のとおりです。 彼らは、コントローラでこのようなものを呼び出すことは悪いと信じています（そして私は同意します） @street = @invoice.customer.address.street 提案された解決策は、次のことを行うことです。 class Customer has_one :address belongs_to :invoice def street address.street end end class Invoice has_one :customer def customer_street customer.street end end @street = @invoice.customer_street ドットを1つしか使用しないため、ここでデメテルの法則に違反していないと述べています。あなたはまだ顧客を通り抜けて住所を通り、請求書の番地を取得しているので、これは間違っていると思います。私は主に私が読んだブログ投稿からこのアイデアを得ました： http://www.dan-manges.com/blog/37 ブログの投稿では、主な例は class Wallet attr_accessor :cash end class Customer has_one :wallet # attribute delegation def cash @wallet.cash end end …

13 design  design-patterns  object-oriented  ruby-on-rails 

codereview.SEの成長を測定するPythonプログラムを作成していました。私のアプローチは、フロントページに表示される「サイトの統計」を取得し、ハードドライブに保存することでした。これは毎日1回行う予定です。これまでに、統計を取得してテキストファイルに追加するのに十分な量を作成しました。Pythonスクリプトはgithubで表示できます。私が使用している形式は次のとおりです 22-08-2013 questions 9073 answers 15326 answered 88 users 26102 visitors/day 7407 22-08-2013 questions 9073 answers 15326 answered 88 users 26102 visitors/day 7407 スクリプトを2回実行して、ファイルで使用する形式を取得しました。最初は自分で保存するので、フォーマットは同じであるため、簡単に解析できますが、よくわかりません。データベースを使用する方が、データを取得する方が簡単であるため、ここではより良いはずです。ただし、データベースを使用したことがなく、SQL、MySQL、またはRDBMSのその他のバリアントについての知識もありません。 だから、これは私に質問をもたらします。データをテキストファイルに保存するよりも、データを保存するのにデータベースを優先すべき場合 データベースが必要なのか、単純なテキストファイルが必要なのかを判断する際に参照できるポインタはありますか？ PS：より良いタグを追加できる場合は追加してください。追加できるタグについて疑問がありました。

13 design  python  database  storage 

バックグラウンド このテーブルがあります +-------------------------+ +------------------------+ |Airport | |Country | |-------------------------| |------------------------| |airport_code string (PK) | |country_code string (PK)| |address string | |name string | |name string | +------------------------+ +-------------------------+ +-------------------------+ |Currency | |-------------------------| |currency_code string (PK)| |name string | +-------------------------+ airport_codeは、IATA（国際航空運送協会）の 空港コードです。飛行機で旅行する場合は、荷物タグで確認できます。 country_codeはISO 3166-1 A3標準の国コードです。オリンピックで見ることができます。 currency_codeは、IS0 417標準の3文字の通貨コードです。国際通貨交換の表示板で確認できます。 ご質問 これらの自然なPKは十分ですか？ 業界全体で受け入れられているPKにとって十分な世界的に尊敬されている標準を使用していますか？ この表には、何があっても代理変数が必要ですか？

13 design  database-design  relational-database  rdbms  surrogate-keys 

私は、依存関係の逆転の原則を（ほとんどは後輩の）同僚に説明しようとしています。ソフトウェアの「高レベルポリシー」と「低レベル詳細」を定義するにはどうすればよいですか？たとえば、ソフトウェアが複数のビジネスアプリケーションのワークフローを自動化する場合、ワークフローの自動化が高レベルのポリシーであり、ビジネスアプリケーションが詳細であると言うのはなぜですか？

13 design-patterns  object-oriented  solid  design 

編集：私の言語は、Javaとは異なり、複数の継承を可能にします。 教育、レクリエーション、潜在的に有用な目的のために、独自のプログラミング言語の設計と開発を開始しました。 最初は、Javaをベースにすることにしました。 これは、すべてのコードがクラスの形式で記述され、そのコードがVMによってロードされるクラスにコンパイルされることを暗示しています。 ただし、インターフェイスや抽象クラスなどの機能は必要ないため、除外しました。彼らはパラダイムを実施しているようで、私の言語はそれをしないようにしたいです。クラスをコンパイル単位として保持したかったのは、実装が便利で馴染みがあり、アイデアが気に入ったからです。 それから、クラスをstaticディレクティブを使用して定数と関数を提供する「名前空間」として、またはインスタンス化する必要のあるオブジェクトのテンプレート（「実際の」クラスの目的）として使用できるモジュールシステムが基本的に残っていることに気付きました他の言語で）。 今、私は疑問に思っています：コンパイル単位としてクラスを持つことの利点と欠点は何ですか？ また、私のデザインに関する一般的なコメントは大歓迎です。私の言語に関する有益な投稿は、http：//www.yannbane.com/2012/12/kava.htmlにあります。

13 java  programming-languages  design  language-design 

私は単体テストを行っており、クラスの1つでメソッドの1つからメールを送信する必要があるため、コンストラクター注入を使用Zend_Mailして、Zendフレームワークにあるクラスのインスタンスを注入します。 現在、一部の人々は、ライブラリが十分に安定しており、頻繁に変更されない場合、それをラップする必要はないと主張します。したがって、それZend_Mailが安定しており、変更されず、私のニーズに完全に適合すると仮定すると、そのためのラッパーは必要ありません。 次にLogger依存する私のクラスを見てみましょうZend_Mail： class Logger{ private $mailer; function __construct(Zend_Mail $mail){ $this->mail=$mail; } function toBeTestedFunction(){ //Some code $this->mail->setTo('some value'); $this->mail->setSubject('some value'); $this->mail->setBody('some value'); $this->mail->send(); //Some } } ただし、ユニットテストでは、一度に1つのコンポーネントをテストする必要があるため、Zend_Mailクラスをモックする必要があります。さらに、クラスが抽象ではなく結石に依存するようになったため、依存関係反転の原則に違反してLoggerいます。 Loggerラップせずに単独でテストするにはどうすればよいZend_Mailですか？ コードはPHPにありますが、答えはそうである必要はありません。これは、言語固有の機能というよりも設計上の問題です

13 design  object-oriented  unit-testing  tdd  solid