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

foo.pyクラスを含むファイルがあるとしますFoo： class Foo(object): def __init__(self, data): ... ここFooで、生のソースデータから特定の方法でオブジェクトを作成する関数を追加します。Fooの静的メソッドまたは別の別の関数として配置する必要がありますか？ class Foo(object): def __init__(self, data): ... # option 1: @staticmethod def fromSourceData(sourceData): return Foo(processData(sourceData)) # option 2: def makeFoo(sourceData): return Foo(processData(sourceData)) ユーザーにとって便利であることがより重要かどうかはわかりません。 foo1 = foo.makeFoo(sourceData) または、メソッドとクラスの間の明確な結合を維持することがより重要かどうか： foo1 = foo.Foo.fromSourceData(sourceData)

30 design  python 

現在、私はクライアントに学校入学システムの開発を要求しています。今、これはこの種の挑戦をしている私にとって初めてです。私が作成した過去のソフトウェアのほとんどはそれほど複雑ではありません。 私はあなたのほとんどすべてが複雑なソフトウェアを作成したことを知っています。これについてあなたのアドバイスが欲しいです。最初にフロントエンドまたはバックエンドを設計する必要がありますか？ ありがとう！ ここに、私が少し前にインターネットで見つけた記事の結論があります。共有したいだけ http://www.skitoy.com/p/front-end-vs-back-end-developers-my-take/157 フロントエンド開発者とバックエンド開発者（私の意見） 私の個人的なテイク 繰り返しますが、それは訓練の問題であり、いくつかの広範なストロークの一般化です： フロントエンド開発者 通常、CS学位を取得していないか、3級学校のCS学位を取得していません。 基本に似た言語で作業する（PHP is Basicを参照） フォトショップドキュメントをCSS / HTML /などに変換する視覚的なスキルを持っている。 型のない言語のため、反復プログラミングに対して高い許容度を持っている バックエンド開発者 CSの学位または豊富な経験がある 問題解決のアプローチをより体系的にする 漏れているオブジェクトを見つけるのに何日も費やすことを気にしないでください 問題を解決するためのツールを試してビルドする

30 design  database  database-development  database-design  front-end 

銀行の「口座」の抽象化を提供したいとします。functionPythonでオブジェクトを使用する1つのアプローチを次に示します。 def account(): """Return a dispatch dictionary representing a bank account. >>> a = account() >>> a['deposit'](100) 100 >>> a['withdraw'](90) 10 >>> a['withdraw'](90) 'Insufficient funds' >>> a['balance'] 10 """ def withdraw(amount): if amount > dispatch['balance']: return 'Insufficient funds' dispatch['balance'] -= amount return dispatch['balance'] def deposit(amount): dispatch['balance'] += amount return dispatch['balance'] …

29 design  object-oriented  python  object-oriented-design  object 

「実装ではなくインターフェースへのプログラミング」という用語に頻繁に出くわしましたが、それが何を意味するのか理解していると思います。しかし、私はそれが利点であり、可能な実装であることを確実に理解したいと思っています。 「インターフェースへのプログラミング」とは、可能な場合、具体的な実装を参照するのではなく、クラスのより抽象的なレベル（インターフェース、抽象クラス、またはある種のスーパークラス）を参照する必要があることを意味します。 Javaの一般的な例は、次を使用することです。 List myList = new ArrayList();の代わりにArrayList myList = new ArrayList();。 これに関して2つの質問があります。 このアプローチの主な利点を確実に理解したいと思います。利点は主に柔軟性だと思います。具体的な実装ではなく、より高レベルの参照としてオブジェクトを宣言すると、開発サイクル全体およびコード全体で柔軟性と保守性が向上します。これは正しいです？柔軟性が主な利点ですか？ 「インターフェースへのプログラミング」の方法は他にありますか？または、「具体的な実装ではなく、インターフェイスとして変数を宣言する」がこの概念の唯一の実装ですか？ 私はJavaコンストラクトInterfaceについて話しているのではありません。オブジェクト指向の原則「実装ではなく、インターフェイスへのプログラミング」について話しています。この原則では、世界の「インターフェース」とは、クラスの任意の「スーパータイプ」を指します。インターフェース、抽象クラス、またはより具体的なサブクラスよりも抽象的で具体的ではない単純なスーパークラスです。

29 design  object-oriented  interfaces 

