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

そのため、フランス語の動詞（データセットではなく、アルゴリズム）を活用するプログラムを作成しようとすると、ちょっとした問題に遭遇しました。 動詞を活用するアルゴリズムは、実際には動詞の17程度のケースではかなり単純であり、各ケースの特定のパターンで実行されます。したがって、これらの17のクラスの活用接尾辞は静的であり、（ほとんどの場合）すぐに変更されることはありません。例えば： // Verbs #1 : (model: "chanter") terminations = { ind_imp: ["ais", "ais", "ait", "ions", "iez", "aient"], ind_pre: ["e", "es", "e", "ons", "ez", "ent"], ind_fut: ["erai", "eras", "era", "erons", "erez", "eront"], participle: ["é", "ant"] }; これらは、フランス語の最も一般的な動詞クラスの接尾辞です。 他のクラスの動詞（不規則）がありますが、その活用も次の1世紀または2世紀の間は変化しないでしょう。これらは不規則であるため、パターンから確実に共役できないため、完全な共役を静的に含める必要があります（32の不規則もあります）。例えば： // "être": forms = { ind_imp: ["étais", "étais", "était", "étions", "étiez", "étaient"], …

39 design  strings 

私の学校のCSプログラムでは、オブジェクト指向プログラミングについては一切言及していません。そのため、私はそれを補足するために独力で読んでいます。具体的には、Bertrand MeyerによるObject Oriented Software Constructionです。 Meyerは、クラスが実装に関する可能な限り多くの情報を隠すべきであると繰り返し指摘していますが、これは理にかなっています。特に、彼は、属性（つまり、クラスの静的で計算されていないプロパティ）とルーチン（関数/プロシージャ呼び出しに対応するクラスのプロパティ）を互いに区別できないと繰り返し主張しています。 たとえば、クラスPersonに属性がある場合、定数属性として定義されている場所またはのようなものに内部的に対応するageかどうかを表記法から判断Person.ageすることは不可能であると主張します。これは私にとって理にかなっています。ただし、彼は次のように主張し続けています。return current_year - self.birth_datereturn self.ageself.age クラスの短い形式として知られるクラスの標準クライアントドキュメントは、特定の機能が属性または関数のどちらであるかを明らかにしないように考案されます。 つまり、クラスのドキュメントでさえ、「getter」が計算を実行するかどうかを指定することを避けるべきだと主張しています。 これ、私は従わない。この区別をユーザーに知らせることが重要になるのは、ドキュメントだけではありませんか？Personオブジェクトで満たされたデータベースを設計する場合Person.age、高価な呼び出しかどうかを知ることは重要ではないので、何らかのキャッシュを実装するかどうかを決定できますか？彼が言っていることを誤解していませんか、それとも彼はOOP設計哲学の特に極端な例ですか？

39 design  object-oriented  documentation  performance 

記述子「エンジン」は、グラフィックエンジン、正規表現エンジン、AIエンジンなど、さまざまな場所に投げ込まれますが、実際にソフトウェアをエンジンにするものは何ですか？設計、入力/出力、目的、サイズ？

39 design  terminology 

