high level principles, micro-patterns and anti-patterns

© 2014 VMware Inc. All rights reserved

High-level principles, Micro-patterns and anti-patterns

Dimitar Dimitrov Software engineer

Лекцията накратко

2


! High-level principles • Добри практики на по-високо ниво (от обичайните design patterns)

2



! Micro-patterns and code idioms • Добри практики на гранулярно ниво

2




! Anti-patterns • Често срещани лоши практики или конструкции, за които съществува алтернативен подход

2





! Examples of design patterns • Примери от Java 7 SE API !

2





! Examples of design patterns • Примери от Java 7 SE API !

! Disclaimer: Безогледна смес на български и английски ahead. Приемете на доверие, че това спомага за краткостта и яснотата на изложението. Авторът приема критики за грамотността си и преводаческите си способности.

2

High-level principles

3


! Като цяло не са обвързани с конкретен език или платформа.

3



! Могат да бъдат както implementation-centric, така и practice-centric.

3




! Design pattern-ите, които имат сходна структура и/или употреба, обикновено изхождат от един и същ implementation-centric принцип.

3





! Добрите практики, свързани с процеса на проектиране, изграждане и поддържане на софтуер, обикновено изхождат от practice-centric принципи. • The Pragmatic Programmer, ISBN 978-0-2016-1622-4

3





! Добрите практики, свързани с процеса на проектиране, изграждане и поддържане на софтуер, обикновено изхождат от practice-centric принципи. • The Pragmatic Programmer, ISBN 978-0-2016-1622-4

! Disclaimer: Термините implementation-centric и practice-centric са измислени от автора и имат определени недостатъци.

3

Implementation-centric principles

4


! Четирите основни принципа на ООП • Abstraction

• Encapsulation

• Inheritance

• Polymorphism

4



• Encapsulation

• Inheritance

• Polymorphism

! Separation of concerns • Свързан с encapsulation, loose coupling и strong cohesion

4



• Encapsulation

• Inheritance

• Polymorphism


! Single responsibility principle

4



• Encapsulation

• Inheritance

• Polymorphism


! Single responsibility principle! DRY principle

• Свързан със single responsibility principle и maintainability

4



• Encapsulation

• Inheritance

• Polymorphism


! Single responsibility principle! DRY principle

• Свързан със single responsibility principle и maintainability

! Design by contract • Pre-conditions, post-conditions, invariants

• Особено важен при проектирането и създаването на API

4

Implementation-centric principles (2)

5


! Open-closed principle • Компонентите трябва да са отворени за разширяване

• Но затворени за модификация

5




! Liskov substitution principle • Обект от даден тип трябва да може да се използва прозрачно навсякъде, където се очаква обект от базов на дадения тип (µs и ns)

5





! Law of Demeter • “Не говори със съседа на съседа си”

• Ограничава методи на кои обекти могат да бъдат изпълнявани директно

5





! Law of Demeter • “Не говори със съседа на съседа си”

• Ограничава методи на кои обекти могат да бъдат изпълнявани директно

! Inversion of control + Dependency injection • Абстракцията не трябва да зависи от детайлите, детайлите трябва да зависят от абстракцията

• Предпочитане на интерфейси пред абстрактни класове

5


6


! Interface segregation principle • Абстракции и зависимости трябва да бъдат ограничавани до възможно най-малък интерфейс • Ползвайте маркер интерфейси и интерфейси с един метод

6



! Acyclic dependency principle • Структурата на зависимостите между компонентите не трябва да съдържа циклични зависимости

6




! Principle of least astonishment • Операциите трябва да имат ясен и консистентен резултат, разбираем от името, документацията и очакваното приложение на метода или класа • Много важен, когато имплементирате API

6




! Principle of least astonishment • Операциите трябва да имат ясен и консистентен резултат, разбираем от името, документацията и очакваното приложение на метода или класа • Много важен, когато имплементирате API

! Principle of least resource usage • Използвайте минимално количество ресурси

• Оптимизирайте само на базата на резултати от тестове, за да избегнете premature optimization

6

Practice-centric principles

7


! Яснота и простота преди всичко • Модулите, класовете, методите и др. трябва да бъдат възможно най-малки, но не по-малки (Еinstein reference)

