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

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



  1. Decouple essential business logic from accidental persistence

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


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


public class Person {
  int childrenCount; 

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


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


[X] Semi-Automatic

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


  • Coupling


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

More Info


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.