- 2
@Harry19911: ja bym zrobił klasę PrepaidSendSms która ma wstrzyknięte te dwie klasy, i ona odpowiada za wysłanie i pobranie środków z konta
skąd wiesz czy później nie będziesz potrzebował wysłac sma z jakichś punktów, albo rozliczał smsy na koniec okresu itd. itd. więc po co od razu robić klasę SendSMS taką ciężką
of course pewnie klasa SendSMS może dispatcheować jakieś eventy ale raczej powinno to służyć do jakiegoś general loga
skąd wiesz czy później nie będziesz potrzebował wysłac sma z jakichś punktów, albo rozliczał smsy na koniec okresu itd. itd. więc po co od razu robić klasę SendSMS taką ciężką
of course pewnie klasa SendSMS może dispatcheować jakieś eventy ale raczej powinno to służyć do jakiegoś general loga
- 1
@Harry19911: Plus dla @Jaslanin za dobre rozwiązanie – kompozycja. Masz jeden wyspecjalizowany obiekt do wysyłania SMSów, masz drugi wyspecjalizowany obiekt do płatności – zrób trzeci, który połączy te dwa zadania.
Twoje rozwiązanie – z wstrzykiwaniem obiektu płatności do wysyłacza SMSów – też uznałbym za akceptowalne, ALE pod warunkiem, że sygnaturę zależności uzależnisz od interface'u: tzn proponowałbym, żeby
W ten sposób masz luźniejsze powiązanie i oprócz/zamiast opłat możesz dorzucić także dodatkowe rzeczy,
Twoje rozwiązanie – z wstrzykiwaniem obiektu płatności do wysyłacza SMSów – też uznałbym za akceptowalne, ALE pod warunkiem, że sygnaturę zależności uzależnisz od interface'u: tzn proponowałbym, żeby
SendSms (BTW, czemu nie SmsSender?) dostawał w konstruktorze obiekt spełniający interface SmsSendAuthorizer->auhorize($this, $orWhateverYouNeed).W ten sposób masz luźniejsze powiązanie i oprócz/zamiast opłat możesz dorzucić także dodatkowe rzeczy,

















Przyszło mi na myśl, że w sumie to chciałbym poznać nieco i nabrać praktyki w pisaniu aplikacji
http://pl.phptherightway.com
Doctrine jest trochę pomieszany, może najpierw spróbuj RedBeanPHP - prosty do bólu, zero konfiguracji itp