Design by Contract in robotlegs AS3

Editor's Notes

• #2: Design by Contract via robotlegs for AS3\n
• #3: \n
• #4: \n
• #5: 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
• #6: Design the functionality of your application in Contracts, not Classes. What does this do for you?\n
• #7: A Class is the implementation of functionality.\n
• #8: 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
• #9: 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
• #10: \n
• #11: 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
• #12: 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
• #13: 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
• #14: Adobe in the Cairngorm 3 documentation recommends breaking up your application into functional areas.\n\nMe too.\n
• #15: 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
• #16: 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
• #17: 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
• #18: 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
• #19: 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
• #20: 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
• #21: 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
• #22: 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
• #23: 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
• #24: Define contracts that align with your services, then aggregate them on each UI based on the functionality the UI will have.\n
• #25: 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
• #26: 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
• #27: how how how? I’ve been skipping over the implementation details so far. here we go.\n
• #28: There are some basic tools and patterns that facilitate design by contract.\n
• #29: 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
• #30: so it’s better to attach functionality at runtime.\n
• #31: rather than inherit the functionality at compile time.\n
• #32: Ok, here’s how you can do it in robotlegs as3\n
• #33: 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
• #34: 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
• #35: 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
• #36: this utility will also auto-wire mediators based on the Type information from mapped components.\n
• #37: 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
• #38: Covariance relates to any type or any sub-type. it’s equivalent to an IS check in Flash.\n
• #39: Interface checks are covariant by default. you have to do an is check to get the interface information.\n
• #40: \n
• #41: \n
• #42: \n
• #43: \n
• #44: \n