By Peter Bell

The Simplest Thing That Could Possibly Work: Getting Started with OO

Ben Nadel is doing a great job of working through the concepts of OO programming, but I want to promote Dan Wilsons advice of doing the simplest thing possible (even if procedural) and then refactoring to OO. Here's why . . .

OO programming takes a while to get up to speed with. There's not only the idea of using objects, but you also need to use a bunch of design patterns to solve various problems that are commonly encountered. There isn't "one true way" to do OO and there are very few recipes for getting started. Because of this it can get easy to get so caught up in all the new concepts that it becomes really difficult to get it all straight and get a good architecture.

One thing I've learnt from TDD and agile is the idea of doing the simplest thing possible - anything more complex is probably wrong anyway :-)

I find now that while I'll try to get some ideas about architecting something, if I'm unsure how to solve a problem correctly, I'll just hack any old solution that works. As I add more scenarios, I'll see good candidates for refactoring and will user that to evolve my class model and API.

There are a bunch of benefits to a refactoring approach. Firstly, you're never that far outside of your comfort zone so the process is much more comfortable than trying to get the ideal architecture upfront. Secondly you get working code quickly. Thirdly you don't get stuck in analysis paralysis - you just get something working and then improve it. Fourthly, your don't end up building a huge edifice you'll never end up using.

An Example
A while back I was trying to come up with "THE validation framework" that I could use for all of my validations. I came up with an extremely complex system that ended up not working terribly well when I tried to use it within my framework. This time round I'm just hand coding validations within my objects and slowly refactoring those to a set of validation helper methods that I'm going to compose within my beans. By starting with hard coded validations, I'm getting working code quickly, and by refactoring only to implement real use cases, I know that the API works better than anything I could develop in the abstract.

So, if you're trying to design something, consider coming up with a nice simple scenario and coding the simplest tests and then code required to implement the scenario. Let me know your experience, but I've found this approach to make it much easier and more enjoyable to create elegant code.

Thoughts?

Comments
You might like this book:

http://www.amazon.com/Refactoring-Patterns-Addison...

I think it would fit well in the general process that you outline. Fowler's Refactoring is another good read, and while it doesn't specifically describe refactoring to patterns it provides useful paradigms.
# Posted By Joel Hooks | 7/15/08 12:40 PM
@Joel, Thanks for the recommendation. I think Josh's book is excellent and recommend it to others frequently. You're right, though, that this posting is a good place to promote it - so thanks for doing so!
# Posted By Peter Bell | 7/15/08 1:41 PM
@Peter,

I think I will give this a try. Having a working application may help me to see how the "model" would form around what already exists in a refactoring sort of way.
# Posted By Ben Nadel | 7/15/08 1:46 PM
A good general rule of thumb is that if you're stuck, code something. The code helps to show you the way - even if it's only the wrong way :-)
# Posted By Peter Bell | 7/15/08 2:09 PM
@Peter,

I think you are right - seeing the wrong(er) way is better than seeing no way at all.
# Posted By Ben Nadel | 7/15/08 2:13 PM
Couldn't agree with your more Peter. A lot of times you need to get OO out of your mind and just deal with solving a problem, which is what coders do best. Then refactoring to OO, thinking about the architecture, etc, is what I tend to do next.
# Posted By Sami Hoda | 7/15/08 2:24 PM
@Peter,

this reminds me of another post I read some months ago somewhere on the web... basically it said "don't let perfect stand in the way of good"... if you keep searching for the perfect way you may never come up with a working solution.
# Posted By Christoph Schmitz | 7/16/08 2:43 AM
Great post!

I have often learned a good way to solve a problem by solving it in a poor way first. TDD has certainly improved my ability to experiment in this way.
# Posted By Steve Bryant | 7/16/08 1:41 PM
BlogCFC was created by Raymond Camden. This blog is running version 5.005.