Systematyczny architekt naSystematyczny architekt na
drodze ku planowanemudrodze ku planowanemu
postarzaniupostarzaniu
O mnie :
Jarosław Pałka
Who am I?
Journeyman through
space,
time
and
technology
devoted follower in church of JVM
chief architect @ Lumesse
owner/founder @ symentis.pl
blogger @ geekyprimitives.wordpress.com
philosopher @ twitter:j_palk...
„Created weakness for the numbers on the 
board
Absurd amount of things, obsolete creation
The lust for always more, indul...
„strategia producenta, mająca na celu 
takie projektowanie towarów, aby miały 
one ograniczony czas użytecznego życia, po ...
Techniki „planowanego” postarzania
… najlepiej na wczoraj …
… się poprawi jutro …
(jutro nie nadejdzie nigdy)
… to tylko p...
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™
I znowy trzeba przepisać
Dobry inżynier,
Idź szukaj business
Podejście Big-Bang
Uczymy się na żywym organizmie
Ludzie z businessu trzymają się na dystans
Brak zrozumienia domeny probl...
„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 ...
Nie naprawimy przeszłości,
Ale możemy uczynić przyszłość lepszą
Mózg, co
bę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ć
Znaczenie ukryte za fasadą słów
„Czy mógłbyś otworzyć zamek?”
Brak jednoznaczności abstrakcji
Znaczenie = abstrakcja(kontekst)
Polimorfizm
public interface TalkingAboutAbstractions{
public void createEmployee(String candidate);
}
public voishireCandidate(){
String candidate= "Jan Kowalski";
employeeBean.createEmployee(candidate);
candidate=
"<candida...
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 spokój
„! # %^&*()”@ $
public interface GuessWhatIHaveInMind{
public enumServerStatus{ OK, BUSY, INTERNAL_ERROR }
ServerStatusserverStatus() thro...
A teraz czas na coś z klasyki
Prawdziwy,
Autentyczny,
jedyny
Brainfuck
public class BrainFuckextends GenericHibernateDAO{
List<Object[]> processList(String target, Long id);
}
public class BrainFuckextends GenericHibernateDAO{
ResultSet processList(String target, Long id);
}
Use types, Luke!
„Mieć” i „być”, to nie to samo
Diabeł tkwi w szczegółach
Generalizacja, uogólnienie
„is-a”
Kompozycja, delegacja
„has-a”
Uogólniaj na poziomie kontraktu
Interfejsu ze światem zewnętrznym
Kompozycja i delegacja
gdy przychodzi czas
na
Szczegóły ...
Polimorfizm przychodzi
W
wielu smakach
(dziedziczenie to tylko jeden z nich)
„Ad hoc”
„Parametric”
„Coercion”
Buisness logic
system construction
code infrastructure
public class SoftwareConstruction<K,V> implements BeanFactoryAware, DisposableBean {
@Override
@SuppressWarnings("unchecke...
Nie mieszajmy odpowiedzialności
Odpowiedzialność to nie tylko
„business features”
Obiekt nie może być odpowiedzialny za
sk...
public AlbumPage(PageParametersparameters) {
super(parameters);
boolean showDescription = false;
List<AlbumFullViewDTO> al...
public interface ShowMeMore{
@GET
public ResponsegetRoot(
@Context HttpServletRequest request);
}
public class ShowMeMoreImpl implements ShowMeMore{
@Context
private HttpServletRequest request;
@GET
public ResponsegetRoo...
Struktura systemu
Gęstość informacji
„Hierarchies are brilliant systems inventions, 
not only because they give a system
stability and resilience, but also bec...
„Hierarchies are brilliant systems inventions, 
not only because they give a system
stability and resilience, but also bec...
„In hierarchical systems relationships within 
each subsystem are denser and stronger
than relationships between subsystem...
„In hierarchical systems relationships within 
each subsystem are denser and stronger
than relationships between subsystem...
„Hierarchical systems are partially 
decomposable. Their subsystems with their
especially dense information links can 
fun...
„Hierarchical systems are partially 
decomposable. Their subsystems with their
especially dense information links can 
fun...
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 system
stability and resilience, but also bec...
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(){
retur...
Testability
the ultimate UI
If it's hard to test
it will be hard to maintain
and even harder to rewrite
„somebody on the i...
… 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ć
Abstrakcje
Polimorfizm
Context is King
Gęstość informacji
Enkapsulacja
Hierarchical Systems
Software construction
Systematyczny architekt na drodze ku planowanemu postarzaniu
Systematyczny architekt na drodze ku planowanemu postarzaniu
Systematyczny architekt na drodze ku planowanemu postarzaniu
Systematyczny architekt na drodze ku planowanemu postarzaniu
Systematyczny architekt na drodze ku planowanemu postarzaniu
Systematyczny architekt na drodze ku planowanemu postarzaniu
Systematyczny architekt na drodze ku planowanemu postarzaniu
Systematyczny architekt na drodze ku planowanemu postarzaniu
Prochain SlideShare
Chargement dans…5
×

Systematyczny architekt na drodze ku planowanemu postarzaniu

1 286 vues

Publié le

Systematyczny architekt na drodze ku planowanemu postarzaniu

Publié dans : Logiciels
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Systematyczny architekt na drodze ku planowanemu postarzaniu

  1. 1. Systematyczny architekt naSystematyczny architekt na drodze ku planowanemudrodze ku planowanemu postarzaniupostarzaniu
  2. 2. O mnie : Jarosław Pałka
  3. 3. Who am I? Journeyman through space, time and technology devoted follower in church of JVM
  4. 4. chief architect @ Lumesse owner/founder @ symentis.pl blogger @ geekyprimitives.wordpress.com philosopher @ twitter:j_palka code mangler @ bitbucket:kcrimson & github:jpalka
  5. 5. „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
  6. 6. „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
  7. 7. Techniki „planowanego” postarzania … najlepiej na wczoraj … … się poprawi jutro … (jutro nie nadejdzie nigdy) … to tylko prototyp … (żartowaliśmy) … nie mamy czasu …
  8. 8. Jakby tego było mało trendy
  9. 9. „We are fashion industry” Uncle Bob
  10. 10. Rewrite Offload Modernization Next Generation Something™
  11. 11. Kilka lat później
  12. 12. Rewrite Offload Modernization Next Generation Something™
  13. 13. I znowy trzeba przepisać
  14. 14. Dobry inżynier, Idź szukaj business
  15. 15. Podejście Big-Bang Uczymy się na żywym organizmie Ludzie z businessu trzymają się na dystans Brak zrozumienia domeny problemu
  16. 16. „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
  17. 17. Nie naprawimy przeszłości, Ale możemy uczynić przyszłość lepszą
  18. 18. Mózg, co będziemy dziś robić?
  19. 19. Dodamy kolejny framework!
  20. 20. Przygotujmy się na lepszą przyszłość Przygotujmy się na zmiany
  21. 21. Abstrakcje
  22. 22. Posługujemy się nimi na co dzień Są zapisane w naszej podświadomości Dlatego tak trudno o nich rozmawiać
  23. 23. Znaczenie ukryte za fasadą słów
  24. 24. „Czy mógłbyś otworzyć zamek?” Brak jednoznaczności abstrakcji
  25. 25. Znaczenie = abstrakcja(kontekst)
  26. 26. Polimorfizm
  27. 27. public interface TalkingAboutAbstractions{ public void createEmployee(String candidate); }
  28. 28. 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); }
  29. 29. public interface TalkingAboutAbstractions{ public Employee hireCandidate(Supplier<Candidate>candidate); }
  30. 30. public interface GuessWhatIHaveInMind{ String serverStatus() throws Exception; }
  31. 31. „ ”OK „ ”Mam się dobrze „ ”Cholera gdzie jest dysk? „ ”Daj mi spokój „! # %^&*()”@ $
  32. 32. public interface GuessWhatIHaveInMind{ public enumServerStatus{ OK, BUSY, INTERNAL_ERROR } ServerStatusserverStatus() throws Exception; }
  33. 33. A teraz czas na coś z klasyki Prawdziwy, Autentyczny, jedyny
  34. 34. Brainfuck
  35. 35. public class BrainFuckextends GenericHibernateDAO{ List<Object[]> processList(String target, Long id); }
  36. 36. public class BrainFuckextends GenericHibernateDAO{ ResultSet processList(String target, Long id); }
  37. 37. Use types, Luke!
  38. 38. „Mieć” i „być”, to nie to samo Diabeł tkwi w szczegółach Generalizacja, uogólnienie „is-a” Kompozycja, delegacja „has-a”
  39. 39. Uogólniaj na poziomie kontraktu Interfejsu ze światem zewnętrznym Kompozycja i delegacja gdy przychodzi czas na Szczegóły implementacji Stosuj obie techniki świadomie,
  40. 40. Polimorfizm przychodzi W wielu smakach (dziedziczenie to tylko jeden z nich) „Ad hoc” „Parametric” „Coercion”
  41. 41. Buisness logic system construction code infrastructure
  42. 42. 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); } }
  43. 43. Nie mieszajmy odpowiedzialności Odpowiedzialność to nie tylko „business features” Obiekt nie może być odpowiedzialny za skonstruowanie samego siebie
  44. 44. 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); }
  45. 45. public interface ShowMeMore{ @GET public ResponsegetRoot( @Context HttpServletRequest request); }
  46. 46. public class ShowMeMoreImpl implements ShowMeMore{ @Context private HttpServletRequest request; @GET public ResponsegetRoot(); }
  47. 47. Struktura systemu
  48. 48. Gęstość informacji
  49. 49. „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.”
  50. 50. „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.”
  51. 51. „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.”
  52. 52. „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.”
  53. 53. „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
  54. 54. „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”
  55. 55. Value is Your Subsystem Boundary
  56. 56. Kandydat
  57. 57. Aplikant Kandydat
  58. 58. Aplikant Kandydat Bezrobotny
  59. 59. Aplikant Kandydat Bezrobotny
  60. 60. Value is usually Your subsystem boundary
  61. 61. „Encapsulation is the packing  of data and functions into a  single component.”
  62. 62. „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.”
  63. 63. public class WrongEncapsulation{ public String name; }
  64. 64. public class IsItEncapsulation{ private String name; }
  65. 65. public class JavaStyleEncapsulation{ private String name; public String getName(){ ... }; public void setName(String name){ … }; }
  66. 66. Software design porn
  67. 67. public class AnotherStylishClass{ private List<String> strings= new ArrayList<>(); public List<String> getStrings(){ returnstrings; } AnotherStylishCaseobj = new AnotherStylishCase(); obj.getStrings().add("Hello leaky abstraction!"); }
  68. 68. 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”
  69. 69. … Jakie są granice szaleństwa ...
  70. 70. Kiedy znowu zobaczysz Java Bean, usuń go, poważnie, natychmiast, .git rm AnotherStupidJavaBean java
  71. 71. Jedyne rzeczy które warto zapamiętać
  72. 72. Abstrakcje Polimorfizm Context is King Gęstość informacji Enkapsulacja Hierarchical Systems Software construction

×