The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
Almost all of us know the GoF patterns. Perhaps not all of the patterns. I forget them from time to time, but with more experience, I remember more and more. (I keep forgetting what a Memento is. 
)
As important as they are, I think there are other, perhaps more important patterns and principles that I follow. Some of them are “in my head” when I code. Some of them are there and I just follow them without naming.
They are fundamental theorems/patterns/principles of programming.
Good idea to review them.
Good idea to write about them.
Good idea to revisit them.
Don’t you think?
Languages and trends pass by. Principles and how we approach our programming tasks stays with us. Forever.
I’m currently deep into Python. Design patterns I learned earlier still apply. I learned JavaScript a while ago. Same thing.
I feel it’s not the languages we know count. It’s how we go about doing the tasks we have on hand. It’s how we craft software no matter what tools we use. Python is good for one thing; Java for other; and Javascript still for another, but we can apply “our learned way” to all of them.
Once we have solid principles in place, we’re able to reuse it from language to language. Deepening and improving that knowlege has the highest return, I feel.
So I’d like to revisit SOLID principles; GRASP patterns. They’re at the heart of programming. Close to my programming heart, at least. More to follow.
|
focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.
–Steve Jobs in [BusinessWeek, May 25, 1998]
|
I am a TDD fan. I’ve been one for a long time.
But I’m not a TDD practitioner. I don’t follow the TDD methodology of writing the test first, implementation second.
Not yet.
Uncle Bob convinced me to try. Again.
Time to become a TDD developer! Time to step up my code quality.
I have said it many times, Robert Martin, Uncle Bob, is someone who has had a big influence on my career (you can find other references on this site). I usually buy all his books. His latest one, The Clean Coder, is not only a joy to read, it’s filled with great advice. It’s like reading The Pragmatic Programmers again. Who doesn’t want that?
Let’s get to the point, though. Why would I ever want to follow TDD? Isn’t that counterproductive, and… silly!
Do I want to write higher quality code? Faster? Less buggy? And get more fun out of it?
Of course!
But I’ve tried before. And reverted to old ways of doing it.
This time, I want to infect myself with it.
How? By trying harder. By making this “my way” of doing things. And by actually writing the tests first.
It’s going to take more effort than that!
Today I got an opportunity to do just that. And I am surprised how I was able to kill a few bugs. Bugs that would have “bugged” me later.
But why write the tests first?
So I develop good coverage. So I design better. So I get instant feedback. Those are 3 very good reasons. Not only that, but by first thinking about the tests, I will cover more corner cases; I will make my code testable.
Do I really need more convincing?
Not really. Benefits are clear. It’s just a matter of “doing” it.
Lastly, to give some direction and insight on how to proceed, here are the three laws of TDD as per Bob.
The Three Laws of TDD
1) You are not allowed to write any production code until you have first written a failing unit test.
2) You are not allowed to write more of a unit test than is sufficient to fail—and not compiling is failing.
3) You are not allowed to write more production code that is sufficient to pass the currently failing unit test.
Martin, Robert C. (2011). The Clean Coder
Ready to join the TDD camp?
While looking at the top weekly links on dzone (good way to see what are the important things that happened), I came across a very intriguing entry: The Top 10 Attributes of a Great Programmer by Steve Riley.
These always “get me,” but a lot of times they end up being just a quick browse. This one is different. Though the attributes are similar to what I”ve seen before (see entries in Craftsmanship category), they’re good. And it’s always good to re-read them.
Here are the top 10 form the blog. Read the whole post as the author gives his own explanations. My thoughts are below.
- Being a great problem solver.
- Being driven and lazy at the same time.
- Ability to understand other people’s code
- Having a passion for programming
- Loving learning for the sake of learning
- Being good at math
- Having good communications skills
- Strong debating skills
- Extreme optimism
- Extreme pessimism
Being a good problem solver? Of course! Great programmers are great problem solvers. Agreed!
Being driven and lazy. I keep telling my wife that being lazy is a good think. She doesn’t get it! But I agree that being lazy is a good quality to have in programming.
Ability to understand other people’s code. Somewhat agree. Is it just me, though, but I see a ton of code that I’m having very hard time following! I would say it differently: great programmers write code that others can understand; great programmers write code for humans to read.
If you don’t have a passion for programming… can you excel in any other profession if you don’t have passion!?
Everybody needs to learn and work hard to get better. That’s why great programmers go the less traveled road.
Being good at math? Debatable. I think there is a connection, but wouldn’t pay that much attention to it. But yeah, I was good in math.
All in all, a good post by Steve.
Uncle Bob in Clean Code states, “the Boy Scout Rule tells us we should leave the code cleaner than we found it.” Another words, when we make changes to the code base, we should make sure we are leaving it (checking in to repository) cleaner.
The original rule of the Boy Scouts states: “Leave the campground cleaner than you found it.”
This is very relevant to the way we code!
Following this rule is not easy. In some cases it might not even be possible (most likely not a good sign).
Why isn’t it easy?
When I code, I try to follow similar, but fundamentally different rule: don’t make the code base worse than you found it. Worse, not necessarily better. Following this rule is not easy either. It means I have to get a good understanding of the code before I make a change. It means I don’t try to put in a quick fix or a hack, add special exceptions (wouldn’t it be easy to just add a simple “if” statement).
It all starts with one broken window, as the theory of a broken window tells us.
The Boy Scout rule takes it a step forward. It requires you to not only understand the code, but improve it before you check your code in. Just the other day, I saw something that smelled. It had a lot of duplication. My task was to add something similar. Since code was already written, somewhat complicated, I went with the easy route. I followed the same route: I added more duplication! I didn’t necessarily make the code base worse, as it’s already been like that. But I didn’t make it better either.
I did not follow the Boy Scout rule.
If I did, I would have taken the time to refactor the code, generalize it, and make it reusable. I would have removed the duplication and made it easier to modify later on. Read: I would leave it better than I found it.
I’m already feeling resistance. I’m thinking about situations where it might not be possible to follow the Boy Scout rule.
Resistance is good. It means that I have some growing to do. It means that following this rule is…
A challenge!
Yes, it’s going to be a challenge. But the reward is there. Making improvements to the system you’re working on is a reward on its own. Talking about this in an interview should also get me extra points. But most of all, following the Boy Scout rule will make me work harder. It will make me a better programmer.
|
|
Steve McConnell
–The poeple who are best at programming are the people who realize how small their brains are. They are humble. The people who are worst at programming are the people who refuse to accept the fact that their brains aren’t equal to the task. Their egos keep them from being great programmers. The more you learn to compensate for your small brain, the better a programmer you’ll be. The more humble you are, the faster you’ll improve.
in Code Complete |
Do you agree with Steve?
Effective Java (2nd Edition)
by Joshua Bloch
ISBN 0321356683
Date Read 1/2011
My Rating
I read the 1st edition (my recommended book) a few years back. I just re-read the 2nd edition. It’s one of the best Java books around (the other must read would be Java Concurrency in Practice).
Read it.
Re-read it.
The 2nd edition is a little harder to read. Some chapters are too long and are not as cohesive (not like they were in the 1st ed), but still, getting all these tips from a Java champion is very valuable. At the very least, you can use his tips to win your arguments and influence others on your team.
And that’s the reason I’m recommending this book: read it to become a better Java programmer. Isn’t that a good reason?
I’ve been quiet on this blog lately. I’ve been quiet in 2010 as a whole! Only 5 blog posts during the year. That does not make it too active, I must say. As new year’s resolutions go, I plan to change that.
Starting from this week, I set a goal to write a blog post per week. But wait, I have 4 blogs (click Home to see them). So that’s roughly 1 post a month. That should at least double the postings in 2011.
In 2010 I changed jobs. I am now involved with pure Java development, which I love. But it’s also a nice change from using Java sparingly, mostly coding Velocity templates — not too say you cannot get creative, but it’s a “contained” circle. I am now “free” and that should lead to more interesting ideas and topics.
What am I up to lately? Deepening my Java threading knowledge, and Java in general. (I just got an idea for a separate post on this subject. )
What are my plans for 2011? I plan to deepen my Java skills. Java 7 is around the corner (finally!). I’d like to improve my Spring knowledge — if you don’t use it you lose it. Guava — a google collections library. I’d like to learn that as well. I mean, I’d like to find uses for it. I also want to learn bash scripting. Never learned it, but coming across it very often. Time to dig deeper. If time allows, I also want to learn Python. Seems like it should be in my toolbox. I can perhaps combine it with Google App Engine application. Sounds cool.
2011 should be a busy year.
How am I doing it? How do I find the time? Early to bed, early to rise… said Benjamin Franklin. And that’s exactly how. I wake up at 5:15am everyday. And I try to collect at least 2 pomodoros (25 minute sessions, with 5 a minute break; check out ChromoDoro in Chrome) reading, practicing — doing dev-improvement stuff. That’s how. It works for me.
I started learning design patterns a good number of years ago. I learned a few. Probably around half. But others I just kept forgetting. Or I should say, never learned. 
C’mon, you did not learn design patterns!
Knowing design patterns is important. Very important. It’s probably the best “tool” in your toolbox as the developer. Not only the Gang of Four (GoF) patterns, which are the most known, but others as well.
But learning design patterns is hard.
It’s not that the design patterns are hard, it’s the process of learning and retaining that’s hard. Why? If you don’t use it… you’ll forget it.
So a month or two ago, I decided to revisit the subject. I decided to learn the Gang of Four (GoF) patterns. Learn it in a way so I can remember. As I said, not an easy thing to do. (I guess I will really know if I learned it after a few months. )
There is probably only one way to really “learn” it. Use it in code. That’s when you see the context, problem, solution, etc. That’s when you really know all the details about the pattern. And most likely it will “stick” with you and you will not forget it.
If you really want to learn a pattern, use it!
If you can…
I have a few that I have used: Observer, Factory, Builder, Singleton, Facade, Strategy, Template Method, Iterator, Command… I think that’s about it.
OK, that’s less than half of the 23 GoF patterns. What happened to the others?
Blame it on my memory.
On the other hand, I don’t want to just use it because it would be cool. It has to be the right fit. And that does not happen often… But when you do see the opportunity, you should be ready!
BE PREPARED
How do you prepare? Here are some ways.
Read the GoF book several times. OK, that might work for you. For others, it probably will not.
Read multiple books. Yes, that’s probably better, but it still could not work for some of the patterns.
Read multiple books and other references at the same time. Yes, I think this is better. Much better. Why? In How To Read A Book the author explains that this is the highest level of reading, Syntopical Reading. By reading multiple authors on the same subject you have trouble understanding, in this case, it might be a particular pattern, you gain the highest level of understanding.
So that’s what I did: I started reading mutliple resources on GoF Patterns at the same time.
Of course, it would be ideal to have ALL the books available on the subject. I don’t. But I have several and that’s a big help. I also have a subscription to Safari (as part of being ACM.org member), and they have a few books there as well. And of course there is the Internet, loaded with many great references.
I started with the classic GoF book. As I read a pattern, let’s say Abstract Factory, I picked up another book or looked at another website. I read a few until I really “got it.” I also looked at code samples. I read some more. Eventually, I got the “aha” moment.
I’d like to share the resources I have used and that I find valuable on the subject of the Design Patterns. Just so your learning will be, let’s say, a bit simpler.
It’s already taken me a long time to get to this point. So without further ado, here they are.
BOOKS
Design Patterns by Gamma,Helm,Johnson,Vlissides
There is a reason it’s the classic book. Start your learning from this book. The explanations, reasoning and usages are the best in this book. But it’s not an easy book to read. In fact, I think it’s hard if you’re not a C++ programmer. Still, it’s a great book.
Refactoring to Patterns by Kerievsky
I appreciate this book more now than when I first bought it. Filled with very good advice. However, it only covers a few of the GoF patterns.
Agile Software Development by Martin
My favorite book. Not on Design Patterns in specific, as it also does not cover all GoF patterns, but still worth checking out the few that it does cover.
Head First Design PatternsAvailable on Safari, this book is loved by many, not so by others (including me). But still a great book on the subject.
WEBSITES
Wikipedia: Design Patterns
More than anything, it contains great examples.
dofactory
(claims to be #1 in design patterns). Valuable resource.
Houston Design Patterns
Great resource on design patterns.
Examples of GoF Patterns
Lists places in the JDK where the patterns are implemented.
INDIVIDUAL PATTERNS
Bridge vs Strategy
If you get stuck like I did, check out this url.
Factory Method
Good examples on how to implement the pattern.
Encapsulation vs Abstraction, a blog post I wrote a few years ago, is the most popular post on this blog. So I decided to revisit the subject. This time, I want to focus more on encapsulation.
Encapsulation = Information Hiding
Did you get that?
Don’t worry. By the end of this post, you’ll get it. 
If you did, you can probably stop reading this post. You already know what encapsulation is. Good for you!
I know McConnell in Code Complete 2 has a great focus on Object Oriented coding, so I turned to his book initially. And I found a great analogy for abstraction and encapsulation.
|
|
Encapsulation is a stronger concept than abstraction. Abstraction helps to manage complexity by providing models that allow you to ignore implementation details. Encapsulation is the enforcer that prevents you from looking at the details even if you want to.
–Steve McConnell in Code Complete
|
This might sound confusing initially. Don’t worry. One thing to take away from it, though, is that encapsulation goes together with abstraction. In fact, McConnell says you cannot have just one, either you have both or you have none. I totally agree. There is no middle ground.
But this post is more about encapsulation…
|
|
The single most important factor that distinguishes a well-designed module from a poorly designed one is the degree to which the module hides its internal data and other implementation details from other modules.
–Joshua Bloch
|
Now we’re talking.
Mr. Bloch, another influential author, is basically telling you what encapsulation is: information hiding.
Once again, it’s a good analogy to have in your mind: Encapsulation = Information Hiding. That’s how you want to remember what encapsulation is.
On a practical level, how do you accomplish encapsulation? Steve McConnell, in in section 6.2 has some very good points:
It’s also important that encapsulation not only applies to classes. It’s easy to only think of classes. But if also applies to object, package, namespace, class or interface.
Real World Example
I found another great definition in the book I started reading, Design Patterns by Lasater.
“Think of encapsulation like your mortgage company,” recommends Lasater. You send of your mortgage payment every month and you get a statement back showing your loan data. Your mortgage company is hiding from you the accounting details. And you don’t really care, as long as your principle is decreasing after your payment is applied.
To take this a step further, here’s a class definition for the Mortgage payment. The idea of encapsulation is to only expose the necessary methods. Not more.
// taken from Design Patterns
class CustomerPayment {
public double postPayment(int loanId, double payment) {
// posts a payment
}
public List getAmortizedSchedule(int loanId) {
// return a schedule in array
}
There would be many more methods in the class. But they’re hidden. Hidden from the class interface. You cannot access them outside the class code. That’s in fact, a definition of encapsulation. Only exposing the required methods, in this case post payment and get schedule.
To take McConnell’s definition I mentioned earlier and apply it to the above example, proper abstraction allows you talk on a higher “abstract” level, about Customer Payment and not worrying about too many details. Encapsulation, like McConnell said, is “the enforcer,” and it is not allowing you to look at the details. How? By only exposing these 2 methods.
Just one more thing: encapsulation = information hiding.
If you just remember one thing about encapsulation, remember that. I hope I helped you.
Related
Encapsulation vs Abstraction – my related blog post
Reference
Design Patterns by Christopher G. Lasater
Code Complete 2 Steve McConnell — one of the best programming books that I recommend/sk