「実際のJava同時実行性」を読んでいます。「幸いなことに、カプセル化やデータ隠蔽など、よく組織化された保守可能なクラスを作成するのに役立つオブジェクト指向の手法は、スレッドセーフの作成にも役立ちますクラス。" 問題＃1-データの隠蔽について聞いたことがなく、それが何であるかわかりません。 問題＃2-カプセル化はプライベート対パブリックを使用しており、実際にはデータが隠れていると常に考えていました。 データ隠蔽とは何か、カプセル化とどのように異なるのか説明していただけますか？

29 java  design  object-oriented 

今日でも、プロのチームによって構築された、長年使用されてきた製品が、今日までまだ、ユーザーに役立つエラーメッセージを提供できないことに驚かされます。場合によっては、ほんの少しの追加情報を追加するだけで、ユーザーの時間を節約できます。 エラーを生成するプログラムが、何らかの理由で生成しました。何が失敗したのか、ユーザーにできる限り多くの情報を提供するために、すべてを自由に使用できます。それでも、ユーザーを支援する情報を提供することは優先度が低いようです。これは大きな失敗だと思います。 1つの例はSQL Serverからのものです。使用中のデータベースを復元しようとすると、まったく問題が発生します。SQL Serverは、どのプロセスとアプリケーションがそれにアクセスしているかを知っています。データベースを使用しているプロセスに関する情報を含めることができないのはなぜですか？すべての人がApplicatio_Name接続文字列で属性を渡すわけではないことは知っていますが、問題のマシンに関するヒントさえあれば役立つかもしれません。 別の候補であるSQL Server（およびmySQL）は、美しいstring or binary data would be truncatedエラーメッセージと同等のものです。多くの場合、生成されたSQLステートメントの単純な閲覧と、テーブルが原因の列を示します。これは常に当てはまるわけではありません。データベースエンジンがエラーを検出した場合、なぜその時間を節約できず、どの列が壊れているかを教えてくれないのでしょうか。この例では、それをチェックするとパフォーマンスが低下する可能性があり、これがライターを妨げると主張できます。結構です、私はそれを買います。データベースエンジンは、エラーがあることを認識すると、格納される値と列の長さを事後比較します。次に、それをユーザーに表示します。 ASP.NETの恐ろしいテーブルアダプタも有罪です。クエリを実行し、どこかで制約に違反していることを示すエラーメッセージを表示できます。ありがとう。開発者は行番号やサンプルデータを提供するのが面倒なので、データモデルとデータベースを比較する時間です。（記録のために、私は選択によってこのデータアクセス方法を決して使用しませんでした、それはただ私が継承したプロジェクトです！）。 C＃またはC ++コードから例外をスローするたびに、手元にあるすべてのものをユーザーに提供します。それを投げる決定が下されたので、私が提供できる情報が多ければ多いほど良いです。関数が例外をスローしたのはなぜですか？何が渡され、何が期待されましたか？例外メッセージの本文に意味のあるものを入れるには少し時間がかかります。地獄、それは何もしませんが、私のコードは意味のあるものを投げることを知っているので、私が開発する間、私を助けます。 複雑な例外メッセージをユーザーに表示すべきではないと主張することができます。私はそれに反対しますが、それはあなたのビルドに応じて異なるレベルの冗長性を持つことで簡単になだめることができる議論です。それでも、ASP.NETおよびSQL Serverのユーザーは一般的なユーザーではなく、問題をより迅速に追跡できるため、冗長でおいしい情報に満ちたものを好むでしょう。 開発者がエラーが発生したときに最低限の情報を提供することは、この日と年齢で大丈夫だと思うのはなぜですか？ それは2011年の男だ、来るで。

29 design  exceptions  error-messages 

