software engineering
play

Software Engineering and Architecture (Many) Mandatory Reflections - PowerPoint PPT Presentation

Software Engineering and Architecture (Many) Mandatory Reflections And SE Hints Correction to the book! I would have made it differently today Include central methods Present book: I do not show the central method in the strategy


  1. Software Engineering and Architecture (Many) Mandatory Reflections And SE Hints ☺

  2. Correction to the book! I would have made it differently today…

  3. Include central methods • Present book: I do not show the central method in the strategy  calculateTime() I should have. Do it in your hand-ins! AU CS Henrik Bærbak Christensen 3

  4. Inner and Outer Encapsulation

  5. How do I? • Switch from channel TV2 to DR on my Samsung TV set? • A) Push the Button ‘3’ on the TV’s remote control interface? • B) Call Samsung to tell them to send a man to re-solder the wire inside the TV set? • Some of you accidentally use method B CS@AU Henrik Bærbak Christensen 5

  6. Example • What happens when I want a WorldWar II HotCiv? – I have to call you guys to resolder the wires inside! AU CS Henrik Bærbak Christensen 6

  7. Frameworks • What is the process in the mandatory exercises? – To use TDD and compositional design to transform an AlphaCiv application into a HotCiv framework • Frameworks are – Reusable software designs and implementations – Must be reconfigurable from the outside • Just like a TV set • Example – Android Google’s smartphone OS – You do not call Google to make them rewrite their constructor in order to introduce the App for your HCI course, do you!?! CS@AU Henrik Bærbak Christensen 7

  8. Open/Closed • Open for Extension (I can adapt the framework) • Closed for Modification (But I cannot rewrite the code) • Change by addition, not by modification • So – public GameImpl(String whichVariant) { • If (whichVariant.equals (”Alpha”)) { – ageStrategy = new AlphaAgeStrategy() • Is not suitable for implementing frameworks… – I have to open the TV to solder the wires inside  – You have to call Google to make your HCI project app  CS@AU Henrik Bærbak Christensen 8

  9. So… • Keep GameImpl, UnitImpl, CityImpl , … closed for modification! – They form the framework that is reused as-is • Allow adapting HotCiv to a WWII scenario by addition – I can code a WorldLayoutStrategy that produce a Europe map – Etc. – And provide my strategies in the constructor of your GameImpl – And it will do the right thing… CS@AU Henrik Bærbak Christensen 9

  10. Uncle Bob??? • What about Uncle Bob? – Though shall not have more than two parameters as arguments • Disobey him for now… – GameImpl(AgeStrategy ageStrategy , …………………..) • We will refactor HotCiv soon enough to fix it… – Abstract Factory… AU CS Henrik Bærbak Christensen 10

  11. Apropos Defining Worlds

  12. Many like my ‘StubGame’ • … but be careful • If you interpret the datastructure in the GameImpl constructor you have a tile type switch inside the GameImpl – Then how to you make a Dune Game • Tile types ala ‘desert’ and ‘oasis’ ? AU CS Henrik Bærbak Christensen 12

  13. Data driven configuration • However, the idea to keep configuration in datastructures is a good one… – Much better than tedious code ala ‘setTile(0,0, plain) – Easy to write a load from disk version AU CS Henrik Bærbak Christensen 13

  14. You Can Do More Outside Inner and Outer have different Rules! AU CS Henrik Bærbak Christensen 14

  15. Parametric Variant • Example: – GammaCiv requirement: Settlers make cities, archers fortify Coded by switching within HotCiv Framework GameImpl Code: GameImpl, CityImpl, UnitImpl, … AU CS Henrik Bærbak Christensen 15

  16. Parametric Variant • Example: – GammaCiv: Settlers make cities, archers fortify Liability: HotCiv has hard bindings to specific HotCiv Framework unit types. Only Change by Modification! Code: GameImpl, CityImpl, UnitImpl, … AU CS Henrik Bærbak Christensen 16

  17. All is Shit Variant • Example: – GammaCiv: Settlers make cities, archers fortify GammaCiv Delegates HotCiv Framework Code: GameImpl, CityImpl, UnitActionStrategy UnitImpl, … AU CS Henrik Bærbak Christensen 17

  18. All is Shit Variant • Example: – GammaCiv: Settlers make cities, archers fortify REALLY BAD: If you have unit-type switching code in GameImpl, you GammaCiv Delegates still have a parametric solution with all its liabilities!!! HotCiv Framework Plus all the extra interfaces of the Code: compositional approach. GameImpl, CityImpl, UnitActionStrategy DO THE SAME THING UnitImpl, … THE SAME WAY!!! AU CS Henrik Bærbak Christensen 18

  19. Compositional Variant • Example: – GammaCiv: Settlers make cities, archers fortify GammaCiv Delegates HotCiv Framework Code: Gamma GameImpl, CityImpl, UnitActionStrategy UnitImpl, … AU CS Henrik Bærbak Christensen 19

  20. Compositional Variant • Example: – GammaCiv: Settlers make cities, archers fortify GammaCiv Delegates HotCiv Framework What would Henrik say? Is this Code: Gamma GameImpl, CityImpl, Parametric design??? UnitActionStrategy UnitImpl, … AU CS Henrik Bærbak Christensen 20

  21. Compositional Variant • Example: – GammaCiv: Settlers make cities, archers fortify GammaCiv Delegates This is a much better design! (My own solution) Why? HotCiv Framework Because a) No hard binding in GameImpl b) Code: GammaCiv requirements are expressed Gamma GameImpl, CityImpl, explicitly in a single piece of code that bears the UnitActionStrategy UnitImpl, … correct name! AU CS Henrik Bærbak Christensen 21

  22. Inner and Outer • Keep inner code (framework code) clean of variability switching code; have it in the outer code (delegates)! GammaCiv Delegates HotCiv Framework Code: UnitActionStrategy GameImpl, CityImpl, UnitImpl, … AU CS Henrik Bærbak Christensen 22

  23. Inner and Outer • Keep inner code (framework code) clean of variability switching code; have it in the outer code (delegates)! HCI Course OurSuperHCIApp Android Framework AU CS Henrik Bærbak Christensen 23

  24. Inner Outer Collaboration Delegates have to tell something

  25. But what then… • GammaCivUnitStrategy has to – create a City??? – destroy a unit??? • Collaborate via well defined, descriptively named, protocol… • Do not reach into actual datastructures! – Breaks encapsulation… AU CS Henrik Bærbak Christensen 25

  26. Lowering Bindings • True, the downside of using GameImp directly… – As in ‘g.removeUnitAt()’ • … is tight coupling from strategies onto implementation of Game  AU CS Henrik Bærbak Christensen 26

  27. But we can… • Decouple through Interfaces, of course – Interface segregation principle or role interfaces • That is – <<interface>> Game As you know it – <<interface>> ModifiableGame extends Game • void createCityAt(…); • void removeUnitAt(…); • Then GameImpl implements ModifiableGame – And Strategy methods refer to instance of ModifiableGame • Exercise: – Why do we achieve lower bindings using this technique? AU CS Henrik Bærbak Christensen 27

  28. The TradeOff • The benefit – Decoupling / lower coupling between Game and Strategies • The liability – More interfaces to overview • The balance is… – Do we need it? • Yes: Do it • No: KISS – keep it simple, stupid – And refactor when need arises AU CS Henrik Bærbak Christensen 28

  29. Generalization or Specialization? Generalization is not a bad thing…

  30. When Need Arise… • Agile development tells us – You ain’t gonna need it – Simplicity • That is: ”Do not generalize (= complicate) design if there is not use of it” • But do it when need arise… – Triangulation: Add tests that force generalization into existence. • Example: – Archers need to fortify in GammaCiv – Question: Is this a general feature or highly GammaCiv specific? AU CS Henrik Bærbak Christensen 30

  31. Generalize • Fortify = unit is not moveable + defense strength change • Making units non-moveable sounds general to me… – Add accessor to interface ‘ isMoveable ()’ – Add mutator to implementing class ‘ setMoveable(boolean m)’ • Extra clause in the bail out fast of ‘ moveUnit(f,t )’ – boolean isMoveable = getUnit(f).isMoveable(); – if (! isMoveable) return false; AU CS Henrik Bærbak Christensen 31

  32. But what about Legion/Settler • They then have this ‘isMoveable’ attribute also… • But they just never use it – And so? AU CS Henrik Bærbak Christensen 32

  33. Multi Role’d Abstractions Big Ball of Mud Strategy Blob Strategy Multi-dimensional Variance

  34. Consider… • One Strategy to Rule Them All! What is the problem? AU CS Henrik Bærbak Christensen 34

  35. The Problem • ZetaCiv – I want to WinnerStrategy to be a combination of those of BetaCiv and EpsilonCiv – ZetaCivVariantStrategy extends BetaCivVariant and EpsilonCiv • Actually, it is the main discussion in the State Chapter in FRS and the State Pattern lecture ☺ , Stay tuned… AU CS Henrik Bærbak Christensen 35

  36. Storing State Who knows how old the game is?

  37. State in Strategies? • Game age state can be stored in – Game: • Keep track of how many rounds have been played – AgeStrategy: • Ok, some suggested keeping state (age) only here… • Strategy pattern is about algorithms – Algorithms compute stuff, they do (generally) not know stuff… • I may change the algorithm Cohesion again! Keep the state – Change the strategy at runtime in the object where is belongs AU CS Henrik Bærbak Christensen 37

Recommend


More recommend