2016-12-26 6 views
1

特定のクラスを構築する最良の方法を決定するのに何らかの問題があります。クラスは設定としていくつかの文字列を取り、メソッドは設定に基づいてさまざまな種類のグラフを作成します。pythonどのようにこのクラスを構造化する

たとえば、それは、クラスとしてこれを構築するのが最善である場合

c = ChartEngine(type='line', labels='foo bar', data='1, 2', data2='3, 4') 
chart = c.make_chart() 

IDK ...このように呼ばれる、または私はちょうど置く必要がある場合は、同じモジュール... IDKで他の関数を呼び出すだけで機能することができ機能のロジックで、make_chart関数を呼び出すように設定するか、または他の方法がある場合に使用します。

どのようにこのようなクラスを構成しますか?

+0

明示的に同じ値をチェックして渡すのではなく、 'make_chart(type)'をうまく呼び出すことができます。 –

+0

if/elifテストで '='の代わりに '=='を使います。また、これは少し広すぎる - それは主に意見に基づいているため、おそらく閉鎖されてしまうだろう。 –

+0

さて、あなた自身の癖にかかっています。私にとっては、 '__init__'に設定を保存し、既に保存されている設定を読み込んで' make_chart'を明示的に呼びたいと思います。 – Acepcs

答えて

2

これは設計上の問題です。問題の性質上、多くの主観的アプローチを使用することができます。あなたのソースは一般的に分離され、今後の変更は簡単ではないような方法でプログラムを設計するのが最適です。しかし、オーバーエンジニアリングは事ですので、手元の要件を考慮してください。いろいろなアプローチが特定の利益を生み出すことができる以下に例を示します。

あなたはChartサブクラス介して各種のチャートを派遣することができますChartEngine(あなたがを述べてきたように)と呼ばれるマスターコントロールクラスを持つことができます。その後、さまざまなバリエーションのスーパークラスとして機能するChartという基本クラスを実装できます。あなたのプログラムの性質は、私の意見では構成よりも継承に合っています(、もう一度、多くの異なるアプローチを使用することができます)。

class Chart(object): 
    def __init__(self): 
     pass 
    def draw(self): 
     pass 
    ... 
Chart

その後の継承を介してベースクラスの機能をオーバーライド/伸びます。あなたはその後、例えばLineクラスのようなものを実装することができます:MVCのWebアプリケーション内のルートに似た様々なグラフタイプごとに、発送方法を持っているChartEngineについては

class Line(Chart): 
    pass 

class Bar(Chart): 
    pass 

を、あなたはクラスを持っている可能性があります。 1つのアプローチは、様々なグラフとそれに関連するディスパッチメソッドを追跡する辞書を持つことです。

class ChartEngine(object): 
    type_to_dispatch = {"bar" : dispatch_bar, "line" : dispatch_line} 
    def __init__(self, type, labels, data): 
     self.type = type 
     self.labels = labels 
     self.data = data 
     ... 

    def make_chart(self): 
     type_to_dispatch[self.type]() 
    def dispatch_line(self): 
     pass 
    def dispatch_bar(self): 
     pass 
+0

私はこの考えが好きです。 'dispatch'メソッドの内部にあるように見えますが、チャート型(' Chart'サブクラス)は正しく整理されますか? – deltaskelta

+0

それは考えです。あなたがそれについて行くことができる広大な方法があるので、私はそれらの不完全なものを残しました。重複したコードを避けるためにグラフをディスパッチする方法を定義する 'Dispatch'クラスを作ることさえできます。または、コンストラクタをすぐに呼び出すことができます。たくさんのオプション。 – ospahiu

3

テストをデザインツールとして使用します。あなたが望む簡単な最小限の機能のテストを書く。それが失敗すると、それを通過させるのに必要な最小限のコードを書いてください。次に、他の機能を持つ他のテストを作成し、失敗させます。この開発サイクル(TDD)を使用すると、ユーザーの観点から設計し、実装の適切なカプセル化と抽象化を実施します。 pytestモジュールについて知りたいことがあります。

あなたのクラスはあまりにも多くの異なることについてあまり知っていると私は言うでしょう。 SRPやその他のソリッドの原則について読むことで、この問題を開始することができます。最も重要なのは、現在必要なものだけを実装することです。

FinalyのChartEngineは、エレガントなコードで実装するのが難しいかもしれない抽象的なファクトリパターンのユースケースのようです。最も簡単なユースケースとリファクタを早期に開始してください。

+0

これは、完璧なソリューションを前もって設計する時間を費やすことなく、自然かつ有機的にチャートエンジンを進化させるのに役立ち、実際には非常に良いアイデアです。 Pythonはすでに言語自体に組み込まれている多くの工場パターンを持っており、MROやオペレータのオーバーロードなどで複数の継承をサポートしているため、オブジェクト指向はJavaの方法では最適な解決策ではないかもしれません。 – Eddie

関連する問題