私は長年の開発者です（49歳）が、オブジェクト指向開発は初めてです。私はBertrand Meyer's Eiffel以来オブジェクト指向について読んでいますが、オブジェクト指向プログラミングはほとんどしていません。 ポイントは、オブジェクト指向設計に関するすべての本は、ボート、車、または私たちが頻繁に使用する一般的なオブジェクトの例から始まり、属性とメソッドを追加し、オブジェクトの状態をモデル化する方法と何ができるかを説明し始めることですそれ。 そのため、通常、「モデルが優れているほど、アプリケーション内のオブジェクトをより適切に表し、すべてがより優れている」というようなものになります。 これまでのところ非常に良いですが、一方で、「クラスは単一のページに収まる必要があります」などのレシピを提供する複数の著者を見つけました（「どのモニターサイズで？」コードを印刷します！）。 たとえば、PurchaseOrder動作を制御する有限状態マシンとのコレクションを持つクラスを考えてみましょう。PurchaseOrderItemここでの作業の引数の1つは、PurchaseOrderいくつかのメソッド（データクラス以上）を持つ単純なクラスを使用することです。PurchaseOrderFSM「エキスパートクラス」のためのハンドル有限状態マシンというPurchaseOrder。 これは、コーディング・ホラーに関するJeff AtwoodのCode Smells投稿の「Feature Envy」または「Inappropriate Intimacy」分類に該当すると言えます。私はそれを常識と呼んでいます。実際の注文書を発行、承認、またはキャンセルできる場合、PurchaseOrderクラスにはissuePO、approvePOおよびcancelPOメソッドが必要です。 それは、私がオブジェクト指向の基礎として理解している「凝集を最大化する」と「結合を最小化する」という古くからの原則とは関係ないのでしょうか？ それに、それはクラスの保守性に役立ちませんか？

29 design  object-oriented 

