Code Smell 60 - Global Classes
Maxi Contieri
Posted on January 31, 2021
Classes are handy. We can call them and invoke them any time. Is this good?
TL;DR: Don't use your classes as a global point of access.
Problems
Coupling
Classes are global unless we use Namespaces.
Name polluting
Static Methods
Static Constants
Singletons
Solutions
Use namespaces, module qualifiers or similar
Avoid namespace polluting, keep the Global names as short as possible.
Class single Responsibility is to create instances.
Sample Code
Wrong
<?
final class StringUtilHelper {
static function reformatYYYYDDMMtoYYYYMMDD($date) {
}
}
class Singleton {
}
final class DatabaseAccessor extends Singleton {
}
Right
<?
namespace Date;
final class DateFormatter {
function reformatYYYYDDMMtoYYYYMMDD(Date $date) {
}
//function is not static since class single responsibility is to create instances and not be a library of utils
}
namespace OracleDatabase;
class DatabaseAccessor {
//Database is not a singleton and it is namespace scoped
}
Detection
We can use almost any linter or create dependency rules searching for bad class references.
Tags
- Globals
Conclusion
We should restrict our classes to small domains and expose just facades to the outside. This greatly reduces coupling.
Relations
Code Smell 18 — Static Functions
Maxi Contieri ・ Nov 6 '20
More info
Coupling: The one and only software design problem
Maxi Contieri ・ Feb 6 '21
Credits
Photo by Alfons Morales on Unsplash
Write shy code — modules that don't reveal anything unnecessary to other modules and that don't rely on other modules' implementations.
Dave Thomas
Software Engineering Great Quotes
Maxi Contieri ・ Dec 28 '20
This article is part of the CodeSmell Series.
Posted on January 31, 2021
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.