kuwamoto.org

In the intro, we talked about the problem we want to tackle, which is to refactor DragTile to be more flexible. If you haven’t read it yet, you might want to check it out.

Back? Ok. Now, let’s look at some code.

Step 0 – the starting point

The original files for my investigation can be downloaded from Ely’s site, or you can get my slightly munged version here.

Step 1 – pull up the FlexibleContainer superclass

Even though we said we were going to use composition instead of inheritance to separate these classes, we do this as a first step because it is easier than pulling out a helper class.

Tip 3: Always refactor in small steps that leave the external behavior unchanged

The basic procedure is to create a superclass (which I called “FlexibleContainer”) and to walk through the DragTile code method by method and property by property to move things to the superclass if it seems appropriate.

I started by moving all of the local variables that seemed “general” to the superclass. This included the _items array, the renderers array, and so forth. The variables that seemed specific to the Tile layout were left in the DragTile class.

Because most of these variables were private, moving them to the superclass caused a lot of compile errors, most of which I fixed by moving the appropriate methods to the superclass.

In one case (dragTargetIndex) I needed to create a protected accessor so that the subclass could get at this information. If you want to be a stickler about it, making a private member protected requires some thought. Is this the right way for a subclass to get information from its superclass? In this case, it’s probably not the right thing. The “right” thing is probably to pass the drag information as a parameter during the drag operation. This brings us to the next tip:

Tip 4: When refactoring, don’t try to make it “perfect”. Just strive to incrementally improve the code each time you touch it.

Creating a protected accessor here was the quickest way to separate these two classes without overcomplicating the design. We can come back and fix this later after the dust has settled.

More »

I love Ely’s DragTile component (demo). However, I have always wished that it were easier to extend its behavior to encompass different layouts. To me, that immediately suggests a (big) refactoring. For those of you who have never done refactoring or who don’t refactor as often as you should, I thought it might be fun to walk through this step by step.

What is refactoring?

Refactoring is the process of incrementally changing the structure of your code without changing the outward functionality. It may seem silly to focus on not changing the functionality, but it is actually pretty important.

The idea is that there are two distinct phases of work: coding and refactoring. During coding, you add new functionality. During refactoring, you restructure your code while making sure that it continues to work properly. Not changing functionality during refactoring gives you a strong reference point as you make lots of iterative changes to the structure. You know your refactoring was successful if the new code still does what the old code did.

Refactoring for better reuse

Usually, you refactor code so that it can be more flexible or more reusable that it currently is. Sometimes, the change that is required is obvious. In other cases, you have to think a little before figuring out how to transform your code.

In this particular case, we want to make it easier to change layouts. Looking at the DragTile code, there is quite a bit that would be the same no matter what the layout is, and relatively little that needs to change with each new layout algorithm. Because the layout algorithm is something that is likely to change in various use cases, it is probably a good idea to isolate this functionality into a separate class.

Tip 1: Cleanly separate out the code that you think will need to change often into a separate class.

The most obvious way to divide up the DragTile layout code from the rest of the DragTile code is through inheritance:

Splitting things up in this way allows us to create a new subclass with a different layout (say, a circle) while reusing the logic that might be common to both, such as the code to talk to item renderers and do animation.

The other main way to split things up is through composition:

In this case, the container delegates to another object in order to do layout. There are a number of advantages to this approach:

1. Using delegates often makes it possible to modify behavior at runtime. After we are finished with this particular refactoring, we should be able to change the layout of one of our containers without reparenting. Woohoo!!
2. Decomposing larger classes into smaller classes can make it easier to evolve different parts of the system separately as needs change. For example, let’s say we later decide to split up FlexibleContainer into two classes: one that is lightweight for easy download, and another that is robust, to handle caching, localization, etc. Should “DragTile” inherit from the light one or the robust one? If layout is handled through delegation, you may not need to choose.
3. Composition often allows for greater decoupling. For example, let’s say you are building a photo organizer module. With the inheritance approach above, it would be difficult to create the module in such a way that the photo module knows absolutely nothing about the layout. With the composition approach, you could provide a default layout (say, Tile), while allowing the user of the module to pass in a different layout if needed.

All of this leads to the next tip, which is:

Tip 2: Think hard before using inheritance. Composition is almost always a better way to separate out the flexible part of a class from the invariant part.

So now we have a general idea of what we want to separate out, and how we want to do it. We’ll start digging into actual code in the next post.

It’s been interesting reading reactions from folks like Ted Leung and Ryan Stewart on the Flex open source announcement. I imagine that more interesting discussions are going to happen as people slowly digest the news and start digging deeper into what this all means and how it will all work.

One of my concerns around open sourcing Flex is around how we stay disciplined about what goes into the framework. As it stands, it is quite difficult for the Flex engineers to balance between the things they would like to add to the framework versus practical considerations like download size and runtime performance. We are going to make sure we don’t get bogged down in feature-itis or “design by committee”.

One thing that I think could help is a clearly articulated philosophy about what Flex is, what Flex is not, and how it should evolve going forward. One community that has done a particularly good job at this is the microformats community. In many ways, the microformats movement grew up as a reaction to some of the more ambitious movements around adding semantics to the web. Because of this reactionary nature, the value of practical, small, incremental steps was greatly appreciated by everyone in that community.

As we open up Flex development to the world, my hope is that we can build a strong, core philosophy around Flex that is similarly grounded in keeping things practical, small, and focused.

I don’t usually glom onto these news postings, on the theory that you already have plenty of blog sources for this kind of stuff. However, this is a topic that is near and dear to my heart, so I thought I’d write a little about it.

Today, we announced that we are going to open source the Flex SDK under the Mozilla public license. in my mind, this is just another step in our continued push to open up our platform to make sure that our community can feel confident in building their applications (and in many cases, their businesses!) on top of it.

I’m obviously pretty excited about this, which begs the question: should we have open sourced it earlier? I don’t think so. We have gone through quite a bit of change between Flex 1.0 to where we are now (remember ActionScript 2? remember the old pricing model? remember the huge API shift from 1.5 to 2.0?) and IMHO, it might have been more difficult to make some of the radical changes we did if we were following a completely open process.

Now, the situation is quite different. The Flex community has reached critical mass and is growing daily. The Flex SDK codebase has had most of the rough edges smoothed off of it, and we are at a point where we no longer expect huge API changes in our existing core API. Most importantly, it feels like the right time to invite the community to become part of defining what Flex is.

We are still working out the details, but I think this is pretty exciting. More details can be found here.

Someone emailed me recently to ask about a case of asynchronous calls that I think is fairly common. At the risk of opening up the floodgates (no, you cannot email me every time you have a Flex question!!!), I think it’s worth answering publicly because it probably trips a lot of people up.

Note that this is a more basic (and common?) case than the stuff I was talking about earlier. For more advanced solutions, see here, here and here.

From: XXXX@XXXXXXXXX

I have two loops. One grabs an Xml file that contains a list of a bunch of Xml files I use to layout data to print. (What I am doing is printing a set of documents).

So, as I loop through each, I call the URLRequest to grab the Xml to process and register the Complete event (which takes care of processing the Xml).

So if I have 20 documents, I find only the last one gets handled, the rest are ignored. I am guessing this is because the thread does not stop. I am thinking synchronous events are not an option either.

What I want to happen is one fires, it lets me do what I want to do, then the next one fires. Or alternatively, one is processed, then the next one is processed.

Am I making sense?

Yes, it does make sense, and I bet a lot of people get stuck on this. So here’s the answer.

More »