Systematyczny architekt na Systematyczny architekt na drodze ku planowanemu drodze ku planowanemu postarzaniupostarzaniu

O mnie : Jarosław Pałka

• 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

„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

„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

Techniki „planowanego” postarzania

… nowy lepszy paradygmat …… nowa wersja biblioteki …

… nowy język programowania …… nowe lepsze API ...

… brak kompatybilności wstecznej …

Jakby tego było mało

trendy

„We are fashion industry”Uncle Bob

Rewrite

Offload

Modernization

Next Generation Something™

Kilka lat później

Rewrite

Offload

Modernization

Next Generation Something™

Organizacje dostają wysypki na samą myśl o kolejnym

offload, rewrite, NG projekcie

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

Podejście Big-Bang

Uczymy się na żywym organizmie

Ludzie z businessu trzymają się na dystans

Brak zrozumienia domeny problemu

„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

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

Mózg, cobędziemy dziś robić?

Dodamy kolejny framework!

Przygotujmy się na lepszą przyszłość

Przygotujmy się na zmiany

Abstrakcje

Posługujemy się nimi na co dzień

Są zapisane w naszej podświadomości

Dlatego tak trudno o nich rozmawiać

Polimorfizm

Znaczenie ukryte za fasadą słów

„Czy mógłbyś otworzyć zamek?”

Brak jednoznaczności abstrakcji

Znaczenie = abstrakcja(kontekst)

public interface TalkingAboutAbstractions{

public void createEmployee(String candidate);

}

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);

}

public interface TalkingAboutAbstractions{

public Employee hireCandidate(Supplier<Candidate >candidate);

}

public interface GuessWhatIHaveInMind{

String serverStatus() throws Exception;

}

„OK”

„Mam si dobrzeę ”

„Cholera gdzie jest dysk?”

„Daj mi spokoój”

„!@#$%^&*()”

public interface GuessWhatIHaveInMind{

public enum ServerStatus { OK, BUSY, INTERNAL_ERROR }

ServerStatus serverStatus() throws Exception;

}

A teraz czas na coś z klasyki

Prawdziwy, Autentyczny,

jedyny

Brainfuck

public class BrainFuck extends GenericHibernateDAO{

List<Object[]> processList(String target, Long id);

}

public class BrainFuck extends GenericHibernateDAO{

ResultSet processList(String target, Long id);

}

Use types, Luke!

Buisness logic &

system construction&

code infrastructure

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

}

Nie mieszajmy odpowiedzialności

Odpowiedzialność to nie tylko „business features”

Obiekt nie może być odpowiedzialny za skonstruowanie samego siebie

public interface ShowMeMore{

@GETpublic Response getRoot(

@Context HttpServletRequest request);

}

public class ShowMeMoreImpl implements ShowMeMore{

@Contextprivate HttpServletRequest request;

@GETpublic Response getRoot();

}

Struktura systemu

Gęstość informacji

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

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

„In hierarchical systems relationships within each subsystem are denser and strongerthan relationships between subsystems. Everything is still connected to everythingelse, but not equally strongly.”

„In hierarchical systems relationships within each subsystem are denser and strongerthan relationships between subsystems. Everything is still connected to everythingelse, but not equally strongly.”

„Hierarchical systems are partially decomposable. Their subsystems with theirespecially dense information links can function at least partially as systems in theirown right. When hierarchies break down, they usually split along their subsystemboundaries”

Donella Meadows

„Hierarchical systems are partially decomposable. Their subsystems with theirespecially dense information links can function at least partially as systems in theirown right. When hierarchies break down, they usually split along their subsystemboundaries”

Value is Your Subsystem Boundary

Kandydat

Aplikant

Kandydat

Aplikant

Kandydat

Bezrobotny

Aplikant

Kandydat

Bezrobotny

Value is usually

Your subsystem boundary

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

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

public class WrongEncapsulation{public String name;

}

public class IsItEncapsulation{private String name;

}

public class JavaStyleEncapsulation{

private String name;

public String getName(){ ... };

public void setName(String name){ …

};

}

Software design porn

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!");

}

… Jakie są granice szaleństwa ...

… Jakie są granice szaleństwa ...

Kiedy znowu zobaczysz Java Bean,usuń go,

poważnie,natychmiast,

git rm AnotherStupidJavaBean.java

Jedyne rzeczy które warto zapamiętać

AbstrakcjePolimorfizm

Context is King

Gęstość informacjiEnkapsulacja

Hierarchical Systems

Software construction vs

business logic