OOP – služba nebo továrna na službu

mystik napsal(a):

S kolegou souhlasim ze tahle nutnost volat type, ktera neni nijak vynucena ani patrna je zaklad pro budouci chyby.

Za me bych sel cestou tovarny.

Proc vadi kdyby bylo vice instanci? Obecne tomu muzes zabranit navrhovym vzorem Singleton, ale to ze ho potrebujes je obvykle spis naznak, ze by neco melo byt nabrzeno jinak aby voce instanci nevadilo. Dela to pak problemy pri testovani apod.

Za me jeste par otazek:
Co za type je $formField? Nejde $type poznat z nej?
Co presne dela addFilter? Meni nejak stav te validacni sluzby nebo neco dela s $formField?

Ahoj,
prvně díky za komentář.

Nevadí, že by měla více instancí. Jen jsem poznačil, že víc instancí mít asi nikdy nebudu (tak jestli to nevadí) a že tu továrnu vidím jako nejreálnější možnost, protože ten typ prostě je potřeba explicitně nastavit.

$formField je instance formulářového prvku (je to v mém případě vždy TextInput) a $type je zcela něco jiného, tím detekuji rodičovský obal a jaké filtry na $formFieldu budu vyvolávat (uvnitř třídy mám seznam všech filtrů a pak konfiguraci a pořadí pro každý $type).

AddFilter nedělá nic jiného než něco jako (opět pseudo)

<?php
foreach ($this->getConfigurationByType($this->type)['filters'] as $filter) { // $filter je tedy \Closure
  $formField->addFilter($filter);
}
?>

Takže továrna tedy bude asi nejvhodnější, 1 způsob je tedy mlhavý a nečitelný a kolegův návrh ale také není zcela v pořádku ne?
V ideálním světě by to byla kolekce tříd, ale to tady ted rozebírat nechci, zajímá mě čiště jen toto :-)

Děkuji.

Vidím největší rozdíl v tom, že v prvním případě jde o sdílenou službu, kterou můžeš používat na různých místech aplikace, zatímco v druhém případě je sdílenou službou továrna, kterou vyrobíš jednu instanci a tu pak používáš na jednom místě.

Což v tvém případě vypadá jako takřka identická záležitost, jako kdyby ta služba byla třeba formulář v malé aplikaci, kde je jen jeden formulář.

Ale u formuláře cítím, že je to spíš shoda okolností, že je v aplikaci jen jeden, a určitě nepotřebuju, aby se předával na různé místa aplikace pomocí autowiringu, takže bych si i na ten jeden formulář udělal raději továrnu, tedy bych šel cestou 2 automaticky.

$form->addText('foo')->setOption('validationType', 'Text');

David Grudl napsal(a):

Vidím největší rozdíl v tom, že v prvním případě jde o sdílenou službu, kterou můžeš používat na různých místech aplikace, zatímco v druhém případě je sdílenou službou továrna, kterou vyrobíš jednu instanci a tu pak používáš na jednom místě.

Což v tvém případě vypadá jako takřka identická záležitost, jako kdyby ta služba byla třeba formulář v malé aplikaci, kde je jen jeden formulář.

Ale u formuláře cítím, že je to spíš shoda okolností, že je v aplikaci jen jeden, a určitě nepotřebuju, aby se předával na různé místa aplikace pomocí autowiringu, takže bych si i na ten jeden formulář udělal raději továrnu, tedy bych šel cestou 2 automaticky.

První odstavec jsi pochopil správně, zatím je to na jednom místě a asi to do budoucna nebudu potřebovat, ale co kdyby.
Potřebuji jen jak jsem již psal, nastavit typ parametru, takže řeším jak co nejvíc čitelněji a neskrytě. To ostatní jak jsem psal v předposledním postu pro mé potřeby docela v pořádku.

A formulář asi do toho netahejme, v tomto místě (administrace) je prostě formulář, na jiném místě to bude řádek z DB, takže potřebuji zase nastavit datový typ a něco s hodnotou toho parametru udělat.

Takže továrna co přes typ vyrobní onu třídu? A je jedno, že v tuto chvili to potřebuji na jednom místě a vic než jednu instanci zatím nepotřebuji a třeba ani potřebovat nebudu, je to v pořádku? Nebo je nějaké pravidlo, že továrna se zpravidla dělá pro potřeby více instancí?

Pozorně jsem četl https://doc.nette.org/…introduction#… takže si nejsem jist jestli postupuji správně.

PS. Nějaký nástřel kódu (stačí pseudo) at vím přesně co tím myslíš?

Editoval Klobás (21. 11. 2023 23:29)

Kamil Valenta napsal(a):

Pokud jsou filtry a validace závislé na setType, tak by mi ve všech případech vadilo, že to nemám na očích. Že zavolám na dvou místech $trida->validate() a ona mi jednou vrátí true, podruhé false. A já si musím všimnout, že někde je jiný ->setType, konstruktor, factory…

Asi by se mi pak více líbila $trida jako wrapper nad poděděnými třídami dle type.
Volání

$trida->text->validate();
$trida->numeric->validate();

