Оффлайн
- Регистрация
- 1 Мар 2015
- Сообщения
- 1,481
- Баллы
- 155
In software design, a God Object (or God Class) is a class that knows too much or does too much. It's a common code smell that tends to emerge as a system evolves without proper boundaries.
What Is a God Object?
A God Object violates the Single Responsibility Principle by taking on multiple responsibilities. It typically centralizes control and knowledge of many parts of a system—handling tasks that should be delegated to other specialized components.
Why Do We Create Them?
Even experienced developers can fall into this trap, usually due to:
Let’s say you're building a food delivery service and start with a class like this:
class DeliveryManager:
def assign_driver(self, order): ...
def calculate_fee(self, order): ...
def notify_customer(self, order): ...
def refund_order(self, order): ...
def log_event(self, event): ...
Over time, DeliveryManager becomes a dumping ground for unrelated concerns: logistics, billing, notifications, logging, and more.
Refactoring the God Object
To fix this, you’d separate concerns into smaller, focused classes:
class DriverAssigner:
def assign(self, order): ...
class FeeCalculator:
def calculate(self, order): ...
class CustomerNotifier:
def notify(self, order): ...
class PaymentProcessor:
def refund(self, order): ...
class EventLogger:
def log(self, event): ...
Now, a high-level class can orchestrate these responsibilities without owning the details:
class DeliveryService:
def __init__(self, assigner, calculator, notifier, processor, logger):
self.assigner = assigner
self.calculator = calculator
self.notifier = notifier
self.processor = processor
self.logger = logger
def process_order(self, order):
self.assigner.assign(order)
fee = self.calculator.calculate(order)
self.notifier.notify(order)
self.logger.log(f"Order processed with fee {fee}")
When a God Object Might Be Acceptable
There are rare scenarios where a centralized object is acceptable:
But even then, use them with clear documentation and a plan to refactor if the scope grows.
Why You Should Avoid God Objects
The God Object is an easy pitfall that feels efficient—until it isn’t. Build smaller, focused classes and let them work together. Clear boundaries make your codebase easier to maintain, test, and scale.
Think of it this way: A chef doesn’t build the kitchen, grow the vegetables, and drive the delivery van. Your code shouldn’t either.
Happy Designing!.
What Is a God Object?
A God Object violates the Single Responsibility Principle by taking on multiple responsibilities. It typically centralizes control and knowledge of many parts of a system—handling tasks that should be delegated to other specialized components.
Why Do We Create Them?
Even experienced developers can fall into this trap, usually due to:
- Moving fast: Prioritizing speed over modularity in early stages.
- Avoiding perceived complexity: Putting logic in one place “for convenience.”
- Fear of breaking things: As the class grows, refactoring becomes scarier.
- Lack of clear ownership boundaries: Developers aren't sure where logic belongs.
Let’s say you're building a food delivery service and start with a class like this:
class DeliveryManager:
def assign_driver(self, order): ...
def calculate_fee(self, order): ...
def notify_customer(self, order): ...
def refund_order(self, order): ...
def log_event(self, event): ...
Over time, DeliveryManager becomes a dumping ground for unrelated concerns: logistics, billing, notifications, logging, and more.
Refactoring the God Object
To fix this, you’d separate concerns into smaller, focused classes:
class DriverAssigner:
def assign(self, order): ...
class FeeCalculator:
def calculate(self, order): ...
class CustomerNotifier:
def notify(self, order): ...
class PaymentProcessor:
def refund(self, order): ...
class EventLogger:
def log(self, event): ...
Now, a high-level class can orchestrate these responsibilities without owning the details:
class DeliveryService:
def __init__(self, assigner, calculator, notifier, processor, logger):
self.assigner = assigner
self.calculator = calculator
self.notifier = notifier
self.processor = processor
self.logger = logger
def process_order(self, order):
self.assigner.assign(order)
fee = self.calculator.calculate(order)
self.notifier.notify(order)
self.logger.log(f"Order processed with fee {fee}")
When a God Object Might Be Acceptable
There are rare scenarios where a centralized object is acceptable:
- Prototypes or scripts: When you’re experimenting or working solo.
- Game engines: A “world” object sometimes needs to hold global state.
- Tiny microservices: If there’s only one job to do and no team dependency.
But even then, use them with clear documentation and a plan to refactor if the scope grows.
Why You Should Avoid God Objects
- Hard to test: Everything depends on everything.
- Poor readability: New developers won’t know where to look or change.
- Risky changes: One bug fix might introduce five new ones.
- Team bottlenecks: Everyone needs to modify the same big class.
The God Object is an easy pitfall that feels efficient—until it isn’t. Build smaller, focused classes and let them work together. Clear boundaries make your codebase easier to maintain, test, and scale.
Think of it this way: A chef doesn’t build the kitchen, grow the vegetables, and drive the delivery van. Your code shouldn’t either.
Happy Designing!.