• Пазете се от семантично замърсяване или “излишен шум” в методите и класовете си (припомнете си какво са cross-cutting concerns)

7




! Принцип на Парето • 80% от ефектите се причиняват от 20% от факторите

• Научете се да идентифицирате важните 20%

7






! Спазвайте създадените правила и конвенции • Консистентността води до четимост и разбираемост

• Не нарушавайте конвенциите си заради малки оптимизации (защо?)

7






! Спазвайте създадените правила и конвенции • Консистентността води до четимост и разбираемост

• Не нарушавайте конвенциите си заради малки оптимизации (защо?)

! Възползвайте се максимално от наличните инструменти • Отделете време, за да оптимизирате максимално тези 20% от дейностите си, които изпълнявате през 80% от времетo си

7

Practice-centric principles (2)

8


! Хващайте грешки, колкото се може по-рано • Свързано не само с имплементацията, но и с целия процес на разработка

(Quality Engineering) • Важно изискване: Признавайте грешките си

8




! Винаги планирайте и изпълнявайте, имайки предвид контекста на вашия проект • Пример: И производителността, и user experience-а са важни, но ако се наложи, с кое от двете бихте направили компромис?

8





! Познавайте спецификите на проблемната област • Познавайте лошите практики и техническите предизвикателства

• Идентифицирайте коя платформа ви върши най-добра работа, използвайте идиомите на езика и проблемната област

8





! Познавайте спецификите на проблемната област • Познавайте лошите практики и техническите предизвикателства

• Идентифицирайте коя платформа ви върши най-добра работа, използвайте идиомите на езика и проблемната област

! Нито един принцип не е абсолютен • Не следвайте сляпо принципи, които не ви носят добавена стойност

8

Micro-patterns and code idioms

9


! Като цяло обхващат добри практики със scope не повече от тялото на един метод. • Понякога разграничаването между pattern и micro-pattern е нетривиално

(Lazy loading)

9



(Lazy loading)

! Често са обвързани с платформата или езика, за които се прилагат. • Под code idiom често се разбира специфична за езика конструкция

(idiomatic code)

9



(Lazy loading)

! Често са обвързани с платформата или езика, за които се прилагат. • Под code idiom често се разбира специфична за езика конструкция

(idiomatic code)

! За разлика от design principles, code idioms по-често биват неправилно използвани. • Най-често всичко започва с доброто намерение на програмиста

• Понякога обаче това нарушава “Яснота и простота преди всичко”, “Спазвайте създадените правила и конвенции” или “Не следвайте сляпо принципи, които не ви носят добавена стойност”

9

Примери - micro-patterns

10


! Създаване и използване на immutable обекти • Изключително полезно при multithreaded приложения, и не само там

• Какво недостатъци може да има?

10

http://goo.gl/5L4fi




! Ограничаване на scope-a на локалните променливи • Ограничава възможността да злоупотребим, подпомага garbage collect-ването

• А ако пишем на JavaScript (как се определя scope-a там)?

10

http://goo.gl/5L4fi






! Lazy loading • Може да подобри бързината и заеманата памет на приложението

