DEV Community: Naomi Dennis

Favorite Refactoring Techniques: Extract Class

Naomi Dennis — Thu, 16 Jan 2020 20:58:12 +0000

The next refactoring technique we'll look at is extracting classes. Extracting classes has a similar thought process as extracting functions. In both cases, we are extracting behavior. For classes however, we are extracting sets of behavior or data.

Say we have the following code:

Multiple conditionals that test strings is a perfect code smell that indicates something can be refactored. In this situation, each string in the if statement denotes a name for an item in a shop. The body of each statement is the same; it performs a transaction with said item, the item's value and the money of the person shopping. After the transaction is complete, #perform_transaction() returns the amount of money the shopper has left. The only clause that is different is else, which outputs a message to the shopper that the requested item is not found.

With this information we can split the behavior of the conditionals into two parts: performing a transaction when the item is in the shop and outputting a message when the item is not in the shop. Looking at the transaction portion, we can see that each item not only has its own name, but its own value. We can extract this into a ShopItem class.

With this class, we can rewrite our if statement to more accurately portray the first portion, checking if the item is in the shop and outputting a message if it isn't. Before extracting the class, if the item wasn't apart of the conditional statement, it was seen as not being included in the shop. Now, we can create a list of items and if the item isn't in the list, we can output the message.

Now our code tells a concrete story. Search for an item. If the item is found, perform the transaction and return money to the shopper, if the item isn't found then tell the shopper the item isn't being sold.

As it stands, our if statement looks pretty good. However, we can make some minor changes to make it a bit better.

