After a bit over two years of pushing for it, it feels fantastic to finally put this into our master page <script language="javascript" type="text/javascript" src="/_scripts/jquery-1.4.2.min.js"></script> 22 2010-03-04T15:45:30Z 50 true 2010-03-04T15:45:43Z feels-great-to-jquery 2010-03-04T16:20:31Z This really is quality stuff. Check it out if you want a quick laugh [link][1] [1]: http://www.amazon.co.uk/gp/cdp/member-reviews/A3B2IL2CP9GW2C?sort_by=MostRecentReview&x=17&y=8&display=public 3 2010-02-26T16:02:22Z 46 true 2010-03-04T06:10:46Z the-amazing-amazon-trolling-of-dr-m-von-vogelhausen 2010-03-04T06:10:46Z I have read the GoF Design Patterns book a few times now, it is one of those things where the more you read it, the more you get out of it. Most patterns in that book can be boiled down to a single principal "Delegate all related functionality as much as possible, and always code against the interface of that delegation, not the implementation." The first benefit of this is obvious, when you delegate out single responsibilities, that code becomes a lot more straight forward to read, and easier to reuse. The second part is a bit trickier, because it is something that can take awhile before you can be bitten by it. Circles and Ellipses --------------------------- There is a huge amount of emphasis on inheritance when there is any discussion on object orientation, even though it is probably the single worst thing about the paradigm. The first comes from a pure modeling point of view, which is more widely known as the [circle-ellipse problem][1]. A circle is an ellipse with an additional constraint put on it, which makes it a classical "`is-a`" relationship. We are taught that as soon as we see that, we are talking about inheritance. So what happens when `Ellipse` has a `stretchX` method that mutates one axis but not another? You have a few options. First, `Circle` could override `stretchX`, and raise an exception if it is called on `Circle`. This is a pretty ugly solution, and will be a huge gotcha in the API. Another possibility is that `Circle` could make `stretchX` mutate the Y axis at the same time. Our problem here is that it violates the [Liskov Substitution Principal][2], which states that any subclass should be able to be swapped in for its base class without breaking the program. If we are working with an ellipse, and we call both the `stretchX` and `stretchY` methods, we will not end up with what we want. When it comes to OO modeling, a circle is not an ellipse (just as a square is not a rectangle). You cannot use inheritance to effectively model a relationship where the subclass is a constrained version of the base class, even though the way we think of inheritance would lead us down that road. Implicit Coupling ----------------- Let's say we are modeling some sort of car and truck registration system. We have a class called `Vehicle`, it has a method called `start` on it. `start` does things like flip an `isStarted` flag, does some logging, maybe stores data about fuel levels and whatnot. This works great while we continue with trucks and cars. But what happens when the system has to be expanded to include bicycles? A bike doesn't have an engine, and starting a bike is a very different process then starting a car. Since we chose to leverage inheritance for code reuse, we are in a bit of a pickle, since we now have many subclasses that depend on specific implementation details of `start`. A refactoring of `start` means those changes will cascade down our inheritance hierarchy, and it will turn a minor job into a pain in the ass. Using Composition ----------------- Lets say that when we were designing `Vehicle`, we saw there was a group of related functionality, and delegated out to an `Engine` interface. First of all, by the time we have a decent number of cars, the things that `start` touches will probably have to handle a few different cases. Having multiple `Engine` implementations will clean that up substantially. Secondly, when we have to implement our bike, all it takes is `NoEngine implements Engine`, and we move on to the next problem. The more ways a class can be impacted by changes in related classes, the harder it is to maintain. By eliminating coupling, you end up reducing the amount of code you have to change when modifying the system, and also increase flexibility. Finally, compositional design is WAY easier to test then anything else. When Inheritance is a Good Idea ------------------------------- Inheritance is a good idea when you are not talking about a constraint on a base class, when you are already behind a more complete level of abstraction, and when your subclass is basically the same as the super class with only a small behavioral change. So in our `Vehicle` case, maybe you have `TruckEngine implements Engine`, and the only difference between implementations are in terms of fuel consumption rate. Sure, there is a tight coupling, but in this case it will save us time down the road, since there is a very small chance that our changes will effect that one piece that is different. Looking at inheritance in this fashion ends up dramatically reducing is usage in big systems, and becomes more used to get a job done it a quick, slightly hacky fashion, rather then the primary form of polymorphism and code reuse. [1]: http://en.wikipedia.org/wiki/Circle-ellipse_problem [2]: http://en.wikipedia.org/wiki/Liskov_substitution_principle 19 2010-03-01T19:17:30Z 47 true 2010-03-01T19:17:41Z composition-over-inheritance 2010-03-01T19:17:41Z Started playing around with the amazing [jQTouch][1] last night (still a work in progress, but you can see more or less how it works if you add .mobile to the end of any url here). There are a few bugs still (which is fine, its still in beta), the only major issue I have is the fairly extreme lack of documentation. Supporting multiple views for user agent strings was extremely easy. First step is to register a mime type alias from `text/html` to `mobile`. Second was to add a `before_filter` on the `ApplicationController` that did a quick check on the user agent string like this `request.user_agent =~ /Mobile|webOS/` (turns out looking for mobile will cover most supported platforms, except for palm), and if that was true, set `request.format` to `:mobile`. Finally, just add a `<viewname>.mobile.erb` for each view or layout you want to support. If you are using implicit view rendering based on action name, you don't even have to do anything. if you are using a `respond_to` block, just add a `format.mobile` clause. One thing I was pleasantly surprised by was how easy it was to transform `will_paginate` to something completely different. I needed only next and previous, with non default labels, and in a `<ul><li><a></li></ul>` type structure. Thanks to nice separation of concerns, and compositional design, it was just a matter of extending their `LinkRenderer` and overriding two one line methods. That is just a really quick run through, once I finish this up, I will do a more complete writeup. [1]: http://www.jqtouch.com/ 18 2010-02-26T15:59:46Z 45 true 2010-02-26T15:59:53Z now-with-iphone-osity 2010-02-26T15:59:53Z Oddly poetic, they were suspended due to "strange activity" [http://twitter.com/scientology][1] [1]: http://twitter.com/scientology 3 2010-02-26T00:27:19Z 44 true 2010-02-26T00:27:34Z scientology-twitter-account-suspended 2010-02-26T00:27:34Z