• Like
DCI
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Published

 

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
896
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
15
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Мы говорили с вами об отображении понятий из головы пользователя в программный код.Как выяснилось, это не простая задача. Не такая простая как может показаться на первый взгляд. Проблема заключается в том, что программист и пользователь мыслят по-разному. Конечный пользователь не мыслит такими понятиями как классы, аттрибуты, методы. В его голове есть сущности, есть взаимодействия этих сущностей, есть конкретные сценарии, в которых сущности взаимодействуют. А сущности эти в его модели мышления обычно гораздо проще, чем их репрезентации в коде.
  • Итак, первая часть – это данные.Они представляют собой статическую часть кода – состояние системы. Можно сказать, что это такая «микро база данных», которая включает в себя доменные классы вашей системы.DCI говорит, что доменные объекты должны быть «тупыми». Мы отделяем состояние системы от поведения, поэтому доменные объекты не содержат кода взаимодействия. Они содержат только основную информацию, общую для всех контекстов, в которых они будут участвовать, а не полный набор всех процессов и алгоритмов.Данные – это элементы модели мышления пользователя. Если вернуться к нашему примеру со счетами, то в системе у нас будет тупой объект счёт, который будет хранить информацию о количестве денег.
  • Как вы понимаете, любая системная операция, или любой юз-кейс будет в рантайме представлен сетью взаимодействующих объектов. Именно контекст определяет топологию этой сети. Он в рантайме будет выбирать объекты, необходимые для конкретного сценария и назначать им роли. Он будет встраивать в них методы, присущие ролям, и запускать взаимодействия между ними.Контекст, в нашем примере, это банковский перевод. Именно контекст выберет, какой счёт будет Отправителем, а какой – Получателем. Контекст присвоит этим счетам соответствующие роли. Контекст встроит в выбранные объекты необходимые методы для взаимодействия, и наконец, контекст запустит эти взаимодействия между объектами.

Transcript

  • 1. DCI – хорошо забытыйстарый взгляд на объектыAnton ChernetskiyLev SivashovMay 1, 2012 www.ExigenServices.com
  • 2. About usLev Sivashov Anton Chernetskiy Developers in Exigen Services
  • 3. What the heck is OOP? Mixins Interfaces Classes TraitsPrototypes OOP Roles Aspects Objects
  • 4. Essence of OOPNetworks of communicating objects work together to achieve a common goal
  • 5. Class orientationStatic class definitions are not capable of fullydescribing dynamic nature of interacting objects
  • 6. Fragmentation instead of decomposition
  • 7. How tounderstand?
  • 8. Extension of yourmental model
  • 9. So?
  • 10. So?• OOP is not a smart programming tool but a way of thinking
  • 11. So?• OOP is not a smart programming tool but a new way of thinking• Objects are not data structures with methods but elements of human mental model
  • 12. So what?
  • 13. Business rules Software
  • 14. User Programmer Classes, attributes, metObject interactions hods
  • 15. Representing the users mental model
  • 16. Representing the users mental model One-to-one
  • 17. MaintainabilityStable /
  • 18. Introducing DCI
  • 19. Network of communicating objects
  • 20. Use case 1 Use case 2
  • 21. Roles and contextsAt work At home At corporate
  • 22. Data ContextInteractions
  • 23. Data – what-the-system-ispublic class Foo{ public String bar; public double baz;} Very dump objects
  • 24. Context – a use case
  • 25. Interactionswhat-the-system-does
  • 26. Object =Data + Roles
  • 27. State Behavior
  • 28. State BehaviorData Context and Interactions
  • 29. State Behavior Data Context and Interactions User’s Use casesmental model
  • 30. State Behavior Data Context and Interactions User’s Use casesmental model Stable Changing
  • 31. In code
  • 32. Implementations• Scala (traits)• Ruby, Python (runtime methods injection)• C++ (templates)• C# (extension methods)• Perl• PHP• Java (Qi4j)
  • 33. Use cases:
  • 34. Use cases:
  • 35. Use cases:
  • 36. Use cases:
  • 37. Datapublic interface Unit { Property<Integer> health(); Property<String> name();}
  • 38. Role (attackable)public interface Attackable { void receiveDamage(double damageAmount);}
  • 39. Role implementation (attackable)class AttackableImpl implements Attackable { @This Unit unit; public void receiveDamage(double damageAmount) { Double health = unit.health().get(); unit.health().set(health - damageAmount); }}
  • 40. Bind implementation to role@Mixins({AttackableImpl.class})public interface Attackable { void receiveDamage(double damageAmount);}
  • 41. Role (attacker)public interface Attacker { void beat(Attackable attackable);}
  • 42. Role implementation (attacker)class AttackerImpl implements Attacker { private final static Integer STRENGTH = 10; public void beat(Attackable attackable) { attackable.receiveDamage(STRENGTH); }}
  • 43. Contextpublic class AttackEnemiesContext { ... Attacker attacker; List<? extends Attackable> enemies; public void fight() { for (Attackable enemy : enemies) { attacker.beat(enemy); } }}
  • 44. Constructing an objectpublic interface Worker extends EntityComposite, Attackable, Healable, Builder {}
  • 45. Initializing unitEntityBuilder<Worker> builder = unitOfWork.newEntityBuilder(Worker.class, name);Unit unit = builder.instanceFor(Unit.class);unit.health().set(100.0);unit.name().set(name);worker = builder.newInstance();
  • 46. Interaction// Team oneprivate Warrior warrior;// Team twoprivate Worker worker;private Medic medic;private Barn barn;
  • 47. barn = worker.buildBarn(); // worker builds barnnew AttackEnemiesContext( // warrior fights everyone warrior, Arrays.asList(worker, medic, barn)).fight();new HealAlliesContext( // doctor heals allies medic, Arrays.asList(medic, worker)).healAll();new RepairBuildingsContext( // worker repairs barn worker, Arrays.asList(barn)).repair();
  • 48. But, requirements had changed
  • 49. Use cases:
  • 50. Use cases:
  • 51. Rolepublic interface Attacker { void beat(Attackable attackable);}
  • 52. Objectpublic interface Worker extends EntityComposite, Attackable, Healable, Builder, Attacker {}
  • 53. Old role implementationclass AttackerImpl implements Attacker { private final static Integer STRENGTH = 10; public void beat(Attackable attackable) { attackable.receiveDamage(STRENGTH); }}
  • 54. New role implementationinterface AttackerStats { Property<Integer> strength();}class AttackerImpl implements Attacker { @This AttackerStats attackerStats; public void beat(Attackable attackable) { attackable.receiveDamage( attackerStats.strength().get() ); }}
  • 55. Initializing unitEntityBuilder<Worker> builder = unitOfWork.newEntityBuilder(Worker.class, name);Unit unit = builder.instanceFor(Unit.class);unit.health().set(100.0);unit.name().set(name);AttackerStats attackerStats = builder.instanceFor(AttackerStats.class);attackerStats.strength().set(5);worker = builder.newInstance();
  • 56. new AttackEnemiesContext( // warrior fights everyone warrior, Arrays.asList(worker, medic, barn)).fight();new HealAlliesContext( // doctor heals allies medic, Arrays.asList(medic, worker)).healAll();new AttackEnemiesContext( // worker’s revenge worker, Arrays.asList(warrior)).fight();
  • 57. Pros• Giving system behavior first class status• Easy to maintain• Object style of thinking is closer to peoples mental models rather than class style
  • 58. Cons• We are strongly tied to Qi4j• Poor community• Developer must communicate a lot with customer.
  • 59. Try it yourself!https://github.com/Qi4jSample/Qi4jSample Questions?