All in all, our code now looks this (Please note, # -- snip -- is code that wasn't mentioned.) :

Favorite Refactoring Techniques: Extract Functions

Naomi Dennis — Thu, 09 Jan 2020 20:21:12 +0000

The next refactoring technique we'll look at is extracting behavior into functions. Say we have the following example:

SubwayTrain#processStop has a lot of behavior. The intention could be made clearer by separating each behavior into its own method. The behavior we extract will also become available to other classes that may need it, outside of the context of getting passengers at a subway station.

After extracting the behavior, #processStop looks like this:

Favorite Refactoring Techniques: Combine Functions Into Transform

Naomi Dennis — Thu, 02 Jan 2020 13:51:23 +0000

When multiple functions have related behavior that acts on an object together, they can combine into a single function to transform an object. Behavior is the main way to determine of multiple functions should be combined. Let's look at an example.

Say, we have the following functions that calculates the total price at a restaurant.

The calculation functions all relate to determining the total. Because we would need to call calculateDiscount whenever we call calculateSalesTax or calculateTip to get an accurate total; we should consolidate these calls into a single function.

Another way of determining the relationship between functions, is to look at its input, output and name. All calculate functions accept a number and return a number. Based on the semantic meaning of calculating the discount, sales tax and tip, we can determine these methods will likely, only, be called together. After this, we can peek into the functions and get a better idea of its behavior. In our example, each calculation function is returning a changed price.

Thus, we create a brand new function that combines all calculations and returns a transformed price.

Favorite Refactoring Techniques: Split Phase

Naomi Dennis — Thu, 26 Dec 2019 16:36:16 +0000

Split phase is the technique of breaking down and separating bloated behavior. Say we have a function that has multiple behaviors or a single line of code that carries out several behaviors and it's hard to deduce the result. We would split the different phases of a program's instruction; rather than keeping them altogether to make it more understandable and readable.

In the example below, the purpose of the program is to board passengers.

We can identify four behaviors in this script:

Parse input from user
Separate passengers based on class
Board the passengers in order of class

To begin refactoring, we are going to separate the behaviors into functions.

In summary we split the instructions in rawPassengerData#map into the following functions:

#processPassengers
#separatePassengerIntoFlightClass
#boardPassengers
#checkAllPassengersBoarded

A #main() was added to give the program a proper starting point to call main instructions. If we were to read the instructions in #main(), we can deduce the program will: processes a list of raw passenger data, board passengers and checks that all passengers were boarded. All without needing to know the inner workings of each function.

In Conclusion

A good way to view the split phase technique is to keep your functions small, readable and consisting of one behavior. There is more we can do like creating classes and streamlining passenger creation. Look out for future blog posts on refactoring to see the techniques used!

Package Cohesion: Reuse-Release Equivalence Principle

Naomi Dennis — Tue, 10 Dec 2019 17:36:34 +0000

Package cohesion is a way of composing packages that makes them reusable and easily maintainable. There are three package cohesion principles, reuse-release equivalence, package common reuse and common closure.

Let's look at the reuse-release equivalence principle.

REP states:

The granule of reuse is the granule of release

However, I prefer the longer definition of:

All classes in a package must be reusable, and all packages must be released via bug tracking, version control and other forms of release.

A good example of this is the io package in Java. It's a package that is easily usable in complex input/output situations. All classes in the io package depend on either default types or types included in itself.

For example, we would only include classes from the io package if we used ByteArrayOutputStream or IOException.

An example of a package breaking the REP, is if the package needs other packages to be used. Take the example below:

Exploring the files menu, we can see that the the Player package is dependent on the Armor and Weapon packages, limiting its reusability. The Armor and Weapon packages are more reusable since it does't depend on other packages. Like the Math package, a reusable package should be useable in a different project. If the Player package was exported to a different project, it wouldn't be usable since the Armor and Weapon packages are not defined.

We can fix this by combining the classes into one GameObjects package.

In Conclusion

The reuse-release equivalence principle is great for ensuring that packages can be used across multiple projects. One major benefit of this principle is a single package can be used across multiple versions of a project since all changes are inclusive.

One thing we didn't talk about is releasing a package. That largely depends on the developers as there are many different bug tracking, version control, documentation tools, support tools, etc. that are available and it's largely based on preference. The gist of the idea, is, as packages are created and made reusable they should be released to the wider project and/or public.

A Light Introduction Liskov Substitution Principle

Naomi Dennis — Fri, 06 Dec 2019 15:12:25 +0000

The Liskov substitution principle, is the L in SOLID principles. It was created by Barbara Liskov and states:

Subtypes must be able to substitute base types.

Aside from the obvious implementation of this principle -- ensuring the subtype has the same behavior as the base type -- the implicit implementation is ensuring the subtype has the same semantic behavior as the base type.

Semantic is defined as:

Relating to meaning in language or logic.

And so, we create a definition of what the class name means. Typically, squares and rectangles are defined through their mathematic definition. Mathematically, a square is a shape with four sides in equal lengths. For rectangles, we will be using the definition of a perfect rectangle, meaning a shape where the top and bottom sides have equal lengths and left and right sides have equal lengths.

From this definition, we can conclude that a square's width and height must be the same while a rectangle can have a width different from its height as well as having a width equal to its height.

Let's create classes for these shapes, where we just define the width and height.

We can see that a Square object can easily replace a Rectangle object in a given situation. All Square objects share the same behavior as Rectangle.

However, we can see the semantic difference, when we test #area().

Because a rectangle can have a different height than its width the result of #area() adheres to our semantic definition.

If we replaced Rectangle with Square the test will pass, but the Square object is no longer behaving the way we expect.

Because a square's width and height cannot be different, the Square object breaks our semantic definition. This breaks the Liskov substitute principle.

The easiest way to ensure both Rectangle and Square pass the test, while satisfying LSP, is to remove line 4.

You may be thinking, why not implement a #setWidth() function in Rectangle that can be overwritten in Square? This would cause Square to only share the interface of Rectangle instead of its behavior, making the abstraction unnecessary. By removing line 4, we can satisfy LSP and we can go even further by making width and height private.

In Conclusion

When implementing inheritance, be sure to adhere to the meaning of the class outside of the implementation. This helps the class become more understandable in the grand scheme of the project.

Another technique that helps ensure classes adhere to LSP is design by contract.

Open / Closed Principle

Naomi Dennis — Tue, 26 Nov 2019 15:19:36 +0000

The open closed principle is the O in the SOLID principles. It was created by Bertrand Meyer and states:

Software entities should be open for extension, but closed for modification

Let's dive deeper with an example.

We've been tasked with creating a platform that merges all video streaming sites. The platform will be able to add a platform to its list of platforms, search for a video on all platforms and play a video from the search results. The class can look like so:

CentralVideoStreamingPlatform covers most mainstream video streaming platforms. However, if we were to add another platform, say DisneyPlus, another #add() would be created. This directly violates the open for extension aspect of OCP.CentralVideoStreamingPlatform must be open to accept different details without needing to change code that's already written. By overloading #add() again, we are needlessly changing CentralVideoStreamingPlatform. Who's to say how many #add() CentralVideoStreamingPlatform would have as more streaming platforms are added?

To ensure CentralVideoStreamingPlatform's extensibility, we can refactor the video streaming classes to implement a VideoStreamingPlatform interface and use one #add().

In Conclusion

The open closed principle is a great principle to keep in mind when writing classes.

Single Responsibility Principle

Naomi Dennis — Thu, 21 Nov 2019 11:42:07 +0000

The first concept in SOLID principles is the single responsibility principle. According to Robert Martin's Agile Software Development: Principles, Patterns and Practices, it is defined as:

A class should have only one reason to change

The definition is simple enough, but let's look at an example to really solidify its meaning.

Despite the class looking relatively simple, there is actually a lot going on. Game controls how the board is rendered, how the player's turn is carried out, if a winner is found and the main game loop. If the way the board is rendered changes, #renderBoard() will have to change. If the rules of the game changes how a player should conduct their turn, #playerTurn() and possibly #detectWinner() will have to change. If we decided to create a more complicated game, where an Ai or some other high level action has to happen, #start() would have to change.

The easiest way to separate responsibility is to separate the functions into classes depending how on they change in respect to one another. #renderBoard() can be separated into its own class, because changing how the board is rendered doesn't necessitate changing the game's loop or the game's rules. It only cares about the medium the board is rendered on; for example, a phone app or command line. #playerTurn() and #detectWinner() can be separated from Game, but kept together. The rules of the game dictates how the player conducts their turn and how a player wins. If the rules of the game changes, both #detectWinner() and #playerTurn() changes.

With these changes, the only behavior left in Game is the main game loop.

In Conclusion

When determining how to separate responsibility, look for what Robert Martin calls, "an axis of change". For example, if #detectWinner() and #startPlayerTurn() behavior weren't related, we could segregate #detectWinner() into its own class. However, for our example, this is unnecessary. Be sure not to introduce needless complexity.

Dependency Inversion Principle

Naomi Dennis — Mon, 18 Nov 2019 16:20:07 +0000

The last SOLID rule is the dependency inversion principle. According to Robert Martin's Agile Software Development: Principles, Patterns and Practices, the principle is defined as,

1) High level modules shall not depend on low-level modules. Both shall depend on abstractions.

2) Abstractions shall not depend on details. Details shall depend on abstraction

This is a lot, so let's look at each rule separately.

High Level Modules Shall not Depend on Low-Level Modules

Let's look at a very simple Java example:

In this example, Monitor is dependent on DisplayPortCable and DisplayPortCable is dependent on Laptop. If Monitor wants to use a different cord, say an HDMI or VGA cord, we will be forced to change Monitor directly. We could give Monitor multiple constructors for each cord type; we could also create a base class that holds the behavior for all the cords. However, these approaches aren't desirable as it leaves the class rigid and cumbersome to expand and it could become bloated. A base class may seem like a good idea, but it's too tempting to add behavior for all the cords in one place and simply extend it to the newly created classes. This bloat tends to break the interface segregation principle. The same holds true for the relationship between DisplayPortCable and Laptop.

In statically typed languages like Java, it's best to invert the dependency using an interface (or virtual classes in C++). Interfaces allows us to define a low level type for our higher level classes (like Monitor) to use.

Inverting a Dependency

When inverting a dependency, we want the classes that are being depended on (in our example DisplayPortCable and Laptop) to instead, depend on an interface. Continuing with our example, the relationship between DisplayPortCable and Monitor looks like so:

From the example, we create an interface for VideoCable and implement the cable we plan on using for Monitor. Instead of Monitor being restricted to accepting DisplayPortCable it can now accept any VideoCable.

There is still a dependency in our code because VideoCable is dependent on Laptop. This helps brings us to the next part of this principle.

Abstractions Shall not Depend on Details. Details Shall Depend on Abstraction

