This Blog


Favorite Posts


July 2010 - Posts

  • DevExpress Newsletter 31: Message from the CTO

    A fun message this time — Pac-Man, yay! — with a serious underlying theme: sometimes the obvious objects in your class model of the real world are not the most optimal. Welcome to antiobject programming...

    What Pac-Man can tell us about Object-Oriented Programming

    We've been doing object-oriented design and programming for getting on for 20 years now, more if you come from the Smalltalk world. You'd think we all know how it works, how we identify the possible objects in our model of the real-world, how we work out the interactions between them, the inheritance patterns, the polymorphism, and so on, so forth.

    Sometimes though all this knowledge and experience can lead us astray.

    Let's take an example from Pac-Man. If you recall there's a maze containing dots for the Pac-Man -- whom you control -- to eat. To make the game harder and and more exciting, there are four ghosts, Blinky, Pinky, Inky, and Clyde, who wander around the maze and suddenly get a whiff of the Pac-Man and start to chase him. Get caught and one of your lives is lost. However, there are four pellets that, if eaten, give you the opportunity to eat the ghosts for a short period of time.

    If you were going to model this in an object-oriented program, you'd probably create a Pac-Man class and a Ghost class, with presumably some kind of maze class to draw the maze. The dots and pellets might be classes too.

    The problem with this scenario is that the Ghost class becomes hard to write. Consider its behavior: it wanders around the maze until it gets "close" to Pac-Man, when it suddenly starts tracking him. But how to calculate "close"? It's not a Euclidean closeness because the ghost can only move along the maze, not hop through the walls. It's a "path closeness". The ghost has to know where Pac-Man is, and calculate the minimal path to him. Calculating that for each ghost at each cycle of the game play on the low-end processor of the time would have been way too slow.

    Instead of trying to design a complex ghost object — the foreground, if you like — we flip our focus to the background: the maze. We give the Pac-Man the ability to leave a smell, an integer value, on the squares of the maze as he moves. Each cycle, the smell evaporates — each maze square decrements its smell value — until it reaches zero. 

    The ghost object then does not have to work out where Pac-Man is and calculate the minimal path to get there, it just instead sniffs out the smell on the adjacent squares. If none, it continues on the path it was travelling. If there is, it just moves to the adjacent square with the stronger concentration.

    This technique is known as antiobject programming. Instead of designing the obvious "real-world" object with its complex behaviors, we design an object that essentially does the opposite of what we originally thought. The new ghost object follows scent and has no knowledge of Pac-Man; the maze squares, instead of not existing at all or being simple static objects sitting there, suddenly have behavior.

    The complexity of the original objects has instead been changed to simple behavior of the antiobjects.

    The video is available here.

    The original source of antiobject programming is from Collaborative Diffusion: Programming Antiobjects by Alex Repenning of the University of Colorado. The whole paper is well worth reading: there’s lots of fascinating information and discussion about the AI aspects of game programming in there, including the introduction of antiobjects.

  • VCL Subscription Build 52 released - now with Office 2010 skins

    Just a quick note to say that we’ve just released Build 52 of our VCL Subscription. Although there have been many changes and fixes in this release, the most prominent feature is the support of the Office 2010 look and feel in the ExpressSkins library.

    For further details on what’s new and what’s changed in Build 52 please go here.

    To download, log in to Client Center with your credentials.

  • DevExpress Newsletter 30: Message from the CTO

    Here’s my message from the 30th DevExpress newsletter. I can’t remember where or when I first learned this trick, but it was fairly early on in my career.

    Improve your code ... by reading

    If you asked a random selection of developers how to improve their code -- its clarity, expressiveness testability, robustness, etc -- you'd probably get a whole lot of good advice about practicing, TDD, BDD, pair programming, and so on, so forth.

    In other words, to improve your code, write more of it. Kind of goes along with the idea of improving your piano playing by playing the piano more.

    But there's another way to improve your code, and that is reading other people's code.

    Let me explain. By reading other people's code, you gain insight into their style (and your own), you gain understanding of particular programming techniques, you gain appreciation of larger code bases, you may even learn something new.

    Of course, I'm not suggesting that you sit back, a cold glass of something brewed in hand, half surfing some code in a window all the time keeping an eye on your twitter feed. No, in order to read code, you have to be able to glean enough knowledge about it that you can criticize it, formulate what you like about it and what you don't, or put into words why you would have done something differently.

    First of all, find some code. I would start off with something fairly small and work your way up. There are many projects at CodePlex or CodeProject that you can take a look at. Find a implementation that interests you or that is written by someone you've heard of.

    Download it and take a high level view. What's the structure of the solution? Does there appear to be one class per file? Pay attention to the names and identifiers: do they imply an implementation? Or are they somewhat opaque? Does it even compile? (Providing you have the required infrastructure, of course.)

    Then proceed from either a top-down or bottom-up approach. I tend to go for the latter: once I have some understanding of how well the low-level classes are designed and written, I can take that knowledge up with me into the higher-level modules. Some people I know take the opposite approach: gain an understanding of the very top-most layers, what the application or class model is supposed to do, and then burrow down wherever your fancy takes you.

    While you are doing this, pay attention to the supporting infrastructure: the test modules (if any), the external libraries it uses, the comments, even the local structure of the code (for example, does the author use exclusively for, foreach, some functional equivalent, LINQ, etc, or does it vary according to purpose).

    Make notes as you go along, not necessarily in a separate file, but as comments in the code itself. If you think that you could have written something better, do so, and check that your version works as well as the original. Make use of a refactoring tool in this endeavor.

    Once you've exhausted one project, go find another and do the same thing. And then do it again, and again. Gradually grow the size of the project you read and analyze until you feel you're at the point that you can help that project get better, and then write the project lead with some suggestions. Become involved.

    I guarantee that if you read other people's code regularly, you'll find your own code improving.

    (Video here.)

    The only thing I’d add is that all you see when reading other people’s code is the end product. You do not see all the dead ends the author hit on the way, you don’t see the mistakes, or the code that failed the tests. You just see the (presumably) polished code, the best implementation the author was able to write. Of course, providing that the author is hosting on some SVN or Git repository (and the author was vigilant about updating said repository), you could take a look through the version diffs to see how the code evolved. I dare say though that this is no longer using the code as a static pedagogical device but as a dynamic investigation into how code is written. You’d still get information, but it would be different information.

  • Rebuild·Restore·Renew: The house three weeks on

    imageSteve Andrews, who helped us on our building day for the DevExpress’ house in New Orleans, is moving from Philly to Seattle. For some reason, spread with awesomeness and dipped in brilliance, he’s taking a whole month over it by driving there visiting as many user groups as he can and by what seems the most circuitous route possible. He’s calling it the Geek Road Trip.

    This weekend he was in New Orleans and decided to pop along and help out at the Habitat for Humanity house DevExpress sponsored. He’s already done two full days: one just before Tech·Ed with GeekGive, and one just after with us. On our day we’d raised the frames for the outside walls, but just take a look at what’s been accomplished over the past three weeks. Today, he helped lay the shingles, baffle, and cap pieces. This is looking like a real house!

    Thanks, Steve. Great work!


Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at info@devexpress.com or call us at +1 (818) 844-3383


DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, Delphi, HTML5 or iOS & Android development. Whether using WPF, ASP.NET, WinForms, HTML5 or Windows 10, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2018 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners