![]() ![]() Software entities should be open for extension, but closed for modification.Īs a reviewer, you might see indications that this principle is being violated if you see a series of if statements checking for things of a particular type: The reviewer should flag these two responsibilities, and then work out with the author a better way of separating these features: perhaps by moving the Twitter string parsing into a different class or by creating a different class that’s responsible for rendering the leaderboard. ![]() The onMessage and getTweetMessageFromFullTweet methods are both about receiving and parsing a Twitter message, whereas draw is all about reorganising that data for displaying on a UI. While this seems reasonable because it uses the data being gathered by the onMessage method, there are indications that this violates SRP. This side-by-side diff from Upsource shows that a new piece of functionality has been added to TweetMonitor, the ability to draw the top ten Tweeters in a leaderboard on some sort of user interface. You want to look at which methods in a class are likely to change at the same time, and which clusters of methods are unlikely to ever be changed by a change to the other methods. By definition, the author is (or should be) applying a single reason to change the code base – a bug fix, a new feature, a focussed refactoring. This can sometimes be hard to spot from a single code review. There should never be more than one reason for a class to change. The purpose of this post is not to educate you on what these principles are or go into depth about why you might follow them, but instead to point those performing code reviews to code smells that might be a result of not following these principles. The SOLID Principles are five core principles of Object Oriented design and programming. As with all the other areas we’ve covered, not all teams will prioritise this as the highest value area to check, but if you are trying to follow SOLID Principles, or trying to move your code in that direction, here are some pointers that might help. In today’s post we’ll look more closely at the design of the code itself, specifically checking to see if it follows good practice Object Oriented Design. This is part 5 of 6 posts on what to look for in a code review. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |