[MacDada]

Mam sobie encję. Chcę na niej i jej plikach wykonać „niebezpieczne” operacje, więc wypadałoby się zabezpieczyć backupem.

Mam dwa pomysły jak to zrealizować. Opinie?

Encja i jej backup:

https://gist.github.com/MacDada/c9a7480c5ba613a43e98

Pomysł1:

BackupFactory

:

https://gist.github.com/MacDada/9459c182ac40cd35bd22

+ zwięzłe użycie i implementacja

-

Task

musi znać dwie klasy (

Backup

i

BackupFactory

)

- magia (backup sam znika wraz z obiektem)

Pomysł2:

BackupManager

:

https://gist.github.com/MacDada/f60b59c12ee7bcc5c1b9

+ backup jest wyraźne usuwany

+

Task

musi znać jedną klasę (

BackupManager

)

- więcej kodu przy użyciu i implementacji

#programowanie #php #refactoring #wzorceprojektowe

[Dzakus]

1

[Dzakus]

2

[Dzakus]

Ja głosuje na 2. Kod jest bardziej wyrazisty i łatwiej w przyszłości się go będzie czytać. Konstruktory i destruktory nie służą do tego do czego chcesz je użyć, wiec może to budzić niezrozumienie.

[k.....o]

@MacDada: Jaki backup factory? To zadne faktory nie jest... Jesli juz chcesz kombinowac to zrob sobie serwis do backupowania, wstrzyknij go do commanda i na nim operuj. Destruktor jest wywolywany w momencie unsetowania obiektu, nie sluzy do usuwania go. Tak samo constructor, w konstruktorze tylko ladujesz propertiesy, backupo powinien odbywac sie w innej metodzie. Faktory to wzorzec projektowy, poczytaj o nim.

[MacDada]

@kmicolo: Sorry, ale co do tego, że nie jest to fabryka, to się nie zgodzę.

BackupFactory

służy dla mnie jako klasa produkująca

Backup

. Tym samym obiekt–konsument (

Command

) nie musi wiedzieć jak utworzyć

Backup

oraz jaka jest implementacja

Backup

u – oczekuje jedynie, że od fabryki dostanie obiekt z metodą

restore()

lub wręcz

BackupInterface

.

https://en.wikipedia.org/wiki/Factory_method_pattern#PHP

Co do konstruktorów/destruktorów – też mnie to martwi, przede wszystkim jako „magię”. Obiekt