When thinking about the details of a class, I like to think that details mean the behavior and properties of a class. In our example, this means #connect() and #connectedDevice. Although our DisplayPortCable is abstracted, it's still dependent on Laptop. The question we ask is the same that we asked before. What if a VideoCable wanted to connect to a Desktop or a Smartphone instead of a Laptop?

And so, we invert the dependency like we did before.

Dynamic vs Static Approaches to Dependency Inversion

The example above was done in Java. Statically typed languages usually have a concrete way of defining abstract interfaces. However, in dynamically typed languages, the idea of an abstract class is harder to implement as the tools to do so are not typically a feature of the language. In cases like this, we can use a technique known as duck typing.

Duck typing is the idea, that if the behavior of a class walks in a particular way, and talks in a particular way, that way can be abstracted to the dependent classes.

The difference between an interface-esque keyword approach to dependency inversion and duck typing, is the former is written in contract form where the behavior is explicitly defined and enforced; the latter is not explicitly defined and becomes apparent as more object types are used within a class. If we were to convert our above code to Ruby, duck typing wouldn't be obvious because there's only one object type depending on an abstraction.

The issue becomes more apparent as we add more classes.

Since there isn't a defined contract, we could use any old interface with our new classes and simply ask for the type of videoConnector and use whatever interface was defined. However, this not only makes Monitor difficult to extend (since we'd have to manually add a new conditional to understand a new type), but it leads Monitor to know about the inner workings of other classes which directly violates this principle. Monitor has to depend on an abstraction of the object it's receiving. Monitor shouldn't care about the object's class, just its behavior.

To do this, we have to consciously ensure the classes have an agreed upon interface and that they depend on this interface. In the case of our example, we have to dictate if #connectToDevice() will expect videoConnector to have the #connect() or #connectToSomething() behavior.

In Conclusion

Dependency inversion can be tricky. However, it allows a class to be more flexible and trains us to think about classes in terms of behavior, rather than construction.

Introduction to the Interface Segregation Principle

Naomi Dennis — Fri, 15 Nov 2019 19:33:06 +0000

The interface segregation principle is the I in SOLID principles. According Robert Martin's Agile Software Development: Principles, Patterns and Practices, the principle is defined as, “Clients should not be forced to depend on methods that they do not use.” In other words, classes should not have access to behavior it does not use. Let’s look at a Python example.

We’ve been hired to create a game where the player sets up entertainment systems. Each piece of the system (television, dvd player, game console, etc.) uses a specific cord to connect to another device. We know that a TV uses an HDMI cord to connect to a game console, and a dvd player uses RCA cords to connect to a TV. Both the game console and TV connects to a router via an ethernet cord so they can access the internet. And lastly, all the devices are connected to the wall via a power cord so they can turn on.

Say we create a class to handle all the connections listed above.

class EntertainmentDevice:
  def _connectToDeviceViaHDMICord(self, device): None
  def _connectToDeviceViaRCACord(self, device): None
  def _connectToDeviceViaEthernetCord(self, device): None 
  def _connectDeviceToPowerOutlet(self, device): None

Now, all we have to do is extend this interface to our device classes.

class Television(EntertainmentDevice):
  def connectToDVD(self, dvdPlayer):
    self._connectToDeviceViaRCACord(dvdPlayer)

  def connectToGameConsole(self, gameConsole):
    self._connectToDeviceViaHDMICord(gameConsole)

  def plugInPower(self): 
    self._connectDeviceToPowerOutlet(self)


class DvdPlayer(EntertainmentDevice):
  def connectToTV(self, television):
    self._connectToDeviceViaHDMICord(television)

  def plugInPower(self):
    self._connectDeviceToPowerOutlet(self) 


class GameConsole(EntertainmentDevice):
  def connectToTV(self, television):
    self._connectToDeviceViaHDMICord(television)

  def connectToRouter(self, router):
    self._connectToDeviceViaEthernetCord(router)

  def plugInPower(self):
    self._connectDeviceToPowerOutlet(self)


class Router(EntertainmentDevice):
  def connectToTV(self, television):
    self._connectToDeviceViaEthernetCord(television)

  def connectToGameConsole(self, gameConsole):
    self._connectToDeviceViaEthernetCord(gameConsole)

  def plugInPower(self):
    self._connectDeviceToPowerOutlet(self)

