search
top

My week (09/18/2010)

Blog Posts Earlier this week I posted What is too simple and small to refactor? about a  follow up to my first Clean Code experience where I took a very small function, and refactored it.  In the end I was truly questioning; how small is too small to refactor?  This post received quite a bit of a response, including a response from Uncle Bob Martin and several refactors from Cliff Mees, Neal Blomfield (his response), Cory Fowler,  Ben Alabaster begin_of_the_skype_highlighting     end_of_the_skype_highlighting, and even Jon Skeet. My Twitter Worth Mentioning(?) “..I’d explain why, but I have to, like, go put on lipstick.”-@aalear responding to a comment “females are too busy being beautiful” #gogirl 8:25 PM Sep 15th My recent blog posts have generated a lot of feedback among my friends & colleagues. I’m glad. It’s a great conversation. 12:09 AM Sep 15th I’m going to create a restaurant review site & call it StickyTables.com 12:51 PM Sep 13th “Clean Code is a design philosophy more than a naming convention.” – me #justQuotedMyself #dealWithIt 😉 12:36 PM Sep 13th If somebody says my code sucks & they’ll redo it, I’d be hurt. But for my design, I’m relieved. #msPaintSucks 😉 10:56 AM Sep 13th Just saw a really cool job title on LinkedIn “Experienced Code Poet” 11:04 PM Sep 12th When I hear “the cloud” I know I no longer understand what the other person is talking about. #widelyMisusedTerm 9:58 PM Sep 12th Friday; I love you, but you come way too fast. #in 7:12 AM Sep 17th Even when they score a major coup to attract & add value to users, the announcement is littered with comments like “Who uses @MySpace? ” 11:16 AM Sep 16th Got to say; one of the biggest challenges I have blogging is coming up /w relevant examples. 8:17 AM Sep 16th #FF @unclebobmartin not for his Clean Code msg, which is awesome, but for addressing your questions & concerns. #wayToGo about 19 hours ago A programmer started to cuss Cause getting 2 sleep was a fuss As he lay there in bed Looping round in his head Was while(!asleep()) sheep++; 9:13 PM Sep 8th (this wasn’t mine, it was quoted from a StackOverflow question) In my opinion ‘no written requirements’ is the biggest kiss of death a project can have. #stackexchange http://bit.ly/d3rho2 5:42 PM Sep 8th I don’t hate technical buzzwords, only the ones non-tech people have hijacked. 4:17 PM Sep 16th Wisdom from Twitter... read more

What is too simple and small to refactor? (Clean Code Experience No. 2)

Shortly after reading Clean Code, I refactored the data access layer from a project I was working on, and was amazed by how much the code improved. It really was night and day. My first clean code refactoring experience was an obvious improvement.

I was still on that clean code high, when a little function entered my life that I was compelled to refactor. This one left me questioning the limits of what I should refactor and if my refactor even qualified as clean.

I’d like to share that second experience with you in this post.

read more

Procedure Like Object Oriented Programming

In a previous post What’s wrong with the Nouns/Adjective/Verb object oriented design strategy, I talked about how verbs should be implemented in their own separate class instead of as a method strapped onto an entity class. In my opinion, it’s an appropriate way to work with processes and pass those processes around, while keeping code flexible, testable, and highly maintainable. But it has led to comments on Twitter and a link to one of Steve Yegge’s post Execution in the Kingdom of Nouns. Basically, Steve said that turning verbs into nouns was a bad idea (at least that’s what I think he was getting at, there were a lot of metaphors in there :-). It’s easy to see Yegge’s point of view, if you just leave it at that. After all turning your single line of code accessing those actions 1 commentData.Insert(cn); into multiple lines of calling code, when you move the logic into its own class, 1 2 3 4 using (CommentInsertCommand insCmd = new CommentInsertCommand(cn)) { insCmd.Execute(commentData); } definitely sucks. So why not add a static method to the process class so you can access it with a single, procedural like, call? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 public class CommentInsertCommand : IDisposable { ....   public static void Execute(CommentData commentData, int userId, SqlConnection cn) { ValidateCommentParameter(commentData); using (CommentInsertCommand insCmd = new CommentInsertCommand(cn)) { commentData.CommentId = insCmd.Execute(commentData, userId); } }   protected static void ValidateCommentParameter(CommentData commentData) {...} } This way your call is reduced to 1 CommentInsertCommand.Execute(data, cn); I think this has merit and is a clean way to manage your classes. It brings your object oriented code back to a more procedural level. One problem I haven’t quite figured out yet is the naming. To be honest, I’m a little uneasy about it. I should probably name it ‘Insert’, but that’s redundant with the class name and I’m not crazy about naming it ‘Execute’ or ‘Run’ either. I chose ‘Execute’ in this example so all XXXXCommand classes would be consistent across the application, and the name is consistent with the SqlCommand naming which is important since this class kind of emulates SqlCommand. However, I’d still love to find a better name. So, the bottom line is this; why not give all your process classes a procedure like entry point? Why not give more of our object oriented code a procedural language feel? Copyright © John MacIntyre 2010,... read more

top