System is processing data
Please download to view
...

Systematyczny architekt na drodze ku planowanemu postarzaniu

by jaroslaw-palka

on

Report

Category:

Software

Download: 0

Comment: 0

819

views

Comments

Description

Download Systematyczny architekt na drodze ku planowanemu postarzaniu

Transcript

Systematyczny architekt na drodze ku planowanemu postarzaniu O mnie : Jarosław Pałka Who am I? Journeyman through space, time and technology devoted follower in church of JVM Archaeologist of legacy code chief architect @ Lumesse owner/founder @ symentis.pl blogger @ geekyprimitives.wordpress.com philosopher @ twitter:j_palka code mangler @ bitbucket:kcrimson & github:jpalka evil emperor @ 4developers architecture track „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 … najlepiej na wczoraj … … się poprawi jutro … (jutro nie nadejdzie nigdy) … to tylko prototyp … (żartowaliśmy) … nie mamy czasu … (to po co się zabieracie za ten projekt?) 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 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, 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 vois hireCandidate(){ String candidate = "Jan Kowalski"; employeeBean.createEmployee(candidate); candidate = "123456"; employeeBean.createEmployee(candidate); candidate = "{ candidate : {id : \"123456\"} }"; employeeBean.createEmployee(candidate); } public interface TalkingAboutAbstractions{ public Employee hireCandidate(Suppliercandidate); } public interface GuessWhatIHaveInMind{ String serverStatus() throws Exception; } „OK” „Mam się dobrze” „Cholera gdzie jest dysk?” „Daj mi spokó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 processList(String target, Long id); } public class BrainFuck extends 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 implementacji Stosuj obie techniki świadomie, Naucz się stosować je wymiennie Polimorfizm przychodzi W wielu smakach (dziedziczenie to tylko jeden z nich) „Ad hoc” „Parametric” „Coercion” „Inclusion (subtyping)” Buisness logic system construction code infrastructure public class SoftwareConstruction implements BeanFactoryAware, DisposableBean { @Override @SuppressWarnings("unchecked") public void setBeanFactory(final BeanFactory beanFactory) throws BeansException { consumerConfigurations = (Map) (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 AlbumPage(PageParameters parameters) { super(parameters); boolean showDescription = false; List 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 albumsListView = new AlbumsListView( ID_ALBUMS_VIEW, albums, showDescription); add(albumsListView); } public interface ShowMeMore{ @GET public Response getRoot( @Context HttpServletRequest request); } public class ShowMeMoreImpl implements ShowMeMore{ @Context private HttpServletRequest request; @GET public Response getRoot(); } Struktura systemu Gęstość informacji „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.” „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.” „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.” „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.” „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 „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” 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 because they reduce the amount of information that any 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 strings = new ArrayList(); public List getStrings(){ return strings; } AnotherStylishCase obj = new AnotherStylishCase(); obj.getStrings().add("Hello leaky abstraction!"); } 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” … 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 vs business logic
Fly UP