This is part four of a five part series about SOLID class design principles by Robert C. Martin. The SOLID principles focus on achieving code that is maintainable, robust, and reusable. In this post, I will discuss the Dependency Inversion Principle.
The Dependency Inversion Principle (DIP): High level modules should not depend upon low level modules. Both should depend upon abstractions.
This is part three of a five part series about SOLID class design principles by Robert C. Martin. The SOLID principles focus on achieving code that is maintainable, robust, and reusable. In this post, I will discuss the Liskov Substitution Principle.
The Liskov Substitution Principle (LSP): functions that use pointers to base classes must be able to use objects of derived classes without knowing it.
This is part two of a five part series about SOLID class design principles by Robert C. Martin. The SOLID principles focus on achieving code that is maintainable, robust, and reusable. In this post, I will discuss the Open Closed Principle.
The Open Closed Principle (OCP): You should be able to extend a classes behavior, without modifying it.
This is part one of a five part series about SOLID class design principles by Robert C. Martin. The SOLID principles focus on achieving code that is maintainable, robust, and reusable. In this post, I will discuss the Single Responsibility Principle.
The Single Responsibility Principle (SRP): A class should have one, and only one, reason to change.
Bellow is a single function commented in two different ways. Which one is better?
NSString* MD5StringOfString(NSString* inputStr) { //UTF8 encoding is used so the hash can be compared with hashes of ASCII strings NSData* inputData = [inputStr dataUsingEncoding:NSUTF8StringEncoding]; unsigned char outputData[CC_MD5_DIGEST_LENGTH]; CC_MD5([inputData bytes], [inputData length], outputData); NSMutableString* hashStr = [NSMutableString string]; int i = 0; for (i = 0; i < CC_MD5_DIGEST_LENGTH; ++i) [hashStr appendFormat:@"%02x", outputData[i]]; return hashStr; }
NSString* MD5StringOfString(NSString* inputStr) { //convert the string to UTF8 encoded byte data NSData* inputData = [inputStr dataUsingEncoding:NSUTF8StringEncoding]; //calculate the hash unsigned char outputData[CC_MD5_DIGEST_LENGTH]; CC_MD5([inputData bytes], [inputData length], outputData); //convert hash to a hexadecimal string NSMutableString* hashStr = [NSMutableString string]; int i = 0; for (i = 0; i < CC_MD5_DIGEST_LENGTH; ++i) [hashStr appendFormat:@"%02x", outputData[i]]; //return the hexadecimal string return hashStr; }
Consider the following if statement:
if(dragOperation != NSDragOperationCopy && NSPointInRect(currentMouseLocation, self.bounds)){ //do something }
Even though you may have worked out what the condition represents, it probably took you a little longer than it should. It’s complicated, making it time consuming to read, and prone to bugs upon modification. Thankfully, there is an easy remedy:
Read the rest of this entry »
Let’s jump straight into the code:
#import <commoncrypto /CommonDigest.h> NSString* MD5StringOfString(NSString* inputStr) { NSData* inputData = [inputStr dataUsingEncoding:NSUTF8StringEncoding]; unsigned char outputData[CC_MD5_DIGEST_LENGTH]; CC_MD5([inputData bytes], [inputData length], outputData); NSMutableString* hashStr = [NSMutableString string]; int i = 0; for (i = 0; i < CC_MD5_DIGEST_LENGTH; ++i) [hashStr appendFormat:@"%02x", outputData[i]]; return hashStr; }
Now for the explanation.
Read the rest of this entry »
The ternary conditional operator (?:) can be used as a short-hand version of an if statement. It is a feature of many languages.
For example, this code:
int height; if(isTall) height = 50; else height = 10;
can be better written as:
int height = isTall ? 50 : 10;
The ?: operator is good for replacing very simple if statements, but is bad for complicated if statements as it can harm readability.
Here is a common misconception when it comes to password security:
“It’s unsafe store user passwords as plain text in the database, so I’ll MD5 the passwords. MD5 is safe because it is one-way encryption, and takes too long to brute force.”
WRONG!
An unsalted MD5 hash can be cracked in less than a second, because it is vulnerable to a precomputation attack. Don’t believe me? Try it for yourself. There are dozens of websites that will take a hash, and return the original password almost instantly. This is true of all hashing algorithms, not just MD5.
How do you defend against a precomputation attack? You use a salt when computing the hash. Using a large salt makes it infeasible to precompute. Also, it helps if you have a strong password that contains numbers, uppercase letters, lowercase letters, and especially symbols. You get bonus points if your password contains strange characters (unicode characters, ascii characters above 128, etc) because nobody can be bothered precomputing rainbow tables for those.
This post is the result of investigation into a stackoverflow.com question of mine.
So, you’ve created a spiffy NSView of your own, and have decided to make it compatible with bindings. Great! So you go and read the documentation, and you look at mmalc’s GraphicsBindings example. You override bind:toObject:withKeyPath:options: and everything works. But wait! Why isn’t the NSWindowController ever being deallocated anymore?
Now you’ve got a nasty retain cycle on your hands. You do a little research and discover that not only do other people have the same problem, but even Apple’s bindings used to have it a few years ago. How did Apple fix the problem? With the magic, undocumented class NSAutounbinder, which nobody seems to know much about.
Other people will tell you that you don’t need to override bind:toObject:withKeyPath:options: and that bindings work automatically. This is only a half truth. NSObject does provide an implementation of bind:toObject:withKeyPath:options:, but it only half works. Using the default NSObject implementation, changes in the model will update the view, but the reverse is not true. When the bound property of the view changes, nothing happens to the model.
So, what is a Cocoa developer to do? I’ll explain how to implement your own bindings that work exactly like Apple’s, with no retain cycles. I haven’t found this solution anywhere else, so as far as I know, I’m the discoverer. I feel so special. It has been mentioned before at least once. The solution is hard to find, though.
