Jim McMaster’s Post

Yet another code smell is the use of Switch Statements. These are procedural artifacts in OO code. In particular, in many cases you have several switch statements doing different things for the same values, often a type code. If you add a new type, or different behavior for an existing type, then you need to find and change all of them. The alternative to using switch statements is polymorphism. Often, a type hierarchy is a more elegant way to solve the problem. You want a set of subclasses that encapsulate the behavior. The first step is to “Extract Method” to get the switch statement into a method, then “Move Method” to a class. After that, you can “Replace Type Code With Subclasses” or “Replace Method With State/Strategy”. Then you can “Replace Conditional With Polymorphism” to break it all apart. Of course, if you have only a few cases in a single method and don’t expect them to change often, then the above is probably overkill. You still might want to “Replace Parameter With Explicit Methods” to eliminate the switch. One special case Fowler mentions here is when you repeatedly check for a null object before calling methods on it. If you find yourself doing that, then “Introduce Null Object” can save a lot of repetitive code. Create an object that returns sensible default values and create one of those instead of using a null value. You can find descriptions of the refactorings at https://lnkd.in/gdJjNQcF

Methods that are too long make code really hard to understand, and are a bad code smell. A good rule of thumb says a method should be no more than 10-25 lines of actual code, not counting comments, white space or curly braces on their own lines. Any method longer than that is a good candidate for breaking up into shorter methods. It matters how you do it, though. I once heard a (possibly apocryphal) story about a developer who cut his long method into arbitrary 20-line chunks named sub1, sub2, etc. This would not have been useful, even if it did satisfy the letter of the rule. It certainly did not clarify the code. A good method reads like a paragraph with the steps clearly named for their purpose. All these steps should be at the same level of abstraction. Don’t mix low-level statements with higher-level method calls. It is fine to extract a single statement into a method if the name of that method makes the code more clear. Loops are often good candidates for extracting into a method of their own.  The way to split a method is to read it through, separating out the “things” it is doing. Then extract each of those “things” into a method that is named to describe that “thing”. If some of the extracted methods are still too long, rinse and repeat, breaking them the same way. One sure sign you need to extract a method is when you feel the need to write a comment describing what is happening. Comments can get out of date or out of position, but if you extract a well-named method you are durably describing the code. When breaking down a method like this, you might run into a problem where you have to pass a lot of parameters, which can be hard to follow. Martin Fowler suggests several possible refactorings to help, like “Replace Temp With Query”, “Introduce Parameter Object” and “Preserve Whole Object”. In some cases, you might need “Replace Method With Method Object”. When you have a complicated conditional, you often can simplify it with “Decompose Conditional”. You can find descriptions of all the refactorings mentioned above at Martin Fowler’s site, https://lnkd.in/gdJjNQcF. Everyone should bookmark that site and be familiar with the refactorings he describes. Your code will be better for it.

The next code smell in the Refactoring book is Long Parameter Lists. These can make it confusing and difficult to call constructors and methods. This is especially true when you have several parameters of the same type, like private int calculateFoo(int x, int y, int z) It is very easy to pass the parameters in the wrong order. There are a few ways to reduce the size of the parameter lists. If you are getting multiple parameter values from the same object, consider passing the whole object instead using “Preserve Whole Object”. If we are getting parameters by calling methods on another object we know about, you can move those calls into the method with “Replace Parameter With Method”. As a last resort, when you have a lot of unrelated parameters, you can “Introduce Parameter Object” to bundle them into a single parameter. One solution I don’t like is to move method variables into fields to avoid having to pass them as parameters. Fields should belong to the whole class, not to an individual method. Using fields for this purpose also obscures the data the methods use. If the method can be called concurrently, data in the fields can be corrupted. I am ambivalent about using a parameter object, especially in constructors. First, it is easy for these to become dumping grounds for junk we might no longer need as the method changes. Second, passing too many parameters to a method is an indication it should be broken up, and the parameter object hides that code smell without actually fixing it. Finally, for constructors, a parameter object causes the method signature to lie about the dependencies of the class. This idea comes from the test experts at Google. Reading the signature should tell you what the class needs to do its job, and that just shows the parameter object. It does *not* show that we depend on all the things *contained in* the parameter object. This makes writing tests for the class more difficult and makes the code harder to understand. Using many parameters might make calling the constructor more difficult, but this is less of a consideration when we are using a dependency injection framework. Then, we offload the responsibility for keeping the parameters straight to the framework. If we really do need a lot of dependencies, especially if we don’t need all of them every time, using a Builder or static factory methods are both good options. You can see descriptions for the refactorings at https://lnkd.in/gdJjNQcF

The last code smell in the Refactoring book is Comments. All the previous code smells were malodorous, but comments are not. They are a *sweet* smell, and can be valuable. Even though they are good, comments *can* indicate problems. People often use them as a perfume to deodorize bad smells. When you see code with a lot of comments, a closer look might show bad code that needs refactoring. If you see a bunch of comments delineating sections of a long method, that often indicates a need to break it up. Use “Extract Method” to create methods with names that obviate the need for the comment. If you see a comment explaining what a method does, then perhaps you should “Rename Method” so the comment isn’t necessary. If you see comments that describe the required state of the system at a given point, you might “Introduce Assertion” to force the system to verify that state. To reiterate, comments are not bad in and of themselves, as long as they add value. But comments often are not maintained when the code changes and can become out-of-date. Then they do more harm than good. Creating comment that doesn’t *need* comments is ideal. You can find descriptions of the refactorings at https://lnkd.in/gdJjNQcF

The next code small is Refused Bequest. This is when a subclass decides not to use some behavior "bequeathed" from a superclass. Fowler says, and I agree, that this is a *very* faint smell, and very likely not worth addressing. Some OO people insist this means that the class hierarchy is wrong and you need to "Push Down Field" and "Push Down Method" into the subclass that actually uses the behavior. But what if multiple children need it? Then you would need to push it into an intermediate subclass, and make those children inherit from that. You might want to do that, but it complicates the inheritance hierarchy, and might not be worth it. As with a lot of code smells, this is a matter for your own judgment. You can find descriptions of the refactorings at https://lnkd.in/gxmaYiRv

The next code smell I want to highlight is one of my personal pet peeves, Primitive Obsession. This means using a primitive or String for a value just because it sort-of fits, rather than using a well-designed object. Yes, there is effort in creating the object, but that effort pays off many times over. What do I mean? How about using a float to represent money just because it has a decimal point. That *always* causes problems. You always have to deal with imprecision and rounding errors. You need a Money class that can store exact values, handle multiple currencies and perform conversions. Another horrible idea is to use a String (or even worse, an int) to hold a phone number. You often need to parse out a country code or an exchange by splitting the String or dividing the int. You can express these concepts directly in a TelephoneNumber class. The same goes for using String to represent an address. Use an Address object to hold a name (which should also be an object), a house number, street name, apartment number, city, province. Postal code and country. The same goes for dates, times, ranges and other types. Of course, Java has already defined classes for those. Any time you have a value in a primitive and keep having to split it apart to use it, you really need to define an object.The appropriate refactoring is “Replace Data Value With Object”. Sometimes, we use a primitive to represent a type code, which can also cause problems. You should use an enum or a class. If you don’t depend on the type code to affect behavior of the system, use “Replace Type Code With Class.” If you do use it for branching, then you can consider “Replace Type Code With Subclasses”, or “Replace Type Code With State/Strategy”. Another smell is storing parts of a value in an Array, then having to pick out pieces by knowing the indices of those pieces. If you find yourself doing this, you can use “Replace Array With Object”. Sometimes, you might have pieces of a value in individual primitive fields and parameters. In this case, you can put them together with “Extract Class” or “Introduce Parameter Object.” Shoe-horning complex values into a primitive is always a bad idea. You may think it is “easier” or “less work”, but it always comes back to bite you. You can find descriptions of the refactorings at https://lnkd.in/gdJjNQcF

"100 Go Mistakes and How to Avoid Them" If you want to get some impulses to improve your Go chops: you can use the free summary of all 100 mistakes from the book over at https://100go.co/ Perfect to help you spot issues with your current Go practices, or as an appetizer to dive into the full-length book.

Yet another short blog about chapter 5 of my Learn #Cpp by Example book: build a higher/lower card game https://lnkd.in/eUfXm-zS

Another code smell is Feature Envy. This occurs when a method in a class is too interested in the data contained in a different class. You might see the method fetching several items from another class, then doing a calculation on that data. The point of creating objects is that data and the operations on that data live in a class. The solution is to “Move Method” into the class with all the data and calling it from the original. Sometimes, only a part of the method depends on foreign data. In that case, you can use “Extract Method” on that part and “Move Method” the extracted part to the right class. What if the method requires data from more than one class? Then it is a judgment call which class to move it to. Usually you would pick the one with the most data. If possible, another option is to “Extract Method” to break out the parts that need the foreign data into separate methods and then move them to the appropriate classes. Martin Fowler points out that some Design Patterns from the Gang of Four book encourage Feature Envy, notably Strategy and Visitor. These get passed to classes and require data from them in order to operate. In these cases, the benefit of encapsulating a behavior in order to make it easy to change outweighs the downside of the Feature Envy. You can find descriptions of the refactorings at https://lnkd.in/gdJjNQcF

Now into chapter 7 of Carola Lilienthal's and Henning Schwentner's book "Domain-driven Transformation" with the $work book club. Cannot recommend this book enough. It's a very condensed, practical, and holistic book on how to get legacy monoliths or "microservices" into shape. They even have a repository of "domain driven refactorings" including technical, but also social/team-topological ones: https://lnkd.in/euE2kNWu 😍 Currently, the book is German-only, but there will be an English version, too.