Non-parameterized constructors are a code smell of an invalid object that will dangerously mutate. Incomplete objects cause lots of issues.
\ Refactorings ⚙️
https://hackernoon.com/refactoring-remove-setters-codesmell?embedable=true
https://hackernoon.com/refactoring-016-building-with-the-essence?embedable=true
class AirTicket { constructor() { } }
class AirTicket { constructor(origin, destination, arline, departureTime, passenger) { // ... } }
Any linter can warn about this (possible) situation.
[X] Beginner
In the MAPPER, objects correspond to real-world entities.
\ Real people aren't born nameless and formless, then gradually acquire attributes.
\ You don't meet someone who temporarily has no age or email address.
\ When you model a person, you should capture their essential attributes at birth, just like reality.
\ Breaking this bijection by creating hollow objects forces you to represent impossible states.
\ Empty constructors create phantom and invalid objects that don't exist in your domain model, violating the mapping between your code and reality.
AI code generators frequently produce this smell because they often follow common ORM patterns.
\ When you prompt AI to "create a Person class," it typically generates empty constructors with getters and setters.
\ AI tools trained on legacy codebases inherit these patterns and propagate them unless you explicitly request immutable objects with required constructor parameters.
AI tools can detect and fix this smell when you provide clear instructions.
\ You need to specify that objects should be immutable with required constructor parameters.
\ Without explicit guidance, AI tools may not recognize empty constructors as problematic since they appear frequently in training data.
Remember: AI Assistants make lots of mistakes
Always create complete objects. Make their essence immutable to endure through time.
\ Every object needs its essence to be a valid one since its inception.
\ We should read Plato's ideas about immutability and create entities in a complete and immutable way.
\ These immutable objects favor bijection and survive the passing of time.
https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd
https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-vi-cmj31om
https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-viii-8mn3352
https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-ii-o96s3wl4?embedable=true
https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxiv
https://hackernoon.com/is-it-crystal-clear-for-everybody-that-a-date-should-not-mutate-wuoy3z03?embedable=true
https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-ii-o96s3wl4?embedable=true
Photo by Brett Jordan in Pexels
Joel Spolski
https://hackernoon.com/400-thought-provoking-software-engineering-quotes?embedable=true
This article is part of the CodeSmell Series.
https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd
\


