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

新しい個人プロジェクト（Python）を開始したばかりで、プログラムの「大まかなドラフト」に相当するものを書いています。私はまだ広範なエラー/例外処理または美的なUI要素を入れていません（これらが最終的に必要になることを知っている場合でも）、ドキュメントは私がやっていることを将来見るのに役立つのに十分です。 プロジェクトの設計/管理の設定原則に反して、大雑把に始めるのですか？私は科学者であり、プログラマーではないので、これらのことを理解していません。したがって、主な問題は、次の2つの両極端のどちらに当てはまるかについてコンセンサスがあるかどうかです。 すべての例外処理を含め、最初から徹底的で高品質のコードを記述し、最終的に必要になることがわかります。 最初から最小限の作業でラフなドラフトを作成し、後ですべての詳細を記入します。 関連する質問：プロジェクトを完成させるために、デザインの「素晴らしさ」を犠牲にしてよいのはいつですか？

15 design  project-management  time-management 

次のマップがあります。 Map<Double, List<SoundEvent>> soundEventCells = new HashMap<Double, List<SoundEvent>>(); これHashMapは、double値（ある時点）を対応するSoundEvent「セル」にマップします。各「セル」には、多数のSoundEventsを含めることができます。それがaとして実装されているList<SoundEvent>理由です。それがまさにそれだからです。 コードを読みやすくするために、次のような非常に単純な静的内部クラスを実装することを考えました。 private static class SoundEventCell { private List<SoundEvent> soundEvents = new ArrayList<SoundEvent>(); public void addEvent(SoundEvent event){ soundEvents.add(event); } public int getSize(){ return soundEvents.size(); } public SoundEvent getEvent(int index){ return soundEvents.get(index); } // .. remove() method unneeded } また、マップ宣言（および他の多くのコード）の方が見栄えがよくなります。たとえば、次のようになります。 Map<Double, SoundEventCell> soundEventCells …

15 java  design  object-oriented 

（この質問の目的のために、私が「インターフェース」と言うとき、私は言葉の他の意味での「インターフェース」ではなく、言語構成体を意味しinterfaceます、すなわち、クラスが通信し、操作します。） オブジェクトを具象型ではなく抽象化に依存させることで、疎結合を実現できます。 これは、2つの主な理由のための疎結合することができます：1 -抽象化が依存するコードが少なく破るためにある意味、具体的なタイプより変更になりにくいです。2 -彼らはすべての抽象化をフィットするので別の具体的なタイプは、実行時に使用することができます。既存の依存コードを変更する必要なしに、新しいコンクリートタイプを後で追加することもできます。 たとえば、あるクラスCarと2つのサブクラスVolvoとを考えMazdaます。 コードがに依存している場合、ランタイム中にCara Volvoまたはaを使用できMazdaます。また、後で追加のサブクラスを追加して、依存コードを変更する必要はありません。 また、Car-抽象化である-は、Volvoまたはよりも変更される可能性が低いMazdaです。車はかなり以前から一般的に同じでしたが、ボルボとマツダははるかに変わる可能性が高いです。すなわち、抽象化は具体的な型よりも安定しています。 これはすべて、疎結合とは何か、そして具体的ではなく抽象化に依存することによってどのように達成されるかを理解していることを示すことでした。（不正確なものを書いた場合はそう言ってください）。 私が理解していないのはこれです： 抽象化は、スーパークラスまたはインターフェースにすることができます。 もしそうなら、なぜインターフェイスは疎結合を可能にする能力で特に称賛されていますか？スーパークラスを使用することとどう違うかわかりません。 私が見る唯一の違いは次のとおりです。1-インターフェースは単一継承によって制限されませんが、それは疎結合のトピックとはあまり関係がありません。2-インターフェースには実装ロジックがないため、より「抽象的」です。しかし、それでも、なぜそんなに大きな違いがあるのか​​わかりません。 単純なスーパークラスはそうではないが、インターフェイスが疎結合を可能にするのに優れていると言われている理由を説明してください。

15 design  object-oriented  interfaces 

私たちの知識領域には、素足で圧力記録プレートの上を歩く人々が含まれます。センサーデータで人間の足が認識されると、「Foot」クラスのオブジェクトを生成する画像認識を行います。 足のデータに対して実行する必要がある計算がいくつかあります。 さて、どのAPIの方が良いでしょう： class Foot : public RecognizedObject { MaxPressureFrame getMaxPressureFrame(); FootAxis getFootAxis(); AnatomicalZones getAnatomicalZones(); // + similar getters for other calculations // ... } または： class Foot : public RecognizedObject { virtual CalculationBase getCalculation(QString aName); // ... } 今、私が思いつくことができる多くの賛否両論がありますが、どれが最も重要かを本当に決めることはできません。これはエンドユーザーアプリケーションであり、当社が販売するソフトウェアライブラリではありません。 何かアドバイス？ 最初のアプローチのプロには次のようなものがあります。 KISS-すべてが非常に具体的です。APIですが、実装も同様です。 強く型付けされた戻り値。 このクラスを継承するのは簡単です。上書きすることはできず、追加するだけです。 APIは非常に閉じられており、何も入れられず、オーバーライドされることもありません。 いくつかの短所： 新しい計算がリストに追加されるたびに、ゲッターの数が増えます APIは変更される可能性が高く、重大な変更が導入された場合、新しいAPIバージョンであるFoot2が必要です。 他のプロジェクトでクラスを再利用する場合、すべての計算が必要になるとは限りません …

15 design  c++  object-oriented  programming-practices  language-agnostic 

最近、Jaron Lanierが「フェノトロピックプログラミング」というアイデアを思いつきました。 考え方は、統計を利用して、通常「古典的な」プログラムを壊滅的にクラッシュさせる小さなエラーを選別するコンピュータープログラムで、シングルポイントインターフェイスの代わりに「表面」インターフェイスを使用することです。 2行の説明は次のとおりです。 Jaronによれば、「プロトコルの遵守である現在のソフトウェアのアイデアと、パターン認識について議論しているアイデアとの本当の違いは、私たちが作成している種類のエラーに関係している」 「ソフトウェアの考え方や作成方法を変えることはありません。プロセッサがどれほど高速になっても、約1,000万行を超えるコードを書くことはありません。」 少し長い説明はこちらです。さらに長い説明はこちらです。 だから、質問は、人々が選ぶ傾向がある明らかなロボットの支配者の意味を過ぎて見て、「フェノトロピックプログラム」を実際にどのように設計して書くのでしょうか？

15 design  program 

一方では、「捨てる人を作る」というアドバイスがあります。ソフトウェアシステムを完成させて最終製品を確認した後にのみ、設計段階で何がうまくいかなかったかを理解し、実際にそれを行う方法を理解します。 一方、設計されている同じ種類の2番目のシステムは通常、最初のシステムよりも悪いという「2番目のシステム効果」があります。最初のプロジェクトには収まらず、2番目のバージョンに組み込まれた多くの機能があり、通常は非常に複雑で過度に設計されています。 ここで、これらの原則の間に矛盾はありませんか？問題に対する正しい見解は何ですか？また、これら2つの境界はどこですか？ 私は、これらの「良い習慣」が、フレッド・ブルックスによる独創的な本「The Mythical Man-Month」で最初に宣伝されたと信じています。 これらの問題のいくつかはアジャイル方法論によって解決されることを知っていますが、根本的には、問題は依然として原則のままです。たとえば、重要な設計変更を3回スプリントすることはありません。

15 design  project-management  programming-practices  project  principles 

この質問に触発されたサードパーティライブラリの使用-常にラッパーを使用しますか？ 人々が実際にサードパーティのライブラリと見なしているものを知りたかった。 PHPの例： Zendフレームワークを使用してアプリケーションを構築している場合、Zendフレームワークライブラリをサードパーティのコードとして扱う必要がありますか？ C＃の例： デスクトップアプリケーションを構築している場合、すべての.Netクラスをサードパーティのコードとして扱う必要がありますか？ Javaの例： JDKのすべてのライブラリをサードパーティライブラリとして扱う必要がありますか？ 一部の人々は、ライブラリが安定していて頻繁に変更されない場合、それをラップする必要はないと言います。ただし、サードパーティのコードに依存するクラスをラップせずにテストする方法はわかりません。

15 programming-languages  design  object-oriented  unit-testing  terminology 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 私はC＃とASP.Netで働いている小さな会社の主任開発者です。私たちのチームは、開発と設計の経験が少ない2〜3人の小規模です。私はより多くの上級開発者から学ぶ機会がありません。自分のチームの誰も私を導き、最良のアプローチを選択するのを手伝ってくれる人はいません。 経験豊富な開発者がいない場合、実際のプロジェクトに取り組みながらソフトウェア開発スキルを向上させるにはどうすればよいですか？

15 web-development  self-improvement  development-process  experience  design 

私は約3年間アジャイル手法（SCRUM）を使用しており、特に多くのレベル（実装された機能への早期アクセス権を持つ顧客から、機能をテストできるテスターからの短期フィードバックで）それらが実装されるとすぐに、レビューなどを通じて新しいコードに関する非常に早いフィードバックを提供できる他の開発者から。 一方、私は2つの未解決の問題を抱えています。最初の問題については、この質問で説明します。 問題：良いデザインを得るのが難しい コードが乱雑になり次第、リファクタリングを試みます。できる限り単体テストを作成します（これは一般的なバグ、特にリファクタリングの際に役立ちます）。一方で、毎日のコミットで少しずつ複雑な機能を開発し、構造化されていないコードを継続的に再考すると、本当に良いデザインを作成できません。 最近作成した唯一の適切に設計されたモジュールは、別のアプローチをとることで得られました：数日間問題を分析しました（実際に問題に取り掛かる前に数か月間、問題が頭に浮かびました） ）、関係するすべてのクラスとそれらの関係の詳細な設計をさらに数日間スケッチし、その後約3週間作業を中断せずにオフィスに閉じ込めてコード全体を書き留めました。結果は、私がしばらくの間作り出した最高のものであり、バグを見つけたり修正したりするのはかなり簡単で、それ以降は関連する変更を必要としない非常に明確な設計でした。 そのため、これまでは、全体像が魔法のようにプロセスに現れることを期待して、少しずつコードを書き始めるよりも、事前にやりたいことの全体像を把握する方がはるかに効果的でした。私の最善の努力により、小刻みの開発アプローチは常に私をより悪い設計へと導いてきました。 質問：同様の経験がありますか？SCRUMを間違った方法で適用しているのですか、それとも少しずつ開発しても、うまく設計されたソフトウェアを作成したい場合、何に注意する必要がありますか？または、実際のコーディングを開始する前に、デザインユーザーストーリーをスケジュールする必要がありますか？少なくとも平均よりも複雑な機能については、これは良い習慣と考えられていますか？ 編集-注 良いデザインは絶対的なものではなく、それ自体に価値はありませんが、コンテキストに依存するという事実と、手近な問題に十分なデザインを目指すべきであるという事実を知っています。 たとえば、（1）できるだけ早く準備する必要がある、（2）一度だけ使用する、（3）しないという単純なコンポーネントを実装する必要がある場合、良いデザインを（あまり）気にしませんシステムの他の部分（YAGNI）によって使用されます。 コンポーネント（1）が数回使用され、製品のいくつかの異なるリリースで使用される場合、（2）長期にわたって保守および拡張する必要がある場合、（3）それに応じて他の多くのコンポーネントを使用する場合、良いデザインが重要です。

15 design  agile 

MVCを中心としたプロジェクトのアーキテクチャを設計しているときに質問があります。（これはC ++ / Marmalade SDKプロジェクトです。特定のMVCフレームワークは使用していません。作成しています。） いくつかの記事（元のSteve Burbek記事など）で、「MVCトライアド」という概念を読み続けています。初めて読んだとき、アプリケーションは「MVCトライアド」ユニット（想定している各UIピースに1つ）を中心に構築されているように見えましたが、これはかなり柔軟性に欠け、MVCの使用が意図されていなかったと思います。次に、この問題をさらに調査すると、コントローラーとビューの密結合の例、つまり1対1の関係が見つかりました-TextEditViewにはTextEditControllerがあります。 しかし、プロジェクトに戻ると、（AddElementControllerのような「論理ユニット」による）1つのコントローラーと、その特定のコントローラーの複数のビューがあると便利です。 私は、何らかのタブUIが必要なAddElementControllerのようなものについて明確に考えています。AddElementTabViewとタブ用の複数のAddImageView、AddSoundViewなどを持つAddElementControllerが必要ですか？または、タブビューごとに異なる「サブコントローラー」が必要ですか？ 要約すると、MVCパターン（このフレームワークのXフレームワーク固有の理解/実装ではありません）に関して、コントローラーに複数のビューがあるのは正しいですか、または各ビューに特定のコントローラーが必要ですか？ また、いくつかの状態情報をコントローラーに保持するのは正しいですか、それともステートレスである必要があります（つまり、状態を非ドメイン状態モデルに配置する必要があるということですか）。 事前にすべてに感謝します。

15 design  design-patterns  architecture  mvc 

Clean Codeの Bob Martinが推奨しているように、私は一般的に小さなメソッドを使用することを好みます。また、Objective-Cの内部についても十分に読んで、メッセージのディスパッチがどのように機能するかについて少なくともある程度理解しました（これについてはbbumsシリーズが特に有益です）。 時期尚早な最適化の懸念にもかかわらず、Objective-cがobjc_msgSendで実行するすべての作業が、実用的な観点から、Objective-Cプロジェクトには「多くの小さなメソッド」アプローチが不適切であるかどうかを知りたいと思います。 経験的な調査結果は特に歓迎します（多分私はいつか自分でテストをセットアップするでしょう）。大規模なObjective-Cプロジェクトを書いた人からの経験も素晴らしいでしょう。 明確化 質問の一般的な口調は意図的です。特定のアプリのパフォーマンスチューニングについては質問していません（そのため、SOではなくここで質問します）。Objective-Cの言語特性が特定の設計アプローチを妨げているかどうかについては詳しく説明しません。Appleや他の関係者（githubなど）から見たコードの多くは大きなメソッド（およびクラス）に向かう傾向があることに気付きましたが、これは言語のために忍び込んだバイアスかどうか疑問に思っています自体。もちろん、間違ったコードを読んでいた可能性があります。または、存在する場合は、傾向をもたらした技術的要因ではなく文化的要因である可能性があります。 （価値があることのために、私は現在Objective-Cを書いており、小さなメソッドを使用しています） さらなるリクエスト 与えられた両方の答えに同意します。さらにもう1つ欲しいのは、誰かが素敵な短いメソッド（および小さなクラス）を使用する（願わくば実質的な）オープンソース（またはそうでなければ見える）のObjective-Cコードベースを指し示すことです。Objective-Cには、たとえばフィットネスソースと比較するものはまだありません。

15 design  coding-style  objective-c 

ASP.NET MVC 2を使用して、コントローラー/ビュープレゼンテーションレイヤーと、ビジネスロジックレイヤー、データアクセスレイヤー[ストアドプロシージャおよびストアードプロシージャと通信するクラス/メソッド]で構成されるモデルを使用しています。 ビジネスレイヤー以上では、ほとんどの目的で、Editはオブジェクトの作成とオブジェクトの編集の両方を表すことができるようです。これは、「保存」メソッドを定義するリポジトリ設計パターンとよく一致します。IDが0の場合はストアドプロシージャをチェックインし、0の場合は新しいオブジェクトを作成します。それ以外の場合は、カテゴリIDが1に一致するため、既存のオブジェクトを更新できます。 議論の第一のポイントは、作成を含む編集をDALレイヤーを超えて作成と編集の別々の部分に分割することが最も理にかなっている場合です。 明らかな例をルートとして示すことができます： 作成 - のhttpを：// someurl / somearea /編集/ 0 編集 - のhttp：// someurl / somearea /編集/ 254 対 作成 - のhttp：// someurl / somearea /作成 編集 - のhttp：// someurl / somearea /編集/ 254 これに関して確立された標準やベストプラクティスはありますか？ 私はこれが小さな詳細であることを知っていますが、ロジスティック的に重要だと思います。

15 design  design-patterns  asp.net-mvc 

すぐに行う必要のある製品で作業し、うまく機能する場合、物事を迅速に完了してドアから外に出すために、設計の保守性と「ニートネス」を犠牲にするのはいつですか？そして、特にそれを「ニート」にするために使用される技術が私にとって新しい場合、それはどの程度大丈夫ですか？

15 design 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 6年前に閉鎖されました。 多くのフリーソフトウェアプロジェクトには美しいアート、特にWebサイトがあり、コーダーとアーティストの出会いはどこにあるのでしょうか。地元の美術専攻の教育委員会以外にこれを求める場所はありますか？私はIRCについて考えましたが、実際にそこに尋ねることで、小さくて頻繁なユーザーベースを悩ますかもしれないと恐れています。

15 design  free-software 

Excel（C＃および.Net 4）から読み取るクラスがあり、そのクラスには、UIの応答性を維持しながらExcelからデータをロードするバックグラウンドワーカーがあります。私の質問は次のとおりです。クラスにバックグラウンドワーカーを配置するのは悪い設計ですか。クラスなしでクラスを作成し、バックグラウンドワーカーを使用してそのクラスを操作する必要がありますか？この方法でクラスを作成することに関する問題は実際にはありませんが、それでも私は初心者なので、先に進む前に確認することを考えました。 私のコードが機能するので、これはスタックオーバーフローではないはずだと思うので、この質問がここで関連することを願っています。これは単なる設計上の問題です。

15 c#  design  multithreading  class-design