Zaczynam dopiero eksplorować SOLID i nie jestem pewien, czy czytanie z plików i pisanie do plików to ta sama odpowiedzialność.
Celem jest ten sam typ pliku; Chcę czytać i pisać .pdf w mojej aplikacji.
Aplikacja znajduje się w Pythonie, jeśli to robi jakąkolwiek różnicę.
Implementacja odczytu i zapisu prawdopodobnie ma duże prawdopodobieństwo, że będzie bardzo spójna. Gdyby jedno się zmieniło, to i drugie. Wysoka spójność jest silnym wskaźnikiem Jednej Odpowiedzialności, a Zasada Jednej Odpowiedzialności mówi nam, że należy je połączyć w tej samej klasie. Jeśli operacje te mają niską spójność, istnieje prawdopodobieństwo, że ich podział poprawi łatwość konserwacji.
Jeśli jednak istnieją konsumenci, którzy czytają dane tylko bez zapisu lub tylko piszą bez odczytu, oznacza to, że z perspektywy interfejsu należy rozdzielić te operacje, zgodnie z zasadą segregacji interfejsu. Oznacza to, że konsumenci powinni zdefiniować dwa interfejsy, na których mogą polegać, podczas gdy Fileklasa zaimplementuje oba interfejsy.
Kiedy zastosujesz zasadę SOLID do zaprojektowania obiektu, możesz rozważyć odczyt i zapis pliku jako JEDEN obowiązek - praca z trwałymi danymi
Nie należy jednak umieszczać odczytu i zapisu pliku w tej samej metodzie lub funkcji.
Wydaje się, że większość innych odpowiedzi przeoczyła fakt, że w twoim pytaniu brakuje jednej kluczowej informacji - nie powiedziałeś nam, czy i w jaki sposób dokumenty, które zamierzasz przeczytać i napisać, są powiązane!
Czy twoja aplikacja ma coś w rodzaju „obiektu dokumentu” i zapisuje to najpierw w pliku PDF, a następnie ponownie czyta ten sam plik w podobnym obiekcie dokumentu? Lub odwrotnie, czyta pliki PDF w dokumencie, wprowadza pewne modyfikacje i ponownie zapisuje ten sam dokument w nowym pliku PDF? Zatem czytanie i pisanie powinno być postrzegane jako jedna odpowiedzialność. Może tak być w przypadku, gdy aplikacja jest lub zawiera coś w rodzaju komponentu „edytora PDF” lub „zestawu narzędzi do manipulacji PDF”.
Jeśli jednak jedna część aplikacji tworzy niektóre pliki PDF, na przykład w komponencie raportującym, a inna niepowiązana część aplikacji odczytuje różne pliki PDF (na przykład, ewaluator załączników poczty dla wyszukiwarki), a także wewnętrzna reprezentacja te ostatnie pliki PDF nie mają nic wspólnego z pierwszym przypadkiem użycia, wtedy te zadania mają inne obowiązki.
Szczególnie w przypadku plików PDF ten drugi przypadek użycia jest przypadkiem, który widziałem znacznie częściej w różnego rodzaju aplikacjach. Istnieje o wiele więcej bibliotek / komponentów, które obsługują tylko tworzenie plików PDF, i tylko znacznie mniejsza liczba, która obsługuje również czytanie plików PDF. Jeśli zamierzasz korzystać z jednej biblioteki do generowania plików PDF, a zupełnie innej do czytania plików PDF, powinno być oczywiste, że czytanie i pisanie PDF będą osobnymi obowiązkami.
Według ( Roberta C. Martina ) odpowiedzialność to zestaw funkcji, które służą konkretnemu aktorowi.
Aktor powinien być jedynym źródłem zmiany danej odpowiedzialności (powinien istnieć tylko jeden powód zmiany).
W twoim przypadku należy najpierw zdefiniować aktorów jako pierwszy krok, a następnie zadać pytania:. Czy są aktorzy zainteresowani tylko czytaniem plików, a inni pisaniem?
W takim przypadku odczytywanie i zapisywanie plików to dwa odrębne obowiązki. Ponieważ będzie wiele źródeł zmian (wielu aktorów może poprosić o zmianę logiki czytania i to samo w przypadku pisania).
źródło