Looking at each class, you’ll notice that every class only uses a method or two from EntertainmentSystemDevice. For instance, DVDPlayer only uses #connectToTV and #connectToPowerOutlet methods. There’s also a bit of duplication across the classes. Each class uses #connectToPowerOutlet. First, let’s work on separating the EntertainmentSystemDevice interface.

We can extract #connectToDeviceViaEthernetCord and create a class dedicated to internet devices.

class InternetDevice: 
  def _connectToDeviceViaEthernetCord(self, device): None

Both HDMI and RCA cords are used for transmitting audio and video data. The difference between the two, is RCA handles analog signals, while HDMI handles digital signals. We can use this difference to create two classes, AnalogDevice, and DigitalDevice that handles devices connected by RCA and HDMI respectively.

class AnalogDevice:
  def _connectToDeviceViaRCACord(self, device): None 

class DigitalDevice:
  def _connectToDeviceViaHDMICord(self, device): None

Our EntertainmentSystemDevice class now only has the #connectToPowerOutlet method. Because it only handles behavior for connecting a device to an outlet, the class name should change to reflect that. We can also define a #plugInPower method that uses the #connectDeviceToPowerOutlet method. Let’s rename EntertainmentSystemDevice to WallPoweredDevice.

class WallPoweredDevice: 
  def plugInPower(self, device):
    self.__connectToDeviceViaPowerOutlet(device)

  def __connectToDeviceViaPowerOutlet(self, device): None

Our classes are looking pretty good.

class Television(WallPoweredDevice, InternetDevice, AnalogDevice, DigitalDevice):
  def connectToDVD(self, dvdPlayer):
    self._connectToDeviceViaRCACord(dvdPlayer)

  def connectToGameConsole(self, gameConsole):
    self._connectToDeviceViaHDMICord(gameConsole)

  def connectToRouter(self):
    self._connectToDeviceViaEthernetCord(self)


class DvdPlayer(WallPoweredDevice, AnalogDevice):
  def connectToTV(self, television):
    self._connectToDeviceViaRCACord(television)


class GameConsole(WallPoweredDevice, InternetDevice, DigitalDevice):
  def connectToTV(self, television):
    self._connectToDeviceViaHDMICord(television)

  def connectToRouter(self):
    self._connectToDeviceViaEthernetCord(self)


class Router(WallPoweredDevice, InternetDevice):
  def connectToTV(self, television):
    self._connectToDeviceViaEthernetCord(television)

  def connectToGameConsole(self, gameConsole):
    self._connectToDeviceViaEthernetCord(gameConsole)

In the end, we were able to refactor our device interfaces to only have access to behavior it uses. Because the behavior is separated based on the sole behavior the class supports, the extended classes act as a description of the subclass. For example, we know that a router uses the internet and needs to be plugged into the wall without having to look at the inner functionality of the class.

We can take this idea one step further and say, classes should only use objects where it uses the entire interface of said object. This is a bit difficult to show in a dynamically typed language like Python, so we will convert our Router class to Java and convert our InternetDevice class to a Java interface.

interface InternetDevice{
  public void connectToDeviceViaEthernetCord(InternetDevice device); 
}

class Router extends WallPoweredDevice implements InternetDevice{
    public void connectToDeviceViaEthernetCord(InternetDevice device){}
}

In this example, Router can only connect to another device that uses the internet. Because we want it to only have access to behavior associated with an InternetDevice, we tell it to only understand objects that use the InternetDevice interface.

This way, even if we implement an InternetDevice to other classes like Television or GameConsole, Router's #connectToDeviceViaEthernetCord will only have access to the functions associated with InternetDevice.

To learn more about Java interfaces, follow the link here.

When adding additional features to the program, such as connecting to the internet not only via ethernet, but also via Wi-Fi, be sure to pay attention to the cohesion of the methods. How well do the methods relate to each other? If a class were given the set of behavior defined in the base class or acknowledged in an interface, would the class actually need the behavior? By answering these questions we are able to create reusable, general classes that are easier to delegate.

Gists: