[Hatespinner]

Ten uczuć kiedy musisz robić refactor, bo #!$%@?łeś nazewnictwo.

Przyjmijmy, że masz prosty pattern:

ServiceHost

klasa która obsługuje hosta. Proste jak fabuła odcinka Chłopaków do wzięcia.
Problem powstaje gdy wasz obiekt nazywa się Service. Wtedy klasa:

ServiceService

zaczyna wygladać zabawnie. Ale w zyciu nie ma łatwo i jeżeli w aplikacji mamy Resty to siłą rzeczy powstało:

ServiceServiceService

Czyli Usluga obsługi obiektu Service. To nawet nie jest poniedziałek karwa. ( ͡° ʖ̯ ͡°)

#java #programowanie

[k.....l]

ServiceHost

@Hatespinner: A nie HostService?

[Hatespinner]

@kisi3l: Nie, bo Service z tylu determinuje ze to WebService od hosta. Z przodu logicznie dotyczy co sie dzieje z obiektem:
DestroyHost, MoveHost itp

Efekt koncowy i tak taki sam.

[k.....l]

@Hatespinner: Nie podoba mi się takie nazewnictwo. DestroyHost świadczy o tym, że mamy do czynienia z pewnym zachowaniem obiektu.

[Hatespinner]

@kisi3l: Kazdy przyjmuje taka konwencje jaka pasuje. Ja od lat używam tej bo jest moim zdaniem najbardziej logiczna. HostDestroy to klasa ktora by niszczyla Hosta. HostDestroyService - usluga ktora odpala niszczenie Hosta itd.

[Hatespinner]

@zranoI: Nie ma ani jednego ani drugiego, to przyklady. Service, bo to jest klasa ktora przeprowadza roznego rodzaju maintenance. Serve to mi pachnie jakims podawaczem, meh.

[w0If]

@Hatespinner: może zrób HostManager ( ͡° ͜ʖ ͡°)