This content originally appeared on DEV Community and was authored by Maxi Contieri
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.
Problems
Side Effects
Solutions
Decouple essential business logic from accidental persistence
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 linterns 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.
This content originally appeared on DEV Community and was authored by Maxi Contieri
Maxi Contieri | Sciencx (2022-06-20T13:30:29+00:00) Code Smell 142 – Queries in Constructors. Retrieved from https://www.scien.cx/2022/06/20/code-smell-142-queries-in-constructors/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.