いつクラスにするか

01 / 06

手に入れた道具をならべる

この章で手に入れた道具をならべてみよう。

設計図 … class / __init__ / self
ふるまい … メソッド / __str__
受けつぐ … 継承 / オーバーライド / super()

新しい文法はもう出てこない。ここからはいつ使うかの練習だよ。使う道具は、第2章までのリスト・辞書・くり返しも込みだ。

02 / 06

辞書のままでいいとき

クラスを覚えると、何でもクラスにしたくなる。でも辞書のままで十分なことは多いよ。

目安はこれ。

持ち運ぶだけのデータ → 辞書でいい
データと、それを使う処理がセットになっている → クラスにする

名前と点数を並べて表示するだけなら、辞書のほうが短いし読みやすい。

seito = {"namae": "ゆい", "ten": 82}namae = seito["namae"]ten = seito["ten"]print(f"{namae} {ten}てん")

実行結果

ゆい 82てん

03 / 06

クラスにすると変わること

話が変わるのは、そのデータを使う処理が増えてきたときだよ。辞書のままだと、その辞書を前提にした関数があちこちに散らばる。

クラスにまとめると、データと処理が1か所にそろう。「この人の評価は？」と知りたくなったら、その人自身に聞けばいい。

class Seito:    def __init__(self, namae, ten):        self.namae = namae        self.ten = ten    def hyouka(self):        if self.ten >= 80:            return "よい"        return "ふつう"s = Seito("ゆい", 82)print(f"{s.namae} {s.hyouka()}")

実行結果

ゆい よい

04 / 06

1つのクラスに1つの役割

クラスは何でも入る箱なので、放っておくとどんどん太る。会員クラスに、レシートの印刷も、メールの送信も、売上の集計も入れてしまう——これがいちばんよくある失敗だよ。

目安は「このクラスを一言で説明できるか」。「会員1人ぶんのデータと、その人についての判断」なら説明できる。「会員とレシートとメール」と言い出したら、分けどきだね。

05 / 06

継承は「〜の一種」と言えるときだけ

継承も使いすぎると危ない。子は親の一種であると声に出して言えるかで決めよう。

プレミアム会員は会員の一種である → 言えるので継承していい
かごは商品の一種である → 言えない。これは「かごが商品を持っている」関係なので、リストで持つのが素直

「コードが似ているから」という理由だけで継承すると、あとから必ず苦しくなるよ。

class Kago:    def __init__(self):        self.shinamonos = []    def ireru(self, namae):        self.shinamonos.append(namae)kago = Kago()kago.ireru("パン")kago.ireru("のり")print(len(kago.shinamonos))

実行結果

06 / 06

まず読めるようになる

クラスは、覚えることが多いわりに「ありがたみ」が実感しにくい章でもある。小さなプログラムなら、辞書と関数だけでも書けてしまうからだ。

でも、あなたがこれから使うライブラリのほとんどはクラスでできている。人の書いたコードに class が出てきたとき、「これは設計図だな」「これは親から受けついだメソッドだな」と読めること。書けるようになる前に、まず読めるようになる。それだけでも十分な収穫だよ。

それじゃあ、10問やってみよう。あとの問題ほど大きくなるよ。