je pak jednoznačné.

Pokud filtry na type závislé nejsou, pak bych jen separoval jednotlivé validační metody.

$trida->validateText();
$trida->validateNumeric();

Myšlenku chápu, ale asi to není potřeba, nebo co si mám představit pod $trida->text->validate() že se interně provede?

A filtry na sobě zavislé nejsou, existuje obecný seznam, (samozřejmě některé filtry mají jasné regexpy pro konkrétní situace) ale můžou se mezi sebou kombinovat.

Kamil Valenta napsal(a):

Takže vůbec nepotřebuješ znát type v počátku. Je Ti přece jedno, jaká hodnota do objektu vstoupí.
Na vstupu můžeš mít z inputu „1“, a při volání:

$trida->validateText(); // => (string) "1"
$trida->validateNumeric(); // => (int) 1
$trida->validateBoolean(); // => (bool) TRUE

Už je více jasné, proč to chtěl Tvůj kolega jako parametr metody validate(). Jako samostatné metody to ale bude napovídat a člověk si nemusí pamatovat možné hodnoty pro type (které by byly konstantami).

Ahoj,

no to ano, ale nepoužije se jenom validate, použije se ještě addFilter a případně se může použít zase další metoda, která uvnitř pracuje s tím typem, takže hypoteticky budu muset v celém procesu použít 3 funkce závislé na typu a tech typů bude později více třeba 10, tak budu muset mít ve výsledku 30 funkcí dle této logiky? (Ano, dá se to přes __call na pozadí vyřešit, abych se neupsal, ale to se mi nelíbí).

Postup ve smyslu

<?php
$type = 'Numeric';
$trida = tridaFactory->create($type);

$trida->addFilter($formField);
$trida->validate($formField);
$trida->necoDalsiho();

?>

mi přijde pochopitelnější než

<?php
$trida->addFilterNumeric($formField);
$trida->validateNumeric($formField);
$trida->necoDalsihoNumeric();
?>

nehledě na to, že klidne v onom jednom procesu zavolám addFilterNumeric a podtím (protože jsem blb) validateText a logicky to je špatně …

Pokud mám někde mezeru, prosím o upřesnění a díky za čas.

Filtry uvnitř jsou zavislé na typu.

Takhle jsem to myslel.

<?php
	private function getRules(string $type): array
	{
		$x = [
			'Text' => [
				'validators' => [],
				'filters' => [
					'filterTrim'
				],
			],
			'Boolean' => [
				'validators' => ['validateIsBoolean'],
				'filters' => [
					'filterTrim',
					'filterLowerCase',
				],
			],
			'Numeric' => [
				'validators' => ['validateIsNumber', 'validateIsNumberRange'],
				'filters' => [
					'filterTrim',
					'filterCommaToDot',
					'filterRemoveSpaces',
					'filterRangeWords',
					'filterRangeDash',
				],
			]
		];

		return $x[$type];
	}

?>

Můžeš mi říct, co se na pozadí stane, když zavolám $trida->**numeric**->validate()

Jinak samozřejmě ta třída má uvnitř seznam podporovaných typů a kontrolu, jinak selže (Exception).

Kamil Valenta napsal(a):

Klobás napsal(a):

Můžeš mi říct, co se na pozadí stane, když zavolám $trida->**numeric**->validate()

$trida je kolekce tříd předávaná jako service.
$trida->numeric->validate() zavolá metodu validate() nad objektem numeric.
Pokud totiž každý „type“ má své validátory, své filtry, případně své vlastní metody necoDalsiho(),
nedává smysl mít to v jedné třídě a oddělovat to typem.
Měly by to být samostatné třídy se společným interfacem.

Jinak samozřejmě ta třída má uvnitř seznam podporovaných typů a kontrolu, jinak selže (Exception).

A necítíš rozdíl mezi psaním stringu a mačkáním F5 dokud se exceptiony nezbavím a napsáním → a našeptáním možných variant?

Pochopil jsem :-)

mystik napsal(a):

Pokud $type neni nejaky predavany parametr ale uvadis ho tam exixitne tak souhlas s @KamilValenta. Idealne mit polymorfni tj. interface Validator, jeho implementace jako NumericValidator, TextValidator a ta predavana service bude tovarna nebo rovnou kolekce hotovych instanci.

Mas nejaky duvod proc pouzivas takovy slozity config v poli misto explicitniho kodu? Chapal bych pokud ten config musis nacitat z nejakeho externiho zdroje, ale tohle vypada jen jako hardcoded config. A takovahe zbytecna magie je dobry zaklad na spoustu osklivych bugu, narocne refaktorovani, neumozni to naseptavani a statickou analyzu, …

Pokud config chces zachovat tak bych minimalne zvazil si ty filtry predavat jako first-class callable a ne string.

Uff. Nejsem backendak, pulce věcí nerozumím, což není omlouva, ale je to prostě tak.

Nevím co je first-class callable, něco jako [Trida:class] ?

Vzniklo to jako nevinná hra a začalo se to nabalovat, není prostor pro refactoring (časový ani finanční).

Každopádně díky za pohled.