• Рядко подобрението на бързината е фактор (виж http://goo.gl/5L4fi)

10

http://goo.gl/5L4fi








! Defensive copying • Може негативно да повлияе на бързината и заеманата памет, ако не се изисква

• Все пак по-добре да загубите производителност, отколкото да нарушите encapsulation-а

10

http://goo.gl/5L4fi








! Defensive copying • Може негативно да повлияе на бързината и заеманата памет, ако не се изисква

• Все пак по-добре да загубите производителност, отколкото да нарушите encapsulation-а

! Добавяне на static final модификатори • Ползвайте го заради семантичния ефект, а не като performance optimization

• По подразбиране методите са виртуални в Java и невиртуални в C#

10

http://goo.gl/5L4fi

Примери - micro-patterns (2)

11


! Short-circuit булеви оператори • mostLikelyFalse() && mostLikelyTrue()• alwaysTrue() || alwaysThrowsException()

11



! Избягване на null референции • CONST.equals(nullRef) и return itemArray != null ? itemArray : [];

• Може да бъде ненужно или нежелано • ако прикрива по-късен NullPointerException по време на изпълнение

• ако между null и [] има семантична разлика

11



! Избягване на null референции • CONST.equals(nullRef) и return itemArray != null ? itemArray : [];

• Може да бъде ненужно или нежелано • ако прикрива по-късен NullPointerException по време на изпълнение

• ако между null и [] има семантична разлика

! Достъпване и промяна на полета през методи • Почти винаги трябва да се използва

• Какво става, ако за класа Person, трябва да връщате не this.age, a this.age - 10, ако FEMALE.equals(this.sex)?

• Изключение правят чистите data обекти с ограничена (непублична) видимост

11

Anti-patterns

12

Anti-patterns

! Често срещани шаблони с идентифицирани недостатъци, за които съществува алтернативен подход.

12

Anti-patterns


! Могат да бъдат:

12

Anti-patterns


! Могат да бъдат:• Контрапродуктивни навици

12

Anti-patterns



• Лоши конструкции, създадени с добри намерения

12

Anti-patterns




• Лоши конструкции, появяващи се с течение на разработката

12

Anti-patterns





! Code smells

12

Anti-patterns





! Code smells• индикация или симптом за съществуването на по-сериозен проблем

12

Anti-patterns






• code duplication

12

Anti-patterns







• прекалено дълги методи

12

Anti-patterns








• и разбира се, прекалено дълги класове

12

Anti-patterns









• код с няколко нива на conditional nesting

12

Anti-patterns









• код с няколко нива на conditional nesting

• методи с прекалено много аргументи

12

Design Patterns и Java 7 SE API

13


! Singleton • System.console(), Runtime.getRuntime(), Collections.EMPTY_MAP

13



! Factory method/Factory • Boolean.valueOf(String s), Class.newInstance() (макар че Class вече е параметризиран тип, типът на създадената инстанция е конкретен)

13




! Abstract Factory • URL.openConnection(), Arrays.asList(T... a) (винаги връща инстанция на

ArrayList), Collections.unmodifiableList(List<? extends T> c) (винаги връща инстанция на inner class, невидим извън самия JDK)

13






! Prototype • Object.clone() (клонирането на обекти в Java е доста “дълбока” тема; виж

Effective Java, 2nd Edition, Item 11)

13






! Prototype • Object.clone() (клонирането на обекти в Java е доста “дълбока” тема; виж

Effective Java, 2nd Edition, Item 11)

! Flyweight • Boolean.valueOf(String s), Collections.emptyMap()

13

Design Patterns и Java 7 SE API (2)

14


! Adapter • InputStreamReader(InputStream)

14



! Composite • java.awt.Container.add(Component comp) (връща инстанция на Component)

• Collection.addAll(Collection<? extends e> c) is not Composite (добавяната колекция не бива запазена)

14





! Decorator • Collections.unmodifiableList(List<? extends T> c) (тъй като поведението се променя)

14





! Decorator • Collections.unmodifiableList(List<? extends T> c) (тъй като поведението се променя)

! Proxy • subtypes of java.lang.reflect.Proxy

• създавани чрез статичния factory method newProxyInstance(ClassLoader loader, Class<?>[] interfaces, InvocationHandler h)

14

Ресурси

15

Ресурси

!• http://c2.com/cgi/wiki?OoDesignPrinciples • http://www.slideshare.net/clintedmonson/advanced-

oop-laws-principles-idioms-presentation • http://www.oodesign.com/design-principles.html • http://sourcemaking.com/antipatterns • http://stackoverflow.com/questions/1673841/examples-

of-gof-design-patterns/ • http://msdn.microsoft.com/en-us/magazine/

cc188707.aspx (старо, но все още валидно) • Effective Java, 2nd Edition, ISBN 978-0-3213-5668-0 • The Pragmatic Programmer, ISBN 978-0-2016-1622-4

15

http://c2.com/cgi/wiki?OoDesignPrinciples

http://www.slideshare.net/clintedmonson/advanced-oop-laws-principles-idioms-presentation

http://www.oodesign.com/design-principles.html

http://sourcemaking.com/antipatterns

http://stackoverflow.com/questions/1673841/examples-of-gof-design-patterns/

http://msdn.microsoft.com/en-us/magazine/cc188707.aspx

high level principles, micro-patterns and anti-patterns

Education

practicecentric principles

design principles

code idioms

openclosed principle

acyclic dependency principle

liskov substitution

code idiom idiomatic

javascript scope