Richard Leggett on New Media

• Home
• Contact
• Log in

12 comments

1. § zedia.net said on : 09/12/08 @ 14:16
   Can you elaborate on the use of pure functions because I read the wikipedia article and I can't seem to find a way to use that to code better.
   
   Thank you
2. § Richard Leggett® said on : 09/12/08 @ 14:46
   I'll give it a go, my limited understanding of this is basically... a pure function is one that only depends on the arguments passed to it and has no side-effects. (see http://en.wikipedia.org/wiki/Side_effect_(computer_science) ). So it won't, for example, access a singleton or modify the state of the application, it will only deal with those values or objects passed in. As such you won't find a pure function both retrieving data (a "query") and operating on/modifying that data (an "operation").
   
   The reason for limiting a function to one or the other is to reduce the amount of things that can go wrong when you call it. The function is perfectly isolated from external influences and as such you can accurately predict the pre and post conditions for calling this function (you can usually do that anyway but this guarantees it). The result is a more stable application that is more easily tested and experiences fewer exceptions.
   
   Perhaps one example of a side-effect you may have experienced when starting out programming would be the "remove these values from this array" conundrum. You have an array of 15 numbers ranging from 1 to 5, you want to remove all "5's". At first you attempt to loop through the array from 0 to array.length, and when you find the value you splice() it out. Only in doing so you've now altered the length of your array and the next iteration through the loop will mean you might end up overshooting the new length of the array. The solution is as simple as looping through backwards instead of forwards, but it illustrates the perils of operating on an object whilst at the same time querying it.
   
   In the context of a complex application, these inter dependencies can manifest themselves in much worse and hard to track down ways.
   
   For another reason also see Referential Transparency:
   http://en.wikipedia.org/wiki/Referential_transparency
   
   For even more reading see how functions in Haskell are pure:
   http://www.onlamp.com/pub/a/onlamp/2007/07/12/introduction-to-haskell-pure-functions.html
   
   I hope that helps!
3. § zedia.net said on : 09/12/08 @ 14:59
   I will definitely look into that.
   Thank you for your time.
4. § Scottae said on : 09/12/08 @ 15:41
   Very nice post. I've recently been trying very hard to implement a lot of design patterns into projects I work on. I saw this post not too long ago:
   
   http://www.as3dp.com/2008/11/09/actionscript-30-strategy-design-pattern-under-no-conditionals/
   
   I love the idea of not using if/switch/conditionals. Makes your coding so much cleaner and easier to maintain.
5. § Richard Leggett® said on : 09/12/08 @ 15:49
   Thanks for the link Scott, also an excellent book in itself.
6. § Marc Pelland said on : 09/12/08 @ 16:06
   Thanks for the tips. Always looking for ways to improve efficiency (and readability) of the code that I write!
7. § Liam Walsh said on : 09/12/08 @ 17:13
   Another neat trick (though not so neatly scaleable as using pure functions strictly in this sense) is to use bitwise operators with the functions as objects placed into an array, instead of a complicated list of conditionals. This works best when there's a lot of possible 'if this and this but not that that or that' statements.
   
   It's old news I know, we were all doing this in Flash 5 but a lot of new dogs might wanna know some old tricks.
   
   http://www.moock.org/asdg/technotes/bitwise/
   
   http://www.elitecoders.de/mags/cscene/CS9/CS9-02.html
   
   Thanks for the tip though, I had to step back from learning the patterns as I found myself getting a little pattern happy : when you've got a shiny new hammer everything looks like a nail and all that.
   
   Top Blogging Richard.
   
   
8. § Iain said on : 09/12/08 @ 17:54
   Great post Richard - encapsulation, separation of concerns, loose coupling, etc are some of the main things Flashers (me included) don't devote enough time to.
   
   I've been reading quite a bit about unit testing / TDD etc recently, and I can see how it would be very useful on full scale software products, but can't really see how to apply it to the kind of Flash stuff I do. Automated testing of user interfaces seems futile, and there isn't much business logic within my Flash code. Any thoughts on that?
9. § Richard Leggett® said on : 09/12/08 @ 18:16
   @Liam, more nice links! yeah some of those older articles never seem to lose relevance, Timothy Groleau's "scope chain" being one for sure.
   
   @Ian, funny you should mention that, I was just running FlexUnit on an AIR app I've started the very second I got the comment. There were actually two guys who came from a more classic development background that I was working with on the project mentioned in the post (this was quite some time ago now so if I got any details wrong hopefully they forgive me), anyway both of them vehemently supported TDD... I fought it at first but it makes total sense for applications, well actually it works extremely well for anything that is very "data" driven, it was in fact the ONLY way we could possibly implement the level of complexity/business rules required and have confidence in it with the thousands of boundary cases and combinations possible. Ultimately the test suites were the thing that (having taken what I considered too long to write), led to a very rapid development workflow that paid for itself many times over in developer time, particularly when adding features or working in a team.
   
   So I can totally agree that for a lot of websites, particularly the creative stuff it doesn't make sense at all to shoe-horn TDD in there, however possible it might be.
   
   But anything that does fit nicely into the MVC paradigm might also be a good candidate for TDD, because you can always test the "M" independently, but as you say, this really involves being able to test the business logic. You can also use tools to test UI's with Flex, but in Flash it's not so feasable nor particularly useful in the context of an "experience" piece.
   
   For the most part I find that in almost any Flash work, website, game or application, there's something testable. For example in a website I might load data from XML or CMS, and parse that data. Here are my candidates for testing, my domain model and my parsers which are in almost all websites.
10. § Dan said on : 11/12/08 @ 02:16
    Hey,
    
    I second all that, exept
    
    >polymorphism
    >readable
    
    in a switch statement you at least see at a glance what's happening, otherwise you'd have to sift through a couple of classes first.
    Occasionally an advantage in our fast-paced agency biz.. particularly when dealing with other people's code. ;)
    
    That is, if the number of cases is huge and likely to increase you should avoid switch, of course.
    
    
    Cheers, Dan
    
11. § Phillip Kerman said on : 14/12/08 @ 03:48
    Good post. I'd only suggest that the appeal to avoid a few if/switch statements on the surface is really of limited or no value. However, setting up interfaces that multiple classes implement has great value. The user of such classes (that all implement the same interface) need not know or care HOW each variation implements the methods. It was a huge thing for me to really grasp. I guess I'm just saying people shouldn't have an odd goal to simply avoid if-statements.
12. § Richard Leggett® said on : 14/12/08 @ 11:35
    Absolutely agree. The by-product of using polymorphism correctly is that you avoid if/switch statements, but that shouldn't be the primary goal.

Comments are closed for this post.