Cześć!

Zacznijmy tym razem od przypomnienia pewnej sławnej sceny:

”- A z łokcia… w ryja, wolno?!

– Nie wolno…

– A kolanem… w jaja?!

– Pewnie Cię zawiodę, ale zdecydowanie należy się powstrzymać… ”

Po co przywołuję tę scenę? Chcę zmienić profil Newslettera na polskie komedie? A może na nostalgię za latami 90tymi? Kuszące, ale nic z tych rzeczy.

Przywołuję tę scenę, bo przyszła mi od razu do głowy, gdy oglądałem prezentację Scotta Wlaschina - Designing with Capabilities.

Tworząc nasz kod zwykle zastanawiamy się holistycznie co ktokolwiek będzie mógł z nim zrobić. Przykładowo tworząc generyczne repozytorium z automatu definiujemy metody Create, Update, Get, Delete - bo kiedyś możemy chcieć ich użyć. Czy jednak chcieć to móc? Nie zawsze. Czy ktoś inny niż administrator będzie mógł tworzyć słowniki? Niekoniecznie.

Co zrobimy z naszym kodem gdy klient stwierdzi, że niektórzy użytkownicy mogą zmienić tylko część pól? Co gdy się okaże, że tak naprawdę nie mamy metody Update tylko ChangeAddress, Confirm, UpdateTitle. Każdy z nas pewnie spotkał się z kodem, który na początku zaczynał się fajnie od generycznego kodu, a stopniowo, krok po kroku dochodziły kolejne ify - jak taki użytkownik to zrób to, jak taki to zrób tamto, jak jest taki status to nie pozwól zmienić jakiejś daty, itd, itp.

To co Scott proponuje to zmienić nieco styl myślenia, od początku zacząć się zastanawiać czy aby na pewno warto wystawiać wszystko od razu? Scott proponuje by rozpoczynając cykl życia obiektu zwracać od razu wszystkie operacje, które na nim może dokonać ten konkretny użytkownik.

Przykładowo:

1. Tworząc post na blogu, dostaniemy listę operacji/możliwości: otwórz, zedytuj treść, zmień tytuł, opublikuj.
2. Inny użytkownik niż autor w tym momencie dla tego postu nie dostanie żadnych operacji -
3. Gdy autor opublikuje post to będzie mógł dalej go: otworzyć, zedytować treść i zmienić tytuł, ale już nie opublikować bo już został opublikowany
4. Pozostali użytkownicy dostaną po publikacji możliwość otwarcia tego postu, ale ciągle nie będą mogli zedytować treści i zmienić tytułu, bo nie są jego autorami.

Podeście ma też swoje odzwierciedlenie w design REST WebApi - jest zbieżne z enigmatycznym podejściem zwanym HATEOAS. Zachęcam do zerknięcia co to jest:

• Martin Fowler - Richardson Maturity Model,
• Yann L. - Implementing HATEOAS in your asp.netcore webapi,
• David Berry - Implementing HATEOAS Functionality in an ASP.NET Core Web API

Jestem bardzo ciekaw Twojej opinii co o tym sądzisz - daj znać! Jeśli temat jest ciekawy chętnie rozwinę go bardziej (również praktycznie) w kolejnym mailu.

A teraz już kończę, oddaję głos Scottowi i życzę udanego kolejnego tygodnia.

Pozdrawiam serdecznie!

Oskar