私は最近DDDを勉強していますが、DDDでリポジトリを管理する方法について質問があります。 実際、私は2つの可能性に出会いました： 最初の1つ 私が読んだサービスを管理する最初の方法は、アプリケーションサービスにリポジトリとドメインモデルを挿入することです。 このように、アプリケーションサービスメソッドの1つで、ドメインサービスメソッドを呼び出し（ビジネスルールをチェック）、条件が良好な場合、データベースからエンティティを永続化/取得するために、リポジトリが特別なメソッドで呼び出されます。 これを行う簡単な方法は次のとおりです。 class ApplicationService{ constructor(domainService, repository){ this.domainService = domainService this.repository = repository } postAction(data){ if(this.domainService.validateRules(data)){ this.repository.persist(new Entity(data.name, data.surname)) } // ... } } 二つ目 2番目の可能性は、代わりにdomainService内にリポジトリを挿入し、ドメインサービスを介してのみリポジトリを使用することです。 class ApplicationService{ constructor(domainService){ this.domainService = domainService } postAction(data){ if(this.domainService.persist(data)){ console.log('all is good') } // ... } } class DomainService{ constructor(repository){ this.repository …

29 design  domain-driven-design 

エンティティフレームワークが、レイヤー間でデータを転送するために同じプロパティを持つ新しいオブジェクトを作成するロジックを提供しないのはなぜですか？ エンティティフレームワークで生成したエンティティオブジェクトを使用します。

29 design  design-patterns  architecture  domain-driven-design  entity-framework 

データベースに文字列ペイロードを保存します。2つのグローバル構成があります。 暗号化 圧縮 これらは、構成を使用して有効または無効にすることができます。その場合、どちらか一方のみを有効にするか、両方を有効にするか、両方を無効にします。 私の現在の実装はこれです： if (encryptionEnable && !compressEnable) { encrypt(data); } else if (!encryptionEnable && compressEnable) { compress(data); } else if (encryptionEnable && compressEnable) { encrypt(compress(data)); } else { data; } デコレータパターンについて考えています。それは正しい選択ですか、それとももっと良い選択肢がありますか？

28 design  design-patterns  object-oriented-design  refactoring 

私は、標準のSQLリレーショナルデータベースまたはJSONオブジェクトを使用して、イベントまたはアクティビティに関するデータを保存するかどうかを決定しようとしているプロジェクトに取り組んでいます。 プロジェクトは複数のイベントタイプのデータを保存するため、この質問に対して1つのイベントタイプのみを説明することにしました。 ライブ音楽イベント（この質問の最後にあるJSONスキーマを使用して詳細に説明します）は、イベントが行われる場所、イベントの日時、イベントのコストなどのデータを格納するオブジェクトです。ライブ音楽イベントオブジェクトには、1対1（イベント->名前、イベント->説明）と1対多（イベント->会場、イベント->日付、イベント->チケットタイプの両方があります。 ）関係。さらに、イベントオブジェクトには、パフォーマーオブジェクトにリンクする1つ以上のパフォーマーIDを含めることができます。演奏者オブジェクトは、ライブ音楽イベントで演奏しているミュージシャンのデータを保存します。 データは、単純（「x名前のイベントを検索」）と複雑（「現在の音楽ジャンルから半径「z」以内の「x」音楽ジャンルと「y」コストのイベントを検索」」の両方を使用してユーザーに照会されます場所」）クエリ。データは、ユーザーがWebフォームを使用して送信します。 おそらく定義済みのJSONスキーマからわかるように、私はもともとJSONオブジェクトを使用してこのデータを保存するつもりでしたが、私のデータは純粋にリレーショナルであるため、古いメソッドに固執する必要があると言う人がいます。 私のニーズを考えれば、それぞれのアプローチの長所と短所についてのご意見をいただければ幸いです。明確なものが必要な場合は、お気軽にお問い合わせください。 { "event": { "eventID":{ "type":"string" }, "eventType":{ "type":"array", "eventTypeItem":{ "type":"string" } }, "eventName":{ "type":"string" }, "eventDescription":{ "type":"string" }, "eventVenueList":{ "type":"array", "eventVenueListID":{ "type":"integer" } }, "eventURL":{ "type":"string" }, "eventTwitter":{ "type":"string" }, "eventFB":{ "type":"string" }, "eventInstagram":{ "type":"string" }, "eventEmail":{ "type":"string", "format":"email" }, "eventContactPerson":{ "type":"string" }, …

28 design  sql  json 

複数の開発者がシステムに新しい機能を追加しただけで、アーキテクチャ全体を実際に監視したり、リファクタリングを実行したりしない、歴史的に成長したソフトウェアシステムを説明するアンチパターンはありますか？ これは、管理者/顧客が絶えず新しい機能を要求し、誰も何もリファクタリングせず、他の開発者が以前に行ったことに追加するだけの場合に起こると思います。 開発者がソフトウェアシステムに圧倒されており、現在どのように機能するかを実際に理解していないため、コードをリファクタリングして変更するのではなく、最後にコードを追加/接着するだけの場合もあります。 そのため、時間の経過とともに、システムの保守がますます難しくなっています。 （これらの種類のアンチパターンの写真は、プログラミング全体に誰もがこれをより明確にするためにありますか？全体的なデザインを考えずに機能を追加するだけで構築された車のように。後方に移動しながらトレーラーを牽引し、エンジニアが車両の前面に牽引バーを溶接するだけです。作業は完了しました。しかし、カウルはもう開きません。）

28 design  terminology  anti-patterns  technical-debt  legacy-code 

私は、すべてのソフトウェア設計がローカルチームによって行われ、これらの設計がコーディングのためにオフショアチームに送られるプロジェクトに関与します。 この特徴を持つプロジェクトに直面するのはこれが初めてであり、私にとってはちょっと奇妙に感じます。マネージャーは、私たちが非常に詳細な設計文書を作成することを期待しています。私の観点からは、IDEで行うことはできますが、彼らは紙でコーディングすることになります。 だから、私の質問はこのアプローチが良いですか、それとも正しいですか？ソフトウェアプロセスがプロジェクトで成功するために必要な主な考慮事項は何ですか？

28 design  development-methodologies  distributed-development  offshore 

私は数年前からプログラミングをしていて、ジレンマに陥っていることがよくあります。 2つの解決策があります- 一つはシンプルなもの、すなわちシンプルなアプローチであり、理解と保守が容易です。冗長性、余分な作業（余分なIO、余分な処理）が含まれるため、最適なソリューションではありません。 しかし、他は複雑なアプローチを使用し、実装が難しく、多くのモジュール間の相互作用を伴うことが多く、パフォーマンス効率の高いソリューションです。 達成するのに難しいパフォーマンスSLAがなく、シンプルなソリューションでさえパフォーマンスSLAを満たすことができる場合、どのソリューションに取り組むべきですか？簡単な解決策については、仲間の開発者の間で軽disを感じています。 シンプルなソリューションでパフォーマンスSLAを満たすことができる場合、最も最適な複雑なソリューションを考え出すのは良い習慣ですか？

28 design  programming-practices  coding-style  code-quality  performance 

データベースプログラミングには、保存するデータに対して行う「正規化」と呼ばれる手法があります。 誰もがこの概念をオブジェクト設計に適用しようとしましたか？どのようにしていた？どのようにうまくいきましたか？ 編集：拡張/明確化するために、データベースの正規化は冗長性を減らすための一連の原則以上のものです。実際にあなたが通過するステップと段階があり、あなたがどの段階にいるかを示す少なくとも中程度に客観的な尺度があります。オブジェクト設計には独自の原則があり、匂いの概念がありますが、あなたに伝える同様の何かをする方法はありますかあなたはXX-form0,1,2 ...などにいて、次の「正規化された」レベルに移動する方法ですか？

28 design