問題タブ [software-design]

今日、「C++ でのコーディングの相当な経験と、構造化設計原則の完全な基礎」を必要とする職務記述書を目にしたので、これらの原則とは何かを考えてみました。最初はC++と「構造化設計」を一言で言うとちょっと変だなと思ったのですが、C++はマルチパラダイムプログラミング言語なので、Cと同じように使われているのかなと思いました。ウィキペディアのページも調べて読みました例外処理とステート マシンについては、構造化されていない設計 (当然のことです) ですが、まだ多くのことが不足しているように感じます。では、構造化ソフトウェアの設計で最も重要な原則は何ですか?

数か月前、独立系ソフトウェア開発会社の代表者 2 人が主催するプレゼンテーションに出席しました。それは主に、優れたソフトウェア設計と実践に関するものでした。

2 人は主に Java について話していましたが、状況によっては、コンストラクターの代わりに getInstanceOf() を使用するのが非常に良い方法であると言っていたのを覚えています。これは、コンストラクターではなく異なるクラスから常に getInstanceOf() を呼び出すようにすることと関係があり、大規模なプロジェクトでははるかに優れたアプローチでした。

ご覧のとおり、今はあまり覚えていません :/ しかし、彼らが使用した議論には本当に説得力があったことを覚えています。あなたの誰かがそのようなデザインに出くわしたことがあるのだろうか、いつ、それは役に立つと思いますか? それとも全然ないと思いますか？

私は、グループ プロジェクトで次のタスクを担当しています。

a) アーキテクチャ コンテキスト図の設計/描画
b) ACD 記述
c) UML 配置図

オンラインには簡単なリソースがたくさんあるので、UML 配置図は問題ではありませんが、ACD には当てはまりません。

ACD とは何か、ACD を描く方法についてのリソースが必要です。

Architecture Interconnection Diagram や Operations Systems Diagram などの Architecture Context Diagram などの ACD の別の名前はありますか? Google 検索でよく似た名前で別の図に出くわす...

チームに基本的な設計原則を導入する必要があります。オブジェクト指向のデザイン原理だけにとどまらない本を探しています。そして、モジュール性、情報隠蔽などの概念をカバーすることができます。情報のためだけに-私たちのチームのすべてのプロジェクトの実装言語はCです。

MVC の一般的な意味で、View と Controller の関係は一般的に M:1 であると予想されますか? つまり、多くのビューが同じコントローラーを使用しますか? しかし、ビューは多くの異なるコントローラーを使用しませんか?

または、任意のビューを任意のコントローラーと交換して、すべてを機能させることができますか? 現時点では、2 つの間にかなり緊密な依存関係があるため、現在のレイアウトでは機能しません...

クラス プロジェクト用に何かを設計しようとしていますが、ビューとコントローラを整理/設計する方法がわかりません。

更新: これまでに受け取った回答は役に立ちましたが、決定的なものではありません。私の質問を少し広げてみましょう。振り返ってみると、重要な側面は、モデルが変更できるということです (戦略パターン*) ある例では、モデルはデータベースを作成する場合があります。別の方法では、データベースから読み取ることができます。私の当初の設計目標は、すべてのモデルを処理できる統一された (シンプルではありますが) ビューを配置することでした。

*コントローラーは戦略パターンの実装と見なすことができると読みました ( here )。私のモデルは、似ていますが別の方法で実装されます。

これは、概念の簡単な（不完全な）クラス図です（更新された情報が与えられた場合）：

私の MVC 実装概念のクラス図 http://theopensourceu.com/wp-content/uploads/2010/02/MVC-2334703.png

ソフトウェア開発に関する記事を読んでいると、「クリーンなインターフェース」という言葉をよく耳にします。人々は、API とクラスのクリーンなインターフェースについて話しました。

「クリーンなインターフェース」をどのように定義しますか? クリーンなインターフェイスを備えたシステムを設計するためのガイドラインはありますか?

私は、就職の面接とあまりフォーマルでない場の両方で、ソフトウェア設計への私のアプローチについて尋ねられた例がいくつかありました。ウォーターフォール モデル、アジャイル開発、デザイン パターン、UML、テスト駆動開発、要件ドキュメント、ユーザー受け入れテストなどなど、常に多くの流行語が出てきます。

私の答えは常に、最善のアプローチは当面のプロジェクトに依存するということです。ウォーターフォール モデルを、UML ダイアグラムを使用した 3 ページのパンフレット サイトの設計仕様書に使用するのは、おそらくやり過ぎです。同様に、生命維持装置の制御システムのコードをすぐに書き出すのは得策ではありません。

しばらくすると、質問者は、「彼は概念を理解していないので、率直な答えはしないだろう。カウボーイに違いない」と考え始めると、この怪しい目つきを見せ始めます。「正式な」ソフトウェア エンジニアリング プロセスについては、次のように説明するだけの方がよいことがわかりました。 UML とデザイン パターンを多用した仕様書を作成し、6 か月間コードに打ち込みます...

では、説得力を持たせるにはどのようなアプローチを使用すればよいのでしょうか。さまざまなプロジェクトでの私の経験について話しますか、それともサマービルを逆流させますか?

Stackoverflowが、特定のユーザーからのすべての質問を取得できるWebサービスを提供していると仮定します。ユーザーAからすべての質問を取得するリクエストは、次のjson出力になります。

必要な方法でデータを操作して表示したい場合は、ローカルデータベースにダンプするのが賢明ですか？ある時点で、各質問のすべての回答を取得して、ローカルデータベースに保存することもできます。

私が考えているワークフローは次のとおりです。

1. ユーザーがログインします。
2. Webサービスは、ログインしたユーザーからの質問をすべて取得し、ローカルデータベースにダンプします。
3. ユーザーは特定の質問に対するすべての回答を求めています。別のWebサービスがそれらを取得し、ローカルデータベースにダンプします。
4. ユーザーがログアウトしたら、そのユーザーからのすべての質問と回答をローカルデータベースから削除します。

ビジネス ロジックをどこに配置するかについての議論にいつも出くわします。つまり、アプリケーション コードのビジネス レイヤー内に配置するか、ストアド プロシージャの観点から DB 内に配置するかです。個人的には1番のアプローチになりがちですが、私の個人的な見解に影響を与えることなく、最初にあなたの意見を聞きたいと思います. 万能のソリューションが存在しないことは承知しており、多くの要因に依存することがよくありますが、それについては話し合うことができます。

ところで、私たちはWebアプリケーション（Oracle DBを持つ）のコンテキストにあり、現在のアプローチは

• UI 入力を受け取り、最初のクライアント側検証を行う UI レイヤー
• ユーザー入力の検証を含むビジネス ロジックを含む多数のサービス クラスを含むビジネス レイヤー (サーバー側)
• 永続化/読み取り操作を行うために DB からストアド プロシージャを呼び出すデータ アクセス レイヤー

ただし、多くの人は、ビジネス層のもの (特に検証に関して) をストアド プロシージャの観点から DB に移動する傾向があります。

あなたはそれについてどう思いますか？議論したいです。

デザインパターンについて読んでいると、このフレーズに出くわします。

でもよく分からないので誰か説明してくれませんか？