1.
Systematyczny aarrcchhiitteekktt nnaa
ddrrooddzzee kkuu ppllaannoowwaanneemmuu
ppoossttaarrzzaanniiuu

2.
O mnie :
Jarosław Pałka

3.
• chief architect @ Lumesse
• owner/founder/one man orchestra @
symentis.pl
• blogger @ geekyprimitives.wordpress.com
• philosopher @ twitter:j_palka
• code mangler @ bitbucket:kcrimson &
github:jpalka
• evil emperor @ 4developers conf/architecture
track
• restrained Padawan @ church of JVM

4.
„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

5.
„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

6.
Techniki „planowanego” postarzania
… nowy lepszy paradygmat …
… nowa wersja biblioteki …
… nowy język programowania …
… nowe lepsze API ...
… brak kompatybilności wstecznej …

7.
Jakby tego było mało
trendy

8.
„We are fashion industry”
Uncle Bob

9.
Rewrite
Offload
Modernization
Next Generation Something™

10.
Kilka lat później

11.
Rewrite
Offload
Modernization
Next Generation Something™

12.
Organizacje dostają wysypki na
samą myśl
o kolejnym
offload, rewrite, NG projekcie

13.
Dobry inżynier,
Idź szukaj business value,
szukaj

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

15.
„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

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

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

18.
Dodamy kolejny framework!

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

20.
Abstrakcje

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

22.
Polimorfizm

23.
Znaczenie ukryte za fasadą słów

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

25.
Znaczenie = abstrakcja(kontekst)

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

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

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

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

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

31.
public interface GuessWhatIHaveInMind{
public enum ServerStatus { OK, BUSY, INTERNAL_ERROR }
ServerStatus serverStatus() throws Exception;
}

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

33.
Brainfuck

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

35.
public class BrainFuck extends GenericHibernateDAO{
ResultSet processList(String target, Long id);
}

36.
Use types, Luke!

37.
Buisness logic
&
system construction
&
code infrastructure

38.
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);
}
}

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

40.
public interface ShowMeMore{
@GET
public Response getRoot(
@Context HttpServletRequest request);
}

41.
public class ShowMeMoreImpl implements
ShowMeMore{
@Context
private HttpServletRequest request;
@GET
public Response getRoot();
}

42.
Struktura systemu

43.
Gęstość informacji

44.
„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.”

45.
„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.”

46.
„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.”

47.
„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.”

48.
„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

49.
„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”

50.
Value is Your Subsystem Boundary

51.
Kandydat

52.
Aplikant
Kandydat

53.
Bezrobotny
Aplikant
Kandydat

54.
Bezrobotny
Aplikant
Kandydat

55.
Value is
usually
Your subsystem boundary

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

57.
„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.”

58.
public class WrongEncapsulation{
public String name;
}

59.
public class IsItEncapsulation{
private String name;
}

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

61.
Software design porn

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

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

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

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

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

67.
Abstrakcje
Polimorfizm
Context is King
Gęstość informacji
Enkapsulacja
Hierarchical Systems
Software construction
vs
business logic