DCI

1,205 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,205
On SlideShare
0
From Embeds
0
Number of Embeds
544
Actions
Shares
0
Downloads
19
Comments
0
Likes
1
Embeds 0
No embeds

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

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

    ×