Rozdział 14 · Tworzenie rzeczywistych obiektówklasa czy nie? Projektowanie modeli
Nie każde zadanie wymaga klasy — a zły wybór nie jest od razu widoczny, lecz dopiero wtedy, gdy kod staje się trudniejszy do odczytania.
Nie każde zadanie wymaga zajęć
Po 24 rozdziałach o klasach łatwo dojść do wniosku, że klasą należy otaczać wszystko. To nie tak — klasa jest przydatna, gdy istnieje I stan, I zachowanie, które ma sens trzymać razem, i gdy będzie kilka obiektów tego rodzaju, z niezależną historią.
class SredneeArifmeticheskoe:
def __init__(self, chisla):
self.chisla = chisla
def vychislit(self):
return sum(self.chisla) / len(self.chisla)
rezultat = SredneeArifmeticheskoe([4, 8, 15]).vychislit()# Код работает правильно — ошибка не во время выполнения,
# а в самом ДИЗАЙНЕ: слишком много церемоний для одного вычисленияTechnicznie rzecz biorąc, to działający kod, ale nie ma stanu rzeczywistego (obiekt jest tworzony i używany raz) ani wielu instancji — tylko obliczenia udawające klasę. Zwykła funkcja jest łatwiejsza do odczytania i testowania: srednee(chisla). Klasa jest uzasadniona, gdy obiekt żyje przez jakiś czas I zmienia stan jako Player z sekcji 14.9, nie gdy istnieje w jednej linii.
def srednee_arifmeticheskoe(chisla):
return sum(chisla) / len(chisla)
rezultat = srednee_arifmeticheskoe([4, 8, 15])Dla każdego scenariusza zdecyduj, co jest bardziej odpowiednie — funkcja czy klasa, i uzasadnij: (1) konwersja temperatury z Celsjusza na Fahrenheita; (2) konto bankowe z saldem i historią operacji; (3) sprawdzenie, czy liczba jest pierwsza.