Code Smell 142 - Queries in Constructors

Photo by Callum Hill on Unsplash

Code Smell 142 - Queries in Constructors

Accessing a database in domain objects is a code smell. Doing it in a constructor is a double smell

Maxi Contieri
·Jun 20, 2022·

2 min read

Subscribe to my newsletter and never miss my upcoming articles

Play this article

Table of contents

  • Problems
  • Solutions
  • Context
  • Sample Code
  • Detection
  • Tags
  • Conclusion
  • More Info
  • Credits

TL;DR: Constructors should construct (and probably initialize) objects.

Problems

Solutions

  1. Decouple essential business logic from accidental persistence

  2. On persistence classes, run queries in functions other than constructors/destructors

Context

On legacy code, the database is not correctly separated from business objects.

Constructors should never have side effects.

According to the single responsibility principle, they should only build valid objects

Sample Code

Wrong

public class Person {
  int childrenCount; 

  public Person(int id) {
    childrenCount = database.sqlCall("SELECT COUNT(CHILDREN) FROM PERSON WHERE ID = " . id); 
  }
}

Right

public class Person {
  int childrenCount; 

  // Create a class constructor for the Main class
  public Person(int id, int childrenCount) {
    childrenCount = childrenCount; 
    // We can assign the number in the constructor
    // Accidental Database is decoupled
    // We can test the object
  }
}

Detection

[X] Semi-Automatic

Our linters can find SQL patterns on constructors and warn us.

Tags

  • Coupling

Conclusion

Separation of concerns is key and coupling is our main enemy when designing robust software.

More Info

Credits

Photo by Callum Hill on Unsplash


My belief is still, if you get the data structures and their invariants right, most of the code will kind of write itself.

Peter Deustch


This article is part of the CodeSmell Series.

 
Share this