Czy obiekt powinien wypisać się do pliku, czy inny obiekt powinien na nim działać, aby wykonać operacje wejścia/wyjścia?

Question

UWAGA: Przepraszam za długie pytanie!

Próbuję zrozumieć niektóre kluczowe obszary leżące za orientacją obiektową i nie mogłem zdecydować w ten czy inny sposób o moim konkretnym pytaniu.

Załóżmy, że mam obiekt pełen uroczych danych. Boba klasy.

Bob myBob = new Bob("This string is data"); 

Powiedzmy, że chcemy zapisać zawartość myBob do pliku XML (bob.xml)

Powinienem akt obiekt na bob do zapisu zawartości na zewnątrz, czy też nie mam myBob to?

Przypadek 1: ustawa o obiekcie

Writer myWriter = new Writer(myBob, "C:\\bob.xml"); 

Przypadek 2: Zapisz metoda

myBob.Save("C:\\bob.xml"); 

Niektórzy ludzie są siding z opcją jednej jak to znaczy jeśli kod do zapisu plików jest zmieniony, nie musi być aktualizowany dla każdej metody składowania; promowanie ponownego użycia kodu, jak przypuszczam. Moim problemem jest pobieranie wszystkich danych z obiektów, które mogą mieć prywatne dane bez akcesora.

Sprawą dla opcji drugiej jest to, że metoda działa tylko na dane przechowywane przez obiekt i tak powinno być. Brak zakłóceń od innych obiektów.

Czy odpowiedź na moje pytanie jest jedną z tych "zależnych od sprawy"? Jeśli tak, to skąd wiadomo, że jedna metoda jest preferowana w stosunku do drugiej?

Answer 1

Właściwe podejście, ogólnie rzecz biorąc, to Przypadek 1. Utrzymuje on jedną odpowiedzialność za klasę (cokolwiek robi) bez powiązania jej z określonym mechanizmem trwałości (dysk).

Patrzysz na konkretny przypadek bardziej uogólnionego problemu: Serializacja. To dobrze i dobrze, bo obiekt ma jakiś sposób na wskazanie, jak powinien być serializowany - to jedyny byt, który wie, co jest niezbędne do jego deserializacji. Ale jeśli sprawisz, że obiekt sam się zapisze na dysk, to ściśle powiązałeś ten obiekt z konkretną implementacją.

Zamiast tego rozważ utworzenie interfejsu, którego uogólniony "program piszący" może użyć do "serializowania" obiektu do tego, do którego serializowany jest pisarz. W ten sposób będziesz mógł przekształcić się na dysk, do sieci, do pamięci, do wszystkiego, czego potrzebujesz do serializacji. :)

Answer 2

Zrobiłbym Bob wiedzieć, jak serializować się, ponieważ ma prywatne dane. Inny obiekt (taki jak Twój Writer) weźmie to i umieści go na dysku. Bob wie, jak najlepiej radzić sobie z danymi, ale nie musi przejmować się tym, jak i gdzie jest przechowywany. Twój programista wie, jak najlepiej zapisać dane, ale nie musi dbać o to, jak tworzone są dane.

Answer 3

Kiedyś wolałem opcję 2; jednak, jak zacząłem naprawdę próbować zrozumieć i modelować domeny, nad którymi pracuję, wolę opcję 1.

Wyobraź sobie, że Twoje pojazdy modelujące. Dlaczego pojazd wiedziałby, jak przetrwać? Może wiedzieć, jak się poruszać, jak zacząć i jak się zatrzymać, ale czym jest Save w kontekście pojazdu.

Answer 4

myślę prawidłowe podejście jest przypadek 1, ale klasa może być określony w taki sposób, aby skorzystać z obu podejść:

class Bob { 

    IWriter _myWriter = null; 

    public Bob(){ 
     // This instance could be injected or you may use a factory 
     // Note the initialization logic is here and not in Save method 
     _myWriter = new Writer("c://bob.xml") 
    } 

    //... 
    public void Save(){ 

     _myWriter.Write(this);  

    } 
    // Or... 
    public void Save(string where){ 

     _myWriter.Write(this, where); 

    } 
    //... 
} 

To może być łatwo modyfikowane, aby umieścić logikę pisania i inicjalizacji w sposób podstawowa klasa, więc klasa Boba jest jeszcze czystsza i niezależna od trwałości.

Answer 5

Jest to przykład miejsca, w którym można użyć wzoru projektowania strategii . Twój obiekt myBob może mieć instancję klasy, która ją zapisze. Możesz chcieć, aby program piszący implementował interfejs lub wywodził się z klasy abstrakcyjnej, aby można było łatwo zmienić procedurę składowania.
Dzisiaj zapisujesz w formacie xml, ale może być konieczne, aby obiekt był nadal przechowywany w bazie danych. Ten wzór pozwoli ci łatwo zmienić procedurę zapisu. Mógłbyś nawet zmienić sposób zapisywania w środowisku wykonawczym.

Answer 6

Wykonaj:

public interface Writable { 
    public void Save(Writer w); 
} 

public interface Writer { 
    public void WriteTag(String tag, String cdata); 
} 

public class Bob : Writable { 
    private String ssn = "123-23-1234"; 
    public void Save(Writer w) { 
     w.WriteTag("ssn", ssn); 
    } 
} 

public class XmlWriter : Writer { 
    public XmlWriter(Sting filename) {...} 
    public void WriteTag(String tag, Sting cdata) {...} 
} 

Oczywiście nie jest to kompletne rozwiązanie, ale należy uzyskać ogólne pojęcie.

Answer 7

Jedną z innych metod jest użycie wzoru gościa. Niech twój obiekt zawiera metodę Accept, która przechodzi przez członków, których chcesz przetworzyć/serializuje, i niech odwiedzający będzie twoim serializatorem. Za każdym razem, gdy aktualizujesz lub zmieniasz serializację (zwykły tekst na xml na binarny), nie musisz aktualizować obiektu.

Mieliśmy dobre doświadczenia w pracy, robiąc to w ten sposób. Jest całkiem potężny.