Design by Contract in robotlegs AS3

1,765 views

Published on

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

  • Be the first to like this

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

No notes for slide
  • Design by Contract via robotlegs for AS3\n
  • \n
  • \n
  • Design by Contract\n\nEach party agrees to the terms of the agreement.\nIn Object Oriented Programming, this is commonly enforced by the compiler’s support for Interfaces\n
  • Design the functionality of your application in Contracts, not Classes. What does this do for you?\n
  • A Class is the implementation of functionality.\n
  • What’s the point of writing object oriented code? reuse, duh.\n\nthe more code you reuse, the less you have to write, more money for you.\n\nOnce the code’s already written, what’s the first thing your client wants you to do?\n\nchange it. duh.\n\nmaximizing the vectors for extension means giving you as many ways to easily change your code with the least impact (preferably none) on existing features as possible.\n\nThis is of paramount importance.\n
  • Externalities are the enemy of clean contracts.\n\nExternalities are a double edged sword. If you already have a bad design, external access to internal details can make life much simpler. The use of public fields and methods that don’t exist in your contracts should be avoided.\n\nIf you’re starting from scratch, keep your contracts short and sweet. Interfaces shouldn’t be driven by implementation details. You’re not defining public methods. you’re designing object behaviors. the methods or fields are the implementation, the tool you use to accomplish your task.\n\nDependencies themselves aren’t bad. Undeclared dependencies are bad. Dependencies that can’t be mocked or replaced or otherwise overridden from the outside are bad.\n\nIf you have dependencies, you’re only as strong as your weakest link.\n
  • \n
  • This talk isn’t about behavior driven development, but they’re definitely aligned.\n\nBehavior-driven development is an entire methodology that strives to communicate efficiently with the business to increase the technology’s value to the business.\n\nOften BDD prescribes user-interface-first development, because that’s the first and most significant thing the business will see once development is underway.\n
  • When is it appropriate to really focus on design by contract?\n\nI am practical and a minimalist. Be practical and a minimalist.\n\nI only focus on behavior driven development and design by contract when it allows me to write dramatically less code.\n\nIt turns out design-by-contract usually allows me to write less code, but if there were a time it forced me into writing more code, I’d drop the approach and go with something else.\n
  • For the design of common functionality.\n\nFunctionality slash features that are shared between different components is difficult to keep under control.\n\nYou guys know what I’m talking about. Some features seem to pervade your entire code base.\n\nThese features suck, because they require you to declare a dependency on a common piece of code.\n
  • Adobe in the Cairngorm 3 documentation recommends breaking up your application into functional areas.\n\nMe too.\n
  • say you have this awesome comp right here.\n\nyou’ve got this thing at the top with lots of little buttons.\n\nand you’ve got a form and maybe a sweet accordion on the side there.\n
  • first thing’s first, code organization.\n\nDon’t start with something like \n\ncompany.application.models\ncompany.application.views\ncompany.application.controllers\ncompany.application.services\n\n\nthat’s ugly.\n
  • go with functional areas.\n\ndo\n\ncompany.application.functionalArea.views\ncompany.application.functionalArea.controllers\ncompany.application.functionalArea.models\ncompany.application.functionalArea.services\n\n
  • Ok, now if you follow standard UI architecture paradigms, you’ll create some controllers for each region.\n\nwhether you write mediators, view controllers, presentation models, view models, whatever, you’ll have some sort of controller layer.\n\nSo each controller is going to take control of the functionality I showed previously.\n
  • Ah, but you don’t have just controllers.\n\nyou gotta get your data from somewhere right?\n\nwe’ve got these things called services and models.\n
  • but when you aggregate your functional areas into controllers, those controllers are forced to declare dependencies on your services and models.\n\nthe controllers are essentially aggregating data from each service/model, based on how much functionality your UI has.\n\nBut this isn’t that bad, right? After all, this is how UIs have been coded for 20 years, since like NEXT STEP or something.\n
  • yeah, see what happens when you’ve gotta write a whole bunch more components?\n\nyou’ve gotta write a whole bunch more view controller/mediator/presentation model/view model code to aggregate the services and models into a different configuration.\n\nbut Isn’t that how it works?\n
  • no.\n\ntake it one step further.\n\ndesign contracts.\n\nalign your contracts with the services or models.\n\nthen let runtime behaviors do your aggregation.\n
  • OK. We have these UIs again.\n\nAggregation is being done on the UI layer already. As soon as you write a Canvas tag, you’re starting the aggregation process. and that’s simply the language of business. business logic.\n
  • Define contracts that align with your services, then aggregate them on each UI based on the functionality the UI will have.\n
  • The implementation of the contracts can still communicate with each other, they don’t exist in a vacuum. but if they do, it’ll be to the contract.\n
  • and look what happens when you start writing your UIs to the contracts you’ve defined. you don’t have to write more controller logic. just UIs. it’s awesome!\n
  • how how how? I’ve been skipping over the implementation details so far. here we go.\n
  • There are some basic tools and patterns that facilitate design by contract.\n
  • firstly. the real principle here is polymorphism INSTEAD OF inheritance.\n\ninheritance is ugly. inheritance requires you to buy into the entire contract of your parent class, even if you only want a small piece of that contract.\n
  • so it’s better to attach functionality at runtime.\n
  • rather than inherit the functionality at compile time.\n
  • Ok, here’s how you can do it in robotlegs as3\n
  • First, a bit about how robotlegs registers and manages mediators.\n\nrobotlegs requires you map mediator types to view component types.\n\nrobotlegs watches the display list for added to stage and removed from stage events.\n\nwhen it sees a view component that you’ve mapped added or removed from the stage, it will register or remove a mediator.\n
  • but it requires a bit of extension.\n\nhere’s an extension I wrote. This extension allows you to very easily code in a BDD design by contract style.\n
  • This utility enables multiple mediators per component.\n\nby default robotlegs only allows you to have one mediator per component (like the earlier example)\n
  • this utility will also auto-wire mediators based on the Type information from mapped components.\n
  • First, a little bit of computer science here. Let’s talk about the Object Oriented Type system a bit.\n\nTypes can be invariant, covariant, and contravariant. I only care about invariant and covariant right now.\n\nInvariant means that when you check for the type of a component, you’re testing for an exact class type match. the type is IN variant, meaning it does not vary.\n\nThis is equivalent to checking if the constructor equals exactly some class type.\n
  • Covariance relates to any type or any sub-type. it’s equivalent to an IS check in Flash.\n
  • Interface checks are covariant by default. you have to do an is check to get the interface information.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Design by Contract in robotlegs AS3

    1. 1. Design by Contract via
    2. 2. who what whyMy name is Paul TaylorI do user interfaces in Flash, HTML,WPF, and Cocoa.I work at Lab49. We are hiringsmarties like you.I work on open source projects liketinytlf and robotlegs
    3. 3. i am on the twitter @guyinthechair i am on the internets at guyinthechair.com
    4. 4. Design by what? Contracts Agreements Interfaces
    5. 5. Why?
    6. 6. Decouple a feature’s Behavior from itsImplementation
    7. 7. To maximizeCode Re-Use andExtension Vectors
    8. 8. To minimizeExternalities andDependencies public
    9. 9. Nervous yet?
    10. 10. Behavior-Driven DesignDevelopment methodology that encouragesadding business value through efficient communication, design, and testing.
    11. 11. When?
    12. 12. In the design ofCommon Functionality
    13. 13. Functional Areas
    14. 14. Functional Areas Login status controlsToolbar User Entitlements/Permissions Header Form Accordion View Header Header Header
    15. 15. company.application.functionalArea
    16. 16. company.application.functionalArea Views Controllers Models Services
    17. 17. UI ArchitectureToolbar Controller HeaderForm Controller Accordion Controller Header Header Header
    18. 18. UI Architecture User Permissions Logging Svc.Session Mgmt. Toolbar Controller Header Form Controller Accordion Controller Header Header Header
    19. 19. UI Architecture User Permissions Logging Svc. Session Mgmt. AccordionToolbar Controller Form Controller Controller Toolbar UI Form UI Accordion UI
    20. 20. UI Architecture User Permissions Logging Svc. Session Mgmt.Toolbar Controller Form Controller Accordion UI #4 UI #5 Controller UI #6 UI #7 Toolbar UI Form UI Accordion UI ... UI #8 UI #9
    21. 21. Functional Contracts
    22. 22. Toolbar UI Header Form UI Accordion UI Header Header Header
    23. 23. UI Architecture User Permissions Logging Svc. Session Mgmt. Permissions Session Contract Logging Contract Contract Toolbar UI Form UI Accordion UISession Permissions PermissionsPermissions Logging LoggingLogging
    24. 24. UI Architecture Event Bus Permissions Session Contract Logging Contract Contract Toolbar UI Form UI Accordion UISession Permissions PermissionsPermissions Logging LoggingLogging
    25. 25. UI Architecture User Permissions Logging Svc. Session Mgmt. Permissions Session Contract Logging Contract ContractToolbar UI Form UI Accordion UI UI #4 UI #5Session Permissions PermissionsPermissions Logging LoggingLogging UI #6 UI #7 ... UI #8 UI #9
    26. 26. How?
    27. 27. The PatternsInversion of Control withDependency InjectionObserver, Strategy, and VisitorDynamic Programming
    28. 28. Polymorphism instead ofInheritance
    29. 29. Attach functionality at runtime...
    30. 30. ...don’t inheritfunctionality at compile time
    31. 31. via
    32. 32. Robotlegs MediationWatches for Event.ADDED_TO_STAGEWatches for Event.REMOVED_FROM_STAGERegisters/removes the mapped Mediatorfor the added/removed DisplayObjectinstance
    33. 33. Type Variant Multi-Mediation https://github.com/dnalot/robotlegs-utilities-variance
    34. 34. Enables multiple Mediators per Component
    35. 35. Auto-wires Mediators based on theComponents’ Type(s)
    36. 36. Type Categories: InvariancemyComp.constructor == MyComponentChecks for the exact TypeThe check is IN-variant, only one typewill match
    37. 37. Type Categories: CovariancemyComp is MyComponentChecks for the MyComponent Type or asubclassThe check is CO-variant, more than oneType can match
    38. 38. Type Categories: Covariance & InterfacesmyComp is IMyInterfaceThis check is covariant by default,because any Class can implementIMyInterface
    39. 39. Type Categories: InterfacesmyComp.constructor == IMyInterfaceWill always be false
    40. 40. map.mapMediator(IType1, Type1Mediator);map.mapMediator(IType2, Type2Mediator);map.mapMediator(IType3, Type3Mediator);Type1 Type2 Type2 Type3 Type1 Type3 Component Component ComponentIType1 IType2 IType1IType2 IType3 IType3
    41. 41. map.mapMediator( UIComponent, UIComponentMediator);Will create a UIComponentMediator instance for every instance of UIComponent or subclass of UIComponent.
    42. 42. Woah
    43. 43. Code

    ×