1. Systematyczny architekt naSystematyczny architekt na
drodze ku planowanemudrodze ku planowanemu
postarzaniupostarzaniu

2. O mnie :
Jarosław Pałka

3. Who am I?
Journeyman through
space,
time
and
technology
devoted follower in church of JVM

4. chief architect @ Lumesse
owner/founder @ symentis.pl
blogger @ geekyprimitives.wordpress.com
philosopher @ twitter:j_palka
code mangler @ bitbucket:kcrimson &
github:jpalka

6. „Created weakness for the numbers on the
board
Absurd amount of things, obsolete creation
The lust for always more, indulgence in
hunger
A greed for power, the demon needs to feed
…
Designed for failure”
Gojira – Planned Obsolescence

7. „strategia producenta, mająca na celu
takie projektowanie towarów, aby miały
one ograniczony czas użytecznego życia, po
tym zaś okresie stawały się niesprawne, a
często nieopłacalne w naprawie. Towary te
zwykle psują się zaraz po upływie
gwarancji.”
Wikipedia

9. Techniki „planowanego” postarzania
… najlepiej na wczoraj …
… się poprawi jutro …
(jutro nie nadejdzie nigdy)
… to tylko prototyp …
(żartowaliśmy)
… nie mamy czasu …

10. Jakby tego było mało
trendy

11. „We are fashion industry”
Uncle Bob

12. Rewrite
Offload
Modernization
Next Generation Something™

13. Kilka lat później

14. Rewrite
Offload
Modernization
Next Generation Something™

15. I znowy trzeba przepisać

16. Dobry inżynier,
Idź szukaj business

17. Podejście Big-Bang
Uczymy się na żywym organizmie
Ludzie z businessu trzymają się na dystans
Brak zrozumienia domeny problemu

19. „It is up to us to live up to the legacy that was
left for us, and to leave a legacy that is worthy
of our children and of future generations.”
Christine Gregoire

20. Nie naprawimy przeszłości,
Ale możemy uczynić przyszłość lepszą

21. Mózg, co
będziemy
dziś robić?

22. Dodamy kolejny framework!

23. Przygotujmy się na lepszą przyszłość
Przygotujmy się na zmiany

24. Abstrakcje

25. Posługujemy się nimi na co dzień
Są zapisane w naszej podświadomości
Dlatego tak trudno o nich rozmawiać

26. Znaczenie ukryte za fasadą słów

30. „Czy mógłbyś otworzyć zamek?”
Brak jednoznaczności abstrakcji

31. Znaczenie = abstrakcja(kontekst)

32. Polimorfizm

33. public interface TalkingAboutAbstractions{
public void createEmployee(String candidate);
}

34. public voishireCandidate(){
String candidate= "Jan Kowalski";
employeeBean.createEmployee(candidate);
candidate=
"<candidate><id>123456</id></candidate>";
employeeBean.createEmployee(candidate);
candidate= "{ candidate: {id : "123456"} }";
employeeBean.createEmployee(candidate);
}

35. public interface TalkingAboutAbstractions{
public Employee
hireCandidate(Supplier<Candidate>candidate);
}

36. public interface GuessWhatIHaveInMind{
String serverStatus() throws Exception;
}

37. „ ”OK
„ ”Mam się dobrze
„ ”Cholera gdzie jest dysk?
„ ”Daj mi spokój
„! # %^&*()”@ $

38. public interface GuessWhatIHaveInMind{
public enumServerStatus{ OK, BUSY, INTERNAL_ERROR }
ServerStatusserverStatus() throws Exception;
}

39. A teraz czas na coś z klasyki
Prawdziwy,
Autentyczny,
jedyny

40. Brainfuck

41. public class BrainFuckextends GenericHibernateDAO{
List<Object[]> processList(String target, Long id);
}

42. public class BrainFuckextends GenericHibernateDAO{
ResultSet processList(String target, Long id);
}

43. Use types, Luke!

44. „Mieć” i „być”, to nie to samo
Diabeł tkwi w szczegółach
Generalizacja, uogólnienie
„is-a”
Kompozycja, delegacja
„has-a”

45. Uogólniaj na poziomie kontraktu
Interfejsu ze światem zewnętrznym
Kompozycja i delegacja
gdy przychodzi czas
na
Szczegóły implementacji
Stosuj obie techniki świadomie,

