1

私の経歴: 私はソフトウェア業界での仕事を探している最近の卒業生です。質問: 私は最近、ソフトウェア会社の 1 つとのインタビューで、銀行システムの UML ダイアグラムを描くように依頼されました。銀行システムには、預金と当座預金などの 2 つの口座があり、利息の計算方法が異なります。

私の解決策: Accountクラスを抽象クラスにしました。
次のように: public abstract class Account{ ...... } このクラスには、すべてのアカウント タイプに共通する、deposit() と draw() の 2 つのメソッドが定義されています。抽象メソッドである別のメソッド CalculateInterest() 。

アカウント クラスを拡張し、アカウント クラスを実装する 2 つのクラスの保存とチェック。例: public class Saving extends Account { ... }

銀行や銀行の場所などの UML を追加するために他のクラスを追加しましたが、これはインタビュアーを満足させず、彼はプロセス全体をインターフェイスとして実装することを望んでいましたが、私はそれをよく理解していませんでした。同じ情報を抽出しようとしましたが、インタビュアーを喜ばせませんでした。

ここにいる人々が共有できる情報は、デザインを理解し、さらにインタビューにアプローチする方法を理解するのに大いに役立ちます.
そこにはたくさんのデザインパターンがあることは知っていますが、彼が特定のインターフェースについて言及したとき、私はそれにアプローチする方法がわかりませんでした.

4

1 に答える 1

3

通常の銀行業務プロセスでは、すでに適切な回答を提供しています。ただし、複雑な銀行の要件については、よりモジュール化された設計が必要であり、それがインターフェイスが輝く場所です.

基本設計では、次のように述べています。

  • すべてのアカウントで入金が可能
  • すべてのアカウントで引き出しが可能
  • すべてのアカウントで利息を計算できます

現在の設計で、要件が次のようになっているとします。

  1. のタイプを作成するにはaccount、deposit. 出金不可、クローズのみ（定期預金など）
  2. のタイプを作成するにはaccount、withdraw. depositを開けたときにいくらかのお金があると言ってaccount、それからあなたは しかできませんwithdraw。
  3. accountのみ可能で、またはCalculateInterestは不可能な のタイプを作成するには。depositwithdraw
  4. 等々

設計では、基本クラスを継承し、Accountサポートされていないアクション (預金など) ごとに実装されていない例外をスローする場合があります。ただし、(訂正してください) これは LSP に違反しており、実行時例外のリスクがあります。

インターフェイス ベースを使用すると、いくつかのインターフェイスを宣言する必要があります。

  • IAccount (これには、残高、ユーザー ID などの基本的なプロパティがあります)
  • IDepositable : IAccount
  • IWithdrawable : IAccount
  • IClosable : IAccount
  • ICalculateInterestable : IAccount

次に、要件として、クラスを宣言できます。

  1. IDepositable、IClosable、ICalculateInterestable の実装
  2. IWithdrawable、IClosable、ICalculateInterestable の実装
  3. IClosable、ICalculateInterestable の実装

これは最もきれいな設計ではないかもしれませんが、銀行の要件のほとんどを十分に満たすはずです。

于 2013-06-05T02:51:42.807 に答える