Tworzę obiekt, którego jedynym celem jest odczytanie pliku jednego formatu i utworzenie innego w innym formacie.
Czy najlepiej jest utworzyć plik wyjściowy niejawnie podczas inicjowania obiektu, czy też mieć metodę publiczną, która daje użytkownikowi wybór, kiedy ten plik zostanie utworzony?
Odpowiedzi:
Jeśli pracujesz w języku, który go obsługuje, podam metodę Save, która pobiera strumień. W ten sposób użytkownik może zapisać dane tam, gdzie chce.
Zapisanie zajmuje 20 sekund dłużej niż zapisanie tylko do pliku, ale programista łatwo to rozumie, a na stronie wywołującej jest bardzo jasne, co się naprawdę dzieje.
Sposób, w jaki to opisałeś (obiekt, który czyta dane wejściowe i dane wyjściowe do innego pliku) wydaje się dziwny. Jaki jest cel budowy obiektu, który robi wszystko podczas budowy?
Nazwałbyś to w ten sposób?
var stuff = DoStuff();
new SaveFileWeirdClass(stuff);
return;
W przypadku każdej rozsądnej implementacji SaveFileWeirdClass nie spodziewałbym się żadnych skutków ubocznych od samego jej utworzenia. Czytanie pliku - w porządku. Tworzysz plik? Nie.
Wydaje mi się to w ten sposób jaśniejsze:
var stuff = new StuffReader(); //Better name needed...
string filePath = this.whatever;
using(Stream stream = new FileStream(filePath))
stuff.Save(stream);
Jeśli chcesz zrobić to w klasie, utwórz go podczas inicjalizacji. Opóźnienie tego kroku powoduje dwie złe rzeczy: Po pierwsze, dodaje dodatkowy, wyraźny krok dla osoby dzwoniącej, która nie stworzyłaby obiektu w pierwszej kolejności, gdyby nie zamierzała go użyć do wygenerowania wyniku. Po drugie, dodaje co najmniej dwa punkty, w których kod w klasie musi podjąć decyzję o tym, czy plik jest otwarty i obsłużyć ten warunek: raz, gdy idziesz do zapisu wyniku, i raz podczas niszczenia, kiedy go zamykasz. Ten pierwszy oznacza, że musisz sprawdzać podczas każdego zapisu, co może być marnotrawstwem, jeśli wykonujesz wiele z nich.
Osobiście nie zrobiłbym tego i wybrałbym, aby program wywołujący przekazywał do konstruktora wstępnie otwarte uchwyty plików. Utworzenie pliku wewnątrz klasy wyklucza udostępnienie wywołującym opcji wykonywania takich czynności, jak ustawianie uprawnień lub, w przypadku zapisu na urządzeniu, inicjowanie specyficzne dla urządzenia. Jeśli chcesz mieć wersję swojej FooConverterklasy, która działa na plikach i działa tworzenie kreacji, zapakuj go w FooFileConverter.
Wyraźnie.
Chcesz się upewnić, że nie polegasz na sprytnych regułach skutków ubocznych, które mogą się złamać w przyszłych wersjach lub na nietypowych architekturach. Oczywiście powinieneś mieć domyślny plik, który użytkownik może zastąpić, jeśli zechce.
Oprócz innych argumentów za jawną metodą: Jeśli wykonujesz pracę w konstruktorze, to zmuszasz każdego użytkownika swojej klasy do obsługi wyjątków tylko w celu utworzenia obiektu. Może to prowadzić do wielu kodów typu „kocioł”.
Zobacz /programming/6086334/is-it-good-practice-to-make-the-constructor-throw-an-exception w celu omówienia tego.