nie jest prawdą, że łamie SRP. Po pierwsze, nie jesteśmy w programowaniu obiektowym.
Co to ma do rzeczy?
Masz rację, w sumie nic, SRP ma zastosowanie też wszędzie indziej. Ale... :)
Po drugie, dzielenie tego na mniejsze funkcje (a już w ogóle robienie z tego klasy) to dopiero byłby przerost formy.
Ile linijek musi mieć kod, żeby zacząć pisać go poprawnie?
Zarówno mój jak i @Mokrowski'ego kod jest poprawny (a w sumie OPa też), więc o co chodzi? A Twojego ne widzieliśmy, więc nie mogę się wypowiedzieć... Te kody mogą być niezgodne z czyimiś wytycznymi, brzydkie, nieczytelne, nieczyste itp., ale braku poprawności chyba nie da się tutaj wykazać...?
Po trzecie, ten kod ma tylko jedną odpowiedzialność: "pobierz dane wymuszając poprawność".
To są dwie rzeczy. Dodaj "i wypisując komunikaty", to już będą trzy rzeczy.
Ale o ziarnistości (granularity) słyszałeś? To jest -- wbrew może temu, co sądzisz -- rzecz dość subiektywna i zależna od konkretnego projektu, modułu/klasy, zarządzania itp... Zresztą, oryginalne sformułowanie SRP definiowało odpowiedzialność jako "reason to change" (Bob Martin), a to już naprawdę zależy od konkretnego otoczenia klasy/funkcji (czyli od całego projektu).
Rzuć okiem na przykład tutaj:
https://en.wikipedia.org/wiki/Talk:Single_responsibility_principle
https://stackoverflow.com/questions/3720516/how-granular-do-i-get-with-my-class-design-when-trying-to-follow-the-solid-princ
https://softwareengineering.stackexchange.com/questions/154723/how-to-determine-if-a-class-meets-the-single-responsibility-principle
No i warto pomyśleć chwilę, jak mają zdefiniowane odpowiedzialności standardowe klasy bibliteczne -- wydaje mi się, że raczej szerzej, niż Ty to zaprezentowałeś.
W końcu po czwarte, SRP to nie świętość. :)
SOLID również nie jest świętością, olać DRY, a wzorce projektowe to mity ;-)
Ja pisałem tylko o SRP, reszta to Twoje zdanie. :)
A poważniej -- w SOLID wszystko oprócz S (czyli właśnie SRP) jest dużo konkretniej sformułowane...