3

私は継承をどこまで真剣に受け止めるべきかわかりません..

私のアプリケーションには、ほとんどのアプリケーションと同様に、顧客、ユーザー、およびサプライヤーがいます。

簡単に思えますが、詳細にこだわるには、次のことを行う必要があります。

class Person {...}


class NaturalPerson extends Person {...}

class JuristicPerson extends Person {...}



class User extends NaturalPerson {...}

class Supplier extends JuristicPerson {...}

さて、顧客とは何ですか？私の意見では、彼らは自然人であり、法人でもある可能性があります...

class JurCustomer extends JuristicPerson {...}

class NatCustomer extends NaturalPerson {...}

すべての顧客を取得したい場合は、対応する2つのテーブルを選択する必要があるため、これを操作するのはばかげています...

基本的にはタイプごとのテーブルスキーマを好むでしょう...しかし、上記の階層によれば、少し複雑になる可能性があります。

まあ、これはほんの一例です。多くの場合、階層はより複雑になります...

4

2 に答える 2

1

抽象化の不必要なレイヤーは、何の利点も提供せずに複雑さを追加します。

あなたがしなければならないことは、共通の祖先を共有するクラスからどのような実装上の利点が得られるかを判断することです。

アプリを設計するための最良の方法は、扱っているエンティティと関係を正確に表すデータベース スキーマから始めることだと思います。次に、そのスキーマをミラーリングするクラスを作成します (タイプごとのテーブル)。

次に、その時点で同様のクラスの機能を検討するときに、異なるタイプが基本クラスを共有することでメリットがあるかどうかを判断します。たとえば、この設計手法に基づいて、Customer クラスと Supplier クラスが作成されます。要件の一部は、宛名ラベルを印刷するための情報を取得する方法が必要であることを示しています。この情報にたどり着くまでのプロセスが同じである場合、そのメソッドを実装するように拡張する抽象クラスを設計することは理にかなっています。

これは、アプリの設計時にコピー ペースト コーディングを管理するのに役立ちます。

于 2013-06-19T07:08:21.703 に答える