Jak w przypadku każdej reguły, myślę, że ważną rzeczą tutaj jest rozważenie celu reguły, ducha, a nie zanurzenie się w analizowaniu dokładnego sformułowania reguły w jakimś podręczniku i tego, jak zastosować ją w tym przypadku. Nie musimy podchodzić do tego jak prawnicy. Celem tych zasad jest pomoc w pisaniu lepszych programów. To nie jest tak, że celem pisania programów jest przestrzeganie zasad.
Celem zasady pojedynczej odpowiedzialności jest ułatwienie zrozumienia i utrzymania programów poprzez uczynienie każdej funkcji jedną samodzielną, spójną rzeczą.
Na przykład napisałem kiedyś funkcję, którą nazwałem „checkOrderStatus”, która określa, czy zamówienie jest w toku, jest wysyłane, zamawia z powrotem, cokolwiek, i zwraca kod wskazujący, który. Potem pojawił się inny programista i zmodyfikował tę funkcję, aby zaktualizować ilość dostępną w momencie wysyłki zamówienia. To poważnie naruszyło zasadę pojedynczej odpowiedzialności. Inny programista czytający ten kod później zobaczy nazwę funkcji, zobaczy, w jaki sposób została użyta wartość zwracana, i może nigdy nie podejrzewać, że dokonał aktualizacji bazy danych. Ktoś, kto musiał uzyskać status zamówienia bez aktualizacji dostępnej ilości, znalazłby się w niezręcznej sytuacji: czy powinien napisać nową funkcję, która powiela część statusu zamówienia? Dodaj flagę, aby powiedzieć, czy wykonać aktualizację bazy danych? Itp.
Z drugiej strony nie wybrałbym nic, co stanowi „dwie rzeczy”. Niedawno napisałem funkcję, która wysyła informacje o kliencie z naszego systemu do systemu naszego klienta. Ta funkcja dokonuje ponownego formatowania danych, aby spełnić ich wymagania. Na przykład w naszej bazie danych mamy pola, które mogą mieć wartość null, ale nie pozwalają one na wartości null, więc musimy wypełnić tekst zastępczy „nieokreślony” lub zapomnę dokładnych słów. Prawdopodobnie ta funkcja wykonuje dwie czynności: ponownie sformatuje dane ORAZ je wyśle. Ale bardzo celowo umieszczam to w jednej funkcji zamiast „reformatować” i „wysyłać”, ponieważ nie chcę nigdy, nigdy wysyłać bez formatowania. Nie chcę, aby ktoś napisał nowe połączenie i nie zdawał sobie sprawy, że musi zadzwonić do sformatowania, a następnie wysłać.
W twoim przypadku zaktualizuj bazę danych i zwróć obraz zapisanego rekordu, wydają się dwiema rzeczami, które mogą się ze sobą logicznie i nieuchronnie połączyć. Nie znam szczegółów twojej aplikacji, więc nie mogę definitywnie stwierdzić, czy to dobry pomysł, czy nie, ale brzmi to realistycznie.
Jeśli tworzysz w pamięci obiekt, który przechowuje wszystkie dane rekordu, wykonujesz wywołania bazy danych, aby je zapisać, a następnie zwracasz obiekt, ma to sens. Masz przedmiot w swoich rękach. Dlaczego nie oddasz go z powrotem? Jeśli obiekt nie został zwrócony, w jaki sposób osoba dzwoniąca mogłaby go zdobyć? Czy musiałby przeczytać bazę danych, aby uzyskać właśnie napisany obiekt? To wydaje się raczej nieefektywne. Jak znalazłby płytę? Czy znasz klucz podstawowy? Jeśli ktoś deklaruje, że „legalne” jest, aby funkcja zapisu zwróciła klucz podstawowy, aby umożliwić ponowne odczytanie rekordu, dlaczego po prostu nie zwrócić całego rekordu, abyś nie musiał? Co za różnica?
Z drugiej strony, jeśli tworzenie obiektu różni się znacznie od zapisu rekordu bazy danych, a osoba dzwoniąca może chcieć wykonać zapis, ale nie utworzyć obiektu, może to być marnotrawstwem. Jeśli osoba dzwoniąca może chcieć obiektu, ale nie wykonuje zapisu, musisz podać inny sposób uzyskania obiektu, co może oznaczać napisanie zbędnego kodu.
Myślę jednak, że scenariusz 1 jest bardziej prawdopodobny, więc powiedziałbym, że prawdopodobnie nie ma problemu.