Java - značkovací interface

[Karl]

Co je to značkovací interface v Javě?

[Reklama]

[MarSik]

Tipoval bych že správné klíčové slovo bude Anotace. Google pak vrátí třeba tohle: https://www.tomas-dvorak.cz/posts/java-anotace/

[zamek]

Interface, ktery nedefinuje zadne metody, "pritomnost znacky" se pak kontroluje treba pomoci instance of. Typicky priklad je java.io.Serializable.

[Sten]

Rozhraní, které nemá žádnou metodu, ale označuje třídy, které něco umí nebo k něčemu slouží:
https://en.wikipedia.org/wiki/Marker_interface_pattern

[Ondra Satai Nekola]

Sten a Zamek maji pravdu, jen doplnim, ze je to spis relikt z doby pred prichodem @anotaci.

[Reklama]

[Wavelet]

Sten a Zamek maji pravdu, jen doplnim, ze je to spis relikt z doby pred prichodem @anotaci.

Podle mne to relikt být nemusí viz *Effective Java: Item 37*.

[phi]

Jen poznamka - marker interface zdedi i potomci tridy, zatimco anotace je konkretni tride.

[Filip Jirsák]

Jen poznamka - marker interface zdedi i potomci tridy, zatimco anotace je konkretni tride.

Což je zrovna u toho Serializable špatně.

Jak píšou ostatní, používalo se to v případech, které se dnes řeší anotacemi. Ty příklady z Effective Java ukazují zase jen příklady, kdy mají současné anotace v Javě nějaká omezení a může se vyplatit hackovat to pomocí značkovacích rozhraní místo hackování anotací.

[Kit]

Jen poznamka - marker interface zdedi i potomci tridy, zatimco anotace je konkretni tride.

Což je zrovna u toho Serializable špatně.

Mohu vědět, proč je to špatně? Je přece obvyklé, že potomek dědí po rodiči všechno.

[Sten]

Mohu vědět, proč je to špatně? Je přece obvyklé, že potomek dědí po rodiči všechno.

U té serializace, potomek může přidávat členy, které nemusí být serializovatelné, ale to značkovací rozhraní už nejde odebrat.

Ale existují rozhraní, kde to dává smysl, třeba javax.net.ssl.TrustManager nebo java.rmi.Remote.

[Kit]

Mohu vědět, proč je to špatně? Je přece obvyklé, že potomek dědí po rodiči všechno.

U té serializace, potomek může přidávat členy, které nemusí být serializovatelné, ale to značkovací rozhraní už nejde odebrat.

Takový potomek by však nesplňoval LSP, neměl by tedy vůbec vzniknout.

[Filip Jirsák]

Ale existují rozhraní, kde to dává smysl, třeba javax.net.ssl.TrustManager

Podle mne teda nedává smysl celý package javax.net.ssl od první do poslední třídy, a rozhraní TrustManager v tom není výjimkou. To není značkovací rozhraní, i v JavaDocu má napsané, že je to base interface. Zřejmě podle autorů  toho rozhraní je trust manager něco, co neumí vůbec nic.

javax.net.ssl má smysl akorát jako ukázka toho, že někteří programátoři dokáží v C++ programovat v libovolném jazyce. Kdybychom na to měli jenom Xerces, mohlo by se říct, že je to náhoda nebo omyl – proto máme stejným stylem naprogramované ještě javax.net.ssl, aby bylo jasné, že to byl záměr. Problém je v tom, že zatímco Xercesu se lze celkem snadno vyhnout, bez javax.net.ssl se v Javě neobejdete, pokud chcete používat SSL/TLS.

[Filip Jirsák]

Takový potomek by však nesplňoval LSP, neměl by tedy vůbec vzniknout.

To platí možná v případě, pokud se programuje čistě objektově. To ale není moc častý případ, dnes se většinou programuje „s objekty“, nebo jak to nazvat. Stačí, že si třeba do objektu potomka serializovatelné výjimky uložíte neserializovatelný objekt – parametr, který výjimku způsobil – a rázem máte neserializovatelný Serializable objekt.

[Sten]

Takový potomek by však nesplňoval LSP, neměl by tedy vůbec vzniknout.

Tak jasně, pokud by to bylo podle teorie OOP, tak stačí značkovací rozhraní*. Jenže reálně to nejde vždycky zařídit, stačí, když potomek třeba drží spojení přes MPI, zastupuje nějaký OpenGL objekt nebo má data v JNI, a už to nejde serializovat bez obrovského (a zbytečného, když se to nepoužije) úsilí, typicky tak, že si to pamatuje všechny kroky, jak byl ten objekt vytvořen. Často se to řeší, že ta třída implementuje readObject, která vyhazuje UnsupportedOperationException. Bohužel to nejde snadno prohnat anotačním procesorem, který se může pokusit detekovat případy, kdy se takový neserializovatelný objekt pokoušíte serializovat, a tím, že je to opt-out místo opt-in, je to dost náchylné na to, že to někdo zapomene implementovat, a pak se to třeba neodhalí ani testy, protože třeba u toho OpenGL jsou identifikátory objektů inty, u dat v JNI to zase bývají longy jakožto 64bitové pointery, oboje serializátor bez problémů sežere, a pokud se to ten test nepokusí deserializovat v jiném procesu, tak to dokonce bude fungovat.

* tedy ani ta značkovací rozhraní nedávají v čistém OOP smysl, protože nepřidávají žádnou funkčnost; to, co to značkovací rozhraní využívá, by správně mělo být implementované v tom samotném rozhraní, ale to je dané limitací Javy < 8, která neuměla default metody

[Kit]

Takový potomek by však nesplňoval LSP, neměl by tedy vůbec vzniknout.

Tak jasně, pokud by to bylo podle teorie OOP, tak stačí značkovací rozhraní*. Jenže reálně to nejde vždycky zařídit, stačí, když potomek třeba drží spojení přes MPI, zastupuje nějaký OpenGL objekt nebo má data v JNI, a už to nejde serializovat bez obrovského (a zbytečného, když se to nepoužije) úsilí, typicky tak, že si to pamatuje všechny kroky, jak byl ten objekt vytvořen.

Otázkou je, zda v takových případech má ještě dědičnost smysl a zda není výhodnější ji nahradit kompozicí.