オブジェクトを保存および取得したい場合、別のクラスを作成してそれを処理する必要がありますか、それともクラス自体で行う方が良いでしょうか？それとも両方を混ぜるか？ OODパラダイムに従って推奨されるのはどれですか？ 例えば Class Student { public string Name {set; get;} .... public bool Save() { SqlConnection con = ... // Save the class in the db } public bool Retrieve() { // search the db for the student and fill the attributes } public List<Student> RetrieveAllStudents() { // this …

38 design  object-oriented 

ドメインエンティティを取得するビジネスロジックメソッドを提供する場合、パラメーターはオブジェクトまたはIDを受け入れる必要がありますか？たとえば、これを行う必要があります： public Foo GetItem(int id) {} またはこれ： public Foo GetItem(Foo foo) {} オブジェクト全体を渡すことをお勧めしますが、オブジェクトを取得し、IDのみを知っているこの場合はどうでしょうか？呼び出し元は空のFooを作成してIDを設定する必要がありますか、それともメソッドにIDを渡すだけですか？IDを除いて、着信Fooは空になるため、GetItem（）メソッドにIDを送信するだけでFooを作成し、IDを設定する必要があるという呼び出し側の利点はありません。

38 c#  design  object-oriented  clean-code 

ボブおじさんのクリーンコードを数か月前に読みましたが、コードの書き方に大きな影響を与えました。彼がすべてのプログラマーが知っておくべきことを繰り返しているように見えたとしても、それらをすべてまとめて実践することで、コードがずっときれいになります。特に、大きな関数を多くの小さな関数に分割し、大きなクラスを多くの小さなクラスに分割して非常に役立つことを発見しました。 さて、質問です。この本の例はすべてJavaですが、私は過去数年間C ++で働いています。Clean Codeのアイデアは、Javaには存在しない名前空間の使用にどのように拡張されますか？（はい、Javaパッケージについては知っていますが、実際には同じではありません。） それぞれが明確に定義された責任を持つ多くの小さなエンティティを作成するというアイデアを名前空間に適用することは理にかなっていますか？関連するクラスの小さなグループは常に名前空間でラップされるべきですか？これは、多くの小さなクラスを持つ複雑さを管理する方法ですか、それとも多くの名前空間を管理するコストは法外なものでしょうか？ 編集：私の質問は、このウィキペディアのPackage Principlesに関するエントリで回答されています。

38 design  c++  namespace 

自明ではないアプリケーションを構築するとき、物事を迅速に機能させ、モデルロジックをビューと混合し、カプセル化を破るなどのコードのショートカットを取ることに集中するのが最善ですか？または、より多くのアーキテクチャを構築するために事前に時間をかけて、適切に構築する方が良いのですが、デザインが非常に流動的であり、フィードバックが原因でそれを捨てなければならない可能性があるため、この余分なコードはすべて使用されないリスクがあります別の方向に進むには？ コンテキストのために、デスクトップアプリケーションを構築しています。私は唯一の開発者であり、アルバイトをしているのでこのパートタイムで働いています。今、仕事のために、私は物事を正しい方法で行おうとしています。しかし、このプロジェクトは、人々からフィードバックを得ると変化すると予想されますが、それが正しいアプローチであるかどうかはわかりません。今週は数時間かけて、モデルの変更をビューに伝えるために、教科書のModel View Controllerの設計を導入しました。これは一般的に素晴らしいことですが、データを表示するために複数のビューが必要かどうかはわかりません。また、追加のアーキテクチャなしで物事をより迅速に表示できたことを知っています。プロジェクトに1週間に10〜15時間を費やすことになるので、優れたソフトウェアプラクティスに従えばデモできる何かを構築するには時間がかかると感じています。私はユーザーが ' 私がMVCを内部で使用していることに気をつけてください。彼らは問題を解決する何かが欲しいだけです。しかし、ショートカットの技術的負債が非常に大きいため、コードを維持したり、新しい機能を追加したりするのが非常に困難な状況にもあります。他の人がどのようにこの種の問題に取り組んでいるか聞いてみたいです。

38 design  architecture  quality 

プログラミングで、過度に使用されている（IEが本来あるべきものよりも過度に使用されている）、または悪用されている、またはすべてに少し使用されているが、人々が試みる多くの問題に対する本当に良い解決策ではないテクニックがありますか？それで解決します。 正規表現、ある種のデザインパターン、アルゴリズムなど、まったく異なるものを使用できます。たぶん、人々は多重継承などを乱用すると思います。

38 design 

たとえば、{現在は比較的小さいが、将来的には大きくなる可能性がある}プロジェクトで、非常に小さなチームで作業を始めたばかりだとしましょう。これは、実際の世界の他の開発者が使用することを目的とした実際のプロジェクトであり、学期の終わりに廃棄されることを意図した学術プロジェクトではないことに注意してください。 ただし、コードはまだ他の人にリリースされていないため、まだ決定が確定していません。 方法論 コーディングを開始して、すべてのコンポーネントがどのように正確に相互作用するかを明確に理解する前に、ピースを一緒に合わせることが好きです（ボトムアップ設計）。もう1人は、最初に設計全体を行い、ソリューションをコーディングする前にすべてのコンポーネントと通信の詳細を特定することを好みます。 既存のシステムを模倣するのではなく、新しいシステムで作業しているため、適切な最終設計がどのように見えるかが必ずしも明らかではないと想定します。そのため、チームでは、チームメンバーごとに、最終製品にどのような要件が必要であるかについてのアイデアが異なることがあります。 ボトムアップ開発者がいくつかのコードを書くとき、トップダウン開発者は、コードが手元の問題を解決するかもしれないという事実にもかかわらず、設計で想定される潜在的な将来の問題のためにそれを拒否します。問題の解決策をコーディングする前に。 トップダウン開発者がコードを書き始める前に完全な設計と想定される問題を解決しようとすると、ボトムアップ開発者は実際に問題の一部が実際に発生するとは思わないため、ボトムアップ開発者はそれを拒否します、および要件と制約がより明確になったときに、設計を将来変更する必要があるかもしれないと考えています。 問題 これにより、ボトムアップ開発者は設計上の欠陥のためにボトムアップ開発者が書いたソリューションを廃棄すべきであると頻繁に判断するため、ボトムアップ開発者が時間を無駄にしてしまうという問題があります。 -コードを記述します。 トップダウン開発者は、作業を並列化する代わりに、ボトムアップ開発者と正しい設計を行うために頻繁に座って、2つをより速くなる可能性があるまで直列化するため、時間が無駄になります1人が2人よりも仕事をする。 両方の開発者は協力を続けたいと考えていますが、実際にこの組み合わせが実際にどちらかを支援しているようには見えません。 目標 共通の目標は、明らかにコーディングの効果を最大化する（つまり、時間の浪費を最小化する）ことと、有用なソフトウェアを書くことです。 質問 簡単に言えば、どのようにこの問題を解決し、この状況に対処しますか？ 時間を無駄にしないと考えることができる唯一の効率的なソリューションは、各開発者が自分のデザインのスタイルに従うようにすることです。しかし、これは、コードをレビューして、お互いの変更を実際に承認する必要があるとき、および他の人が使用するための一貫したフレームワークを設計しようとしているときに聞こえるよりも困難です。 もっと良い方法はありますか？

37 design  development-methodologies  methodology 

オブジェクト指向プログラムに考えられる設計パターンはありますか？これは、最近、のDoorクラスの実装を見たためですLock。これはテストの一部であり、答えは、コードがNull Objectパターンに従っていることです。 class Lock { public: virtual void close() = 0; virtual void open() = 0; virtual bool is_open() const = 0; virtual ~Lock() { } }; class DummyLock : public Lock { private: DummyLock(); DummyLock(const DummyLock&) = delete; DummyLock& operator=(const DummyLock&) = delete; private: void close() { } void …

37 design  design-patterns  object-oriented  object-oriented-design 

私は3か月前に.NET開発者としてキャリアを始めました。さまざまな技術、パターン、概念に関する長いトレーニングプランの後、私を監督していた開発者は、会社が扱う多くのプロジェクトの1つに参加する準備ができたと判断しました。 最終的にコーディングを開始できることを非常に楽しみにしています。私が参加したチームは、新しいプロジェクトから始めていたため、今のところかなり小さいです。これは、プロジェクトのライフサイクル全体に関わることができるので素晴らしいことです。これは、ASP.NET MVC / ASP.NET Web APIを使用し、フロントエンドでDurandalフレームワークと関連ライブラリを使用するWebベースのSPAプロジェクトです。 私の問題は、同僚と会議を行い、翌月のタスクと見積もりを確立した後、自分がタスクを実行できるかどうかわからない立場にいることです。 作成したタスクを一度も実行したことがないため、どのようにすればよいかわかりません。 たとえば、作成されたタスクの1つは、アプリケーション全体の一般的なエラー処理メカニズムの作成です。 彼がやったことのないタスクに直面したとき、通常どのように進めますか？

37 design  development-process  organization  junior-programmer  development-approach 

私は数年前から並行システムを開発してきましたが、正式なトレーニングが不足している（つまり学位はない）にもかかわらず、このテーマをかなりよく理解しています。少なくとも最近話題になっているいくつかの新しい言語があります。これらは、ErlangやGoなど、並行処理を容易にするように設計されています。並行性に対する彼らのアプローチは、システムをスケーラブルにし、複数のコア/プロセッサ/マシンを活用する方法に関する私自身の経験を反映しているようです。 しかし、あなたが何をしようとしているのかを視覚化し、少なくとも元のビジョンに近いことを確認するのに役立つツールはほとんどないことがわかります。並行コードのデバッグは、並行処理用に設計されていない言語（C / C ++、C＃、Javaなど）では悪夢のようです。特に、開発環境の1つのシステムで簡単に発生する状態を再現することはほとんど不可能です。 それでは、並行性と並列処理に対処するシステムを設計するためのアプローチは何ですか？例： 並行処理できるものとシーケンシャルにする必要があるものをどのように把握しますか？ エラー状態を再現し、アプリケーションの実行中に何が起こっているかを表示するにはどうすればよいですか？ アプリケーションの異なる並行部分間の相互作用をどのように視覚化しますか？ これらのいくつかについては私自身の回答がありますが、もう少し学びたいと思います。 編集 これまでのところ、多くの良い入力があります。リンクされている記事の多くは非常に優れており、私はすでにそれらのいくつかを読みました。 並行プログラミングでの私の個人的な経験から、シーケンシャルプログラミングとは異なる考え方が必要だと思います。精神的な格差は、おそらくオブジェクト指向プログラミングと手続き型プログラミングの違いと同じくらい広いでしょう。この一連の質問では、回答に体系的にアプローチするために必要な思考プロセス（理論）にもっと焦点を当ててほしい。より具体的な回答を提供する場合、例を提供するのに役立ちます-あなたが個人的に経験したこと。 バウンティの目標 何をすべきか教えてはいけません。私はすでにそれをコントロールしています。あなたが何をするか教えてください。これらの問題の解決方法を教えてください。

37 design  debugging  parallelism  concurrency 

コードの作成中または設計中に、最初のインスタンス自体で問題を一般化しようとしますか、それとも非常に具体的な問題を解決しようとしますか。 問題を一般化しようとすると物事が複雑になる傾向があるため（これは必要ではないかもしれません）、一方で、要件に変更があると特定のソリューションを拡張することは非常に困難になるため、私はこれを求めています。 解決策は、言うよりも簡単な中間パスを見つけることだと思います。この種の問題にどのように取り組みますか？どのくらいの時点で一般化を開始したら、これだけの一般化で十分であることがわかりますか？

37 design 

JSON APIに関しては、応答をフラット化し、ネストされたJSONオブジェクトを避けるのが良いでしょうか？ 例として、IMDbに似ているがビデオゲーム用のAPIがあるとします。いくつかのエンティティ、Game、Platform、ESRBRating、GamesとPlatformsをマップするGamePlatformMapがあります。 ID 1のゲームを取得する/ game / 1をリクエストすると、プラットフォームとesrbRatingがネストされたゲームオブジェクトを返します。 { "id": 1, "title": "Game A", "publisher": "Publisher ABC", "developer": "Developer DEF", "releaseDate": "2015-01-01", "platforms": [ {"id":1,"name":"Xbox"}, {"id":2,"name":"Playstation"} ], "esrbRating": { "id": 1, "code": "E", "name": "Everyone" } } JPA / Hibernateのようなものを使用している場合、FETCH.EAGERに設定されていれば自動的にこれを行うことがあります。 もう1つのオプションは、単にAPIを追加して、エンドポイントを追加することです。 その場合、/ game / 1が要求されると、ゲームオブジェクトのみが返されます。 { "id": 1, "title": "Game …

37 design  rest  api-design  json 

以前はセッション変数に大きく依存していましたが、最近ではクエリ文字列パラメーターなどを使用して、それらの多くが不要であることがわかりました。 私の同僚がセッション変数の使用を拒否しています。これは現実的な目標であり、セッション変数は実用的な理由で避ける必要がありますか？セッション変数を完全に回避できますか（ログインを許可するセッションCookieを除く）、これにより設計が改善されますか？ 私の同僚がそれらを使用しない理由は次のとおりです。 セッション変数の型指定されていない性質 セッションのタイムアウトにより状態が失われる セッション変数のグローバルスコープの性質 セッションを失う負荷分散サーバー（.Net固有？） アプリケーションプール/サーバーの再起動 彼らは不要です

36 web-development  design