46. Polimorfizm przychodzi
W
wielu smakach
(dziedziczenie to tylko jeden z nich)
„Ad hoc”
„Parametric”
„Coercion”

47. Buisness logic
system construction
code infrastructure

48. public class SoftwareConstruction<K,V> implements BeanFactoryAware, DisposableBean {
@Override
@SuppressWarnings("unchecked")
public void setBeanFactory(final BeanFactory beanFactory) throws BeansException
{
consumerConfigurations= (Map<String, ConsumerConfiguration<K,V>>)
(Object) ((ListableBeanFactory)
beanFactory).getBeansOfType(ConsumerConfiguration.class);
}
}

49. Nie mieszajmy odpowiedzialności
Odpowiedzialność to nie tylko
„business features”
Obiekt nie może być odpowiedzialny za
skonstruowanie samego siebie

50. public AlbumPage(PageParametersparameters) {
super(parameters);
boolean showDescription = false;
List<AlbumFullViewDTO> albums;
String searchQuery = parameters.get("search").toString(null);
if (searchQuery == null) {
searchQuery = parameters.get(0).toString(null);
if (searchQuery != null) {
showDescription = true;
}
}
albums= productCatalog.searchAlbums(searchQuery);
ListView<AlbumFullViewDTO> albumsListView = new AlbumsListView(
ID_ALBUMS_VIEW, albums, showDescription);
add(albumsListView);
}

51. public interface ShowMeMore{
@GET
public ResponsegetRoot(
@Context HttpServletRequest request);
}

52. public class ShowMeMoreImpl implements ShowMeMore{
@Context
private HttpServletRequest request;
@GET
public ResponsegetRoot();
}

53. Struktura systemu

54. Gęstość informacji

55. „Hierarchies are brilliant systems inventions,
not only because they give a system
stability and resilience, but also because they
reduce the amount of information that
any part of the system has to keep track of.”

56. „Hierarchies are brilliant systems inventions,
not only because they give a system
stability and resilience, but also because they
reduce the amount of information that
any part of the system has to keep track of.”

57. „In hierarchical systems relationships within
each subsystem are denser and stronger
than relationships between subsystems.
Everything is still connected to everything
else, but not equally strongly.”

58. „In hierarchical systems relationships within
each subsystem are denser and stronger
than relationships between subsystems.
Everything is still connected to everything
else, but not equally strongly.”

59. „Hierarchical systems are partially
decomposable. Their subsystems with their
especially dense information links can
function at least partially as systems in their
own right. When hierarchies break down, they
usually split along their subsystem
boundaries”
Donella Meadows

60. „Hierarchical systems are partially
decomposable. Their subsystems with their
especially dense information links can
function at least partially as systems in their
own right. When hierarchies break down, they
usually split along their subsystem
boundaries”

62. Value is Your Subsystem Boundary

63. Kandydat

64. Aplikant
Kandydat

65. Aplikant
Kandydat
Bezrobotny

66. Aplikant
Kandydat
Bezrobotny

67. Value is
usually
Your subsystem boundary

68. „Encapsulation is the packing
of data and functions into a
single component.”

69. „Hierarchies are brilliant systems inventions,
not only because they give a system
stability and resilience, but also because they
reduce the amount of information that
any part of the system has to keep track of.”

70. public class WrongEncapsulation{
public String name;
}

71. public class IsItEncapsulation{
private String name;
}

72. public class JavaStyleEncapsulation{
private String name;
public String getName(){ ... };
public void setName(String name){
…
};
}

73. Software design porn

74. public class AnotherStylishClass{
private List<String> strings= new ArrayList<>();
public List<String> getStrings(){
returnstrings;
}
AnotherStylishCaseobj = new AnotherStylishCase();
obj.getStrings().add("Hello leaky abstraction!");
}

75. Testability
the ultimate UI
If it's hard to test
it will be hard to maintain
and even harder to rewrite
„somebody on the internet”

76. … Jakie są granice szaleństwa ...

77. Kiedy znowu zobaczysz Java Bean,
usuń go,
poważnie,
natychmiast,
.git rm AnotherStupidJavaBean java

78. Jedyne rzeczy które warto zapamiętać

79. Abstrakcje
Polimorfizm
Context is King
Gęstość informacji
Enkapsulacja
Hierarchical Systems
Software construction