- Introduction
- All Software Is Complex
- Controlling Complexity Though Design
- The Craft of Programming
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Craft of Programming
Becoming a good programmer requires that you develop a feel for the aesthetics of code. It's not enough that the code sort of works; we need code that's beautiful as well as functional. After all, as a developer you're going to spend a lot of every working day working with code in one way or another, and it's a drag having to work with ugly things all the time. Much better to make the code pleasing to the eye, because it's amazing how long software lasts. Ten years from now, you don't want to be looking at some of your code and cringing because of how ugly it looks.
Converting from design ideas to source code is not a mechanical process. Yes, initially you can just mechanically translate the design ideas, but once you've done that you have to read the code and adjust it until it feels right. This process of making it feel right is called refactoring, and is a process of identifying and removing code "smells"—as in "That code stinks, we need to clean it up."
Responsibilities Are Implemented as Methods
Whatever an object is responsible for knowing is likely to be an attribute of the class, and as such will need a set of accessor methods. These are represented in Ruby as follows:
class Member attr_accessor :name, :phone_number, :email_address end
Responsibilities that involve the object answering a question are usually implemented as query methods, and the method name will have a trailing ? if the method returns a Boolean true/false answer.
class Member def matches? ( search_criteria ) # to be implemented using test driven development return false end end
Normal behavioral responsibilities are usually implemented as methods that return whatever is appropriate. Give a method name a trailing ! only if the method can have drastic consequences.
class Member def notified ( club_event ) # to be implemented using test driven development end def already_notified? ( club_event ) # to be implemented using test driven development return false end end
For symmetry, a query method (already_notified?) has been added in this example to make it easier to ensure that duplicates are never sent.
Allow Test-Driven Development To Improve Your Design
While it's extremely tempting to jump from the design ideas into writing the methods, that's normally a mistake. It's much better to pause, think of how you're going to unit test the methods, and then write the test first. When you write the test, you'll probably realize that the original name you were going to give the method doesn't really look right when written down. Whenever that happens, pick a better name and use that one instead of your original design.
The next article in this series will show how the email notifications part of the club membership system can be implemented in Ruby using test-driven development. In doing so, it will uncover yet more complexities in what initially looked like a really simple application.