Design by Contract in robotlegs AS3
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Design by Contract in robotlegs AS3

on

  • 1,601 views

 

Statistics

Views

Total Views
1,601
Views on SlideShare
1,601
Embed Views
0

Actions

Likes
0
Downloads
13
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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 Presentation Transcript

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