The Artima Developer Community
Sponsored Link

Orthogonality and the DRY Principle
A Conversation with Andy Hunt and Dave Thomas, Part II
by Bill Venners
March 10, 2003

<<  Page 2 of 3  >>

Advertisement

Building Code Generators

Bill Venners: If you build a code generator to avoid duplication, you must invest the time to build and maintain the code generator. You have to explain the code generator to other team members. Therefore, creating a code generator has costs as well as benefits. How do you decide when the return on investment is great enough to actually justify building one?

Dave Thomas: You never build a code generator just because you feel like it. You build one because you are motivated by some underlying principle, like avoiding duplication. Or, sometimes you might want to encapsulate the knowledge of an expert and make it available to other people. For example, you can tell a Microsoft IDE that you want a new MFC (Microsoft Foundation Classes) application, and it will generate 2000 lines of code for you. Most people who use it, to their shame, don't understand that code. Some expert at Microsoft said this is the way it should be, and the whole world followed suit. Don't use code generators because you fancy doing it. Use them because there's a business benefit to doing so.

That's true for all the tools we recommend using. Don't use them just because they're there. Use them because they fit into the overall philosophy of how you want to develop.

Andy Hunt: Creating a code generator is an investment. You're banking that it will be cheaper in the long run to build the code generator, because as changes come up you can simply tweak the input to the code generator and regenerate the byproducts. Without a code generator, you will have to manually make changes by hand each time to all the byproducts. If you expect a lot of volatility, a code generator can be a good investment.

Dave Thomas: In fact, I'd go further. Typically, if I build a code generator, chances are good I will generate the products manually first. And only when I come back to it will I say, "I'm now in a situation where I need to automate this." That approach has two benefits. First, I might never come back, in which case I don't have to write the code generator. If I do come back, I've already validated the code generator's output. So I don't just march off into the unknown, I actually aim at a definite target.

Bill Venners: I once had a manager who discouraged me from making a code generator tool by using the argument, "But then we'll have to maintain the tool." I later decided he was right in that case, because it was better for the company that I just write the code by hand. In a different case, though, I created a code generation tool that paid for itself. We had a database whose schema changed from release to release. My code generator read in an SQL database schema, that we had to create anyway to change the database, and generated the layer, a C module, between the database and the code. Every time we changed the database, boom, we just regenerated the layer. It saved time and bugs, because once we got the bugs out of the code generator, the C code it generated never contained any bugs.

Dave Thomas: There's also a subtle effect that comes about when you create a code generator. If you remove the friction for change, you'll find yourself making changes you need to make more often. That's a good thing.

Andy Hunt: You're not resisting the process.

Dave Thomas: Right. Maybe a schema change is not a great example, because you don't make gratuitous schema changes. But if you have a code generator that makes something painless, then you're more likely to use it. That means you're more likely to keep things tidy and clean. And you'll extend the life of your software. It's a good habit to follow.

Andy Hunt: This relates to working with metadata, an idea presented later in the book. The idea is to work closer to the level of what you want to express. In the case of schema change, you'll go into an SQL file and make a schema change. You don't have to change member variables and data fields just because the schema changed, the code generator does that for you. When you need to make a schema change, you make it and hit the button. Metadata keeps the act you must perform commensurate with the change itself. You want to avoid, at all costs, a little change that requires a bunch of other tasks. That kind of magnification kills many projects. The simple code generator or equivalent metadata technique keeps the actions commensurate.

Dave Thomas: This extends to the idea of orthogonality. If you have a truly orthogonal system, unrelated elements are expressed independently. Here you have a business-level change: one thing changes at the business level and one thing changes in the system. If the boss says, I want negative numbers red, you change one thing and suddenly all the negative numbers in the system are red.

Andy Hunt: That sounds a lot like DRY: One piece of knowledge in the domain changes, one piece of the system changes.

Dave Thomas: That almost happened to me about a month ago. I was working with a large web application that dealt with registrations in an online membership system. The numbers started out small, a couple hundred here and there. As it grew to tens of thousands, the client found the numbers difficult to read, so they requested commas in all the numbers. Luckily, I only had one change to make, and every number the system outputted then had commas in it. That's an important thing to think about. Code generators let you do that, because they let you have one expression of something.

<<  Page 2 of 3  >>


Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us