単純なものでも継承より委譲を選んだほうが良いのか?

この質問のあと、他のトランプゲームにも応用が利くようにブラックジャックのコードを書き換えました。
(以下概略)

Python
1# game_components.py 概略
2class Card
3class Deck
4class PlayerBase:
5    self.hands: List[Card]
6    self.bankroll: int
7    
8    self.draw()
9    
10    @abstractmethod
11    self.score()  # @propertyとして実装
12
13class GameBase:
14    self.deck: Deck
15
16    @abstractmethod
17    self.play()
18
19    @abstractmethod
20    self.reset()

Python
1# blackjack.py 概略
2class BlackjackPlayer(PlayerBase):
3    self.score()
4class BlackjackDealer(BlackjackPlayer):
5    self.score_based_strategy()  # draw()でディーラーのみ必要
6
7class SimpleBlackjack(GameBase):  # ベットなしのブラックジャック
8    self.__init__():
9        super()
10        self.player: BlackjackPlayer
11        self.dealer: BlackjackDealer
12    self.play()
13    self.reset()
14
15class Blackjack(SimpleBlackjack):  # ベットあり
16    self.__init__():
17        super()
18        self.bet: int
19        self.default_bet: int
20        self.is_double_down: bool

コード全文は長さの制約により乗り切らなかったため、Gistに置いてあります。
blackjack.py | GitHub Gist

いくつかのトランプゲームのルールを調べたうえで、プレイヤーにはそれぞれの手札と種銭が、ゲームの場にはトランプ1組が共通すると判断してPlayerBase, GameBaseを抽出しました。
今後これらを継承する際もブラックジャックのコードと同様、1つのゲームXxxxにつきclass XxxxPlayer(PlayerBase), class XxxxDealer(PlayerBase or XxxxPlayer), 賭けなしのclass SimpleXxxx(GameBase), 賭けに伴う処理を含めたclass Xxxx(SimpleXxxx)の高々4つ程度しか作らず、何重にも入れ子になった継承はしないだろうと考えています。

ですが、このコードを書いたあとネットでクラス設計について調べていると、継承よりも委譲を強く推奨する意見が多く見られました。
1重, 2重程度の継承すらも悪のように書かれているものもあるので、初心者としてはどうすればいいのか困惑しています。
趣味で書いているものとはいえ、できれば良いコードにしたいです。
これくらいの規模(継承の深さ?)でも継承は徹底して避けたほうが良いのでしょうか?
よろしくお願いします。

行動規範の内容に同意します

回答3件

むしろこの規模だと、10行に満たないBaseをちまちま作るご利益がないなと思ってしまいました。

Pythonはダックタイピングできるのでという事情で余計にそう見えているという面はあるかもしれないけど、にしても

「ブラックジャックのプレイヤーとポーカーのプレイヤーで異種試合」

とかやらないだろうから、インターフェースを統一したところでなにも嬉しくないし。逆に、その程度の統一しか求められてないし問題からしてもできないから、Baseが要らない子に。。。

どうせコンフリクトしないでしょということで実際的に問題にならないとしたら、理念の問題なのでどっちでもいいです。is-a関係を満たすので継承でおkというのも一理あるでしょう。委譲で書くと。。。あ、そもそも抽象基底しかなかったりすると委譲の議論に乗らない気がします。

投稿2019/12/08 12:18

編集2019/12/08 12:34

hayataka2049

総合スコア30935

ベストアンサー

「継承より合成」は、おそらく「継承か合成、どっちでもいいなら合成を使いましょう」という 経験則 なのかなと思っています。

経験則なので、これが何か論理的に正しいというわけではなく、ただ、継承か合成、どっちか迷ったら、とりあえず合成にしておいた方が良いということではないかなと思っています。

KISS の原則

継承の欠点は、本来使わないはずの機能も使える様になってしまうことです。使わない機能が使える様になって何が問題なのでしょうか？継承は「KISS の原則」と相反するものなのかなと思っています。

KISS の原則 (英: KISS principle) とは、「Keep it simple stupid.」（シンプルで愚鈍にする）、もしくは「Keep it simple, stupid.」（シンプルにしておけ！この間抜け）、もしくは「Keep it short and simple.」（簡潔に単純にしておけ）という内容の、1960年代の米国海軍において言われた、経験的な原理・原則[1]の略語。その意味するところは、設計の単純性（簡潔性）は成功への鍵だということと、不必要な複雑性は避けるべきだ、ということである。

「KISS の原則」も原則というよりも、おそらく 経験則 かなと感じますが。そのため「じゃあ、なんで設計の単純性（簡潔性）は成功への鍵なのか？」、あるいは「KISS の原則は正しいのか？」と聞かれると答えに窮してしまうのですが...

依存性逆転の原則

「継承より合成」は、言い換えれば「使うメソッドだけ渡して、使わないメソッドは使わせない」とも言えるかなと思います。これと同じことが「依存性逆転の原則」に見られます。

「依存性逆転の原則」も過度に単純化している可能性があるのですが、「関数あるいはメソッドの引数にはオブジェクトをそのまま渡さず、必要な属性だけ渡せ」ということだと思っています。

python
1# player をそのまま渡すのではなく
2monster.damaged(player)

python
1# 必要な属性だけ渡す
2# Player.attack -> (damage, type)
3monster.damaged(player.attack())

「依存性逆転の原則」も論理的に正しいわけではなく、そういう経験則、どっちか迷ったらそうやっておくと良いとということなのかなと思っています。

今回のケースは？

今回のケースは BlackjackPlayer, BlackjackDealer と PlayerBase は、ほぼ完全に is-a 関係 を満たしている様に思えます。なので、個人的には継承でもいいんじゃないかなと思っています。今回のコードは、継承の方がわかりやすいコードなのではないかなと個人的に思っています（わかりやすさ、というのは個々人で議論の分かれるところではあるとは思うのですが）。

継承が一律に悪いわけではないのかなと思っています。継承の方が、即ち全部一括で渡してしまう方が、コードを書くのは楽です。依存性逆転の原則にしても、わざわざ必要な属性に分割したりして渡すのは面倒です。

これはちょうどグローバル変数を使うのと似ています。ウェブアプリケーションフレームワークの Flask は、グローバル変数を多用するというアンチパターンをあえて踏みながら、カジュアルに書けることで、とても人気を博しました（と個人的に思っています）。

is-a 関係 をちゃんと満たす、あるいはコードに変更があったとしても is-a 関係 満たし続けてくれることは、なかなか無いのかなという中で Go, Rust といった言語では、継承という機能が切られてしまったのかなと思っています。

それでも今回のケースでは、継承の方がわかりやすいんじゃないのかなと思ったりもしています。