問題タブ [crc-cards]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
oop - CRC カードを使用した精巧な設計はどのように行うのですか?
私はいつも、人々が CRC (クラス責任コラボレーション) カードをどのように使用しているのか疑問に思っていました。私はそれらについて本で読んだり、インターネットで漠然とした情報を見つけたりしましたが、それを本当に理解したことはありませんでした. 私の本の 1 つで、CRC カードを使用したセッションを示す YouTube ビデオを作成する必要があると思います。私の本の 1 つで、テキストで定式化するのは非常に難しいと説明されているため、「すでにマスターしている誰かに教えてもらう」必要があります。悲しいことに、私はここで CRC カードを使用している人を誰も知らないので、もっと知りたいと思っています。
アップデート
この手法を詳しく説明している人々を示すビデオへのリンクを歓迎します。
crc-cards - CRC カードに協力者を記載するのはなぜですか?
CRC カードでは、依存関係だけでなく、すべての協力者をリストするのはなぜですか。つまり、クラス A が B の関数を呼び出す場合、なぜ A が B クラスの CRC コラボレーターのセクションで言及されているのでしょうか。A の CRC カードで B が既に述べられているように、単純に B の CRC カードに A を残す方がはるかに良いでしょう。このようにして、CRC カードからも依存関係を把握できます。また、A が必要とする B クラスの関数名がわかっている場合は、A の CRC カードにもそれを記載できます。これは、クラス図とシーケンス図をすばやく生成することでさらに役立ちます。B in A コラボレーターと A in B コラボレーターに言及することで実現される具体的な機能は何ですか?
uml - crcカードの共同編集者
User、Address、OrderProductの3つのクラスがあるとします。
ユーザーには、名前、電話番号、住所などのフィールドがあります。ここで、addressはAddressのインスタンスです。
製品の注文を処理するクラスであるOrderProductがUserに格納されているアドレスを必要とする場合、Userをコラボレーターとしてリストするだけですか、それともUserクラスにアドレスクラスが含まれているので、Addressクラスをコラボレーターとして含める必要がありますか？
oop - システムの設計にCRCカードはまだ使用されていますか?
CRC カードは、システムを作成する前にシミュレートするためのシンプルで直感的な方法の 1 つとして知られています。多くの人がその良さを称賛し、いくつかの批判をしていますが、実際の使用法や良いケーススタディについてのしっかりした例を見つけることができませんでした.
YouTube では、CRC メソッドの使用方法の直接的な例を 2 つしか提供していません。どちらもアメリカ人ではなく、メソッドの作成者でさえ 2 人の偉大なアメリカ人です ^^. 何が面白いの？
ここで、設計セッションで実際に CRC を使用する人の数を知りたいですか? それはまだ有効ですか、それとも素晴らしいですか？調査し、練習し、何時間も費やす価値はありますか?
architecture - SOA サービスの機能的責任を決定する方法
SOA サービスの機能的責任を特定するために使用できるツールや方法論を見つけるために、(主に Google で) 検索してきました。私の検索では、実際には何も思いつきませんでした。
現在、機能的責任を決定するために私が使用しているアプローチはアドホックであり、実際には単なる直感です。
- すべての顧客関連機能は顧客サービスに入ります
- すべての支払い関連の機能は支払いサービスに入ります
- 等
ソフトウェア設計/アーキテクチャの世界で使用されている他のアプローチを振り返ると、次のようになります。
オブジェクト指向分析には、クラスの責任を決定するクラス責任コラボレーション(CRC) モデルの概念があります。
私の理解では、ドメイン駆動設計 (DDD) には、ドメインを論理的に分割する境界付けられたコンテキストの概念があります。
従来のソフトウェア アーキテクティングでは:
- 本Process of Software Architectingには、ソフトウェア コンポーネントとその責任を識別するために使用される CRC と同様のアプローチがあります。
- アーキテクチャ ベースの設計プロセスには、責任と機能領域を分割するための手順があります。
質問: SOAアーキテクトは、サービスの機能的責任を決定するためにどのようなツール/方法論を持っていますか?
model-view-controller - model-view-controller の CRC カード
Model View Controller アーキテクチャ パターンの Class Responsibility Collaboration カードについて簡単な質問がありました。
モデル クラスのカードにビューとコントローラー クラスがコラボレーターとして含まれていないのはなぜですか?
ありがとう！