The Principle of Least Knowledge in Software Development

One of the most import software design principles is the Principle of Least Knowledge, also known as The law of Demeter. It is also called the Law of Demeter for Functions/Methods (LoD-F). The Principle of Least Knowledge concerns loose coupling, in that your code or your class depends on the least number of other classes in order to function.

This principle focuses on modularity, whereas, you are more able to remove or change your code without negatively impacting the project as a whole or breaking the system. Keeping a minimal amount of dependencies allows us to refactor or update code in the future without impacting other classes. This also leads to more scalable, more readable code because with minimal dependencies, you don’t have to look in many places to be sure of where certain methods, properties, parameters or arguments data is coming from. Additionally, it keeps your code safer by minimizing the risk posed by third party dependencies such as libraries made by other developers outside your organization.

In example, say you had a class that allowed you to locate the IP address for the user. You could use a third party class to do so, which may pose a risk because the third party class may not have great security over time, or the third party class may be updated and cause your implementation method to no longer work, therefore causing the URL location to not be populated. This may even cause an outage or errors to display for the user. Creating your own way to locate an IP within your class may be optimal so that you don’t have more dependencies than you actually need. You can therefore update, change or delete your class at any time without impacting other code in your project or the system overall (assuming no other classes depend on your method that populates the IP location tool). Below are a couple of examples in Java.

Using dependency (not using the Principle of Least Knowledge):

Notice: The ThirdPartyIPLocator could be changed or updated by the developers. This would render “OtherClass” to no longer work because it depends on ThirdPartyIPLocator working.

import java.util.*

public class IPLocator {

private ThirdPartyIPLocator ipLocator;

public ThirdPartyIPLocationDatabase() throws IOException {

File database = new File(“your-mmdb-location”);

ipLocator = new ThirdPartyIPLocator.Finder.find();

}

public ThirdPartyLibrary getLocation(String ip) throws GeoIp2Exception {

InetAddress ipAddress = InetAddress.getByName(ip);

CityResponse response = ipLocator.country(ipAddress);

String countryName = response.getCountry().getName();

return new OtherClass(countryName);

}

}

Using Principle of Least Knowledge:

Notice: Minimizing dependencies increases modularity and enables scalability for the program overall. The below class identifies the country for the IP without the use of a third party dependency. The users IP is taken as an argument and rendered within the class.

public class IPLocator {

String UserIP;

public void IPLocator(String UserIP) {

// Code to locate country from user IP

}

}