Sunday, January 31, 2010

Thoughts on OO design

OO design is a creative activity. To be successful at it, you’ll need a mixture of both talent and learned skills. There is no such thing as correct design. There is only good, bad and somewhere-in-between design. OO program is simply a collection of objects that send messages to each other. But how do you design these objects? What objects to create? Which objects should interact? In my work, I usually begin OO design by identifying abstractions. I look at the problem from higher level. I try to identify abstractions that model true nature of the problem. An common mistake is to completely model real-world entities. In software development we have possibility of using abstractions to make our job/life easier. You should use this to your advantage. I assign each object a single responsibility. Note that assigning responsibilities is not easy at all. If you are good at assigning responsibilities then chances are, that you’re are good at OO designs too.

Understanding responsibilities is key to good object-oriented design”—Martin Fowler

Once you’re done with the design, how do you know if it’s good or bad? There are two metrics/principles that you can evaluate your designs against. These are coupling and cohesion. These principles are very powerful in assisting you to make your OO designs good. Funnily, the principles don’t even come from OO, but from Structured design. Coupling is simply a degree to which each object is dependent on each one of the other objects (Wikipedia definition). Coupling quantifies the dependencies among objects. It can be loose or tight. Loose coupling is desired, since it’s more change-friendly. Fewer dependencies make introducing changes easier. Cohesion tells us how focused a class is in fulfilling its responsibility. Does a class have well defined responsibility? Are all parts of class (methods etc) focused on fulfilling that, and only that responsibility? High-cohesion is desired, since it promotes robustness, reusability, and understandability.

To sum up, here are the key concepts I use in my day-to-day OO design:

  • Abstractions
  • Responsibilities
  • Loose-coupling
  • High-cohesion

Following books helped me to gain more understanding of OO design:

Final advice: The best way to become better at OO design is to do it a lot. A huge amount of it.   

Saturday, January 30, 2010

DRY – The first step

It has been said that a thousand miles journey starts with a single step. So in case journey = becoming a better developer, then first step = DRY. DRY stands for Don’t Repeat Yourself. I see way too much copy-paste development around. This needs to stop. If you constantly copy-paste code around, you’re limiting yourself of becoming a better developer. Code duplication is evil, and it’s simply against common sense. So why do we do it? We do it probably because it’s easier, it doesn’t require us to think. When we stop thinking, our journey of becoming a better developer ends. Anyway, does anybody know how do you disable CTRL+C in VS :)? 

Wednesday, January 27, 2010

Is anybody interested in open-source tool like Silverlight Spy?

A few months ago I started to work on a Silverlight project. It was a business-line application, pretty much standard of that type. It was my first project in Silverlight. Anyway, soon I found this great tool called Silverlight Spy. It’s a tool for runtime inspection of Silverlight applications, something like Firebug but only for Silverlight. I was impressed with the software since it was very powerful. The tool costs around 99 EUR, which is not much for the value you get. However, as a passionate developer, I like to develop my own tools (during my free time of course:)). It was then the idea of similar open-source tool was born. I decided to develop a proof-of-concept application called Silverlight Buddy(now thinking of renaming it to Silverlight Inspector). Here’s the what I have done by now:

  • Intercepting Silverlight application before it’s displayed in browser
  • Injection of custom code logic into an Silverlight application  
  • Solved communication between Silverlight application and Silverlight Buddy tool. (both using COM and JavaScript)
  • Support for hosting DLR inside Silverlight applications (Just like in Silverlight Spy)
  • Very basic “Inspect Element”-like functionality

The app is not stable since it is intended only to be a proof-of-concept, written in a quick-and-dirty way. But as you can see, all the major issues/parts have been solved. There is still a huge amount of work to be done in order to make it a usable application. Now,I have never run open-source project, and to be honest, I don’t have time to. That’s why I thought there was somebody out there willing to continue to work on the project. I will probably be a committer myself, but don’t have time to devote fully to the project. If somebody is interested please write a comment.

Here are some screenshots of the app so far.


Notice the red border around “Search” textbox, it represents “Inspect Element” functionality as you move your mouse over the elements.

I hope someone will be willing to continue the work on this project so the effort I have made so far will not be wasted.