Ответ
God Object нарушает Принцип единственной ответственности (Single Responsibility Principle, SRP).
Почему это нарушение: SRP гласит, что класс должен иметь только одну причину для изменения. God Object концентрирует множество несвязанных функций, что приводит к:
- Высокой связанности (coupling).
- Сложности тестирования и поддержки.
- Хрупкости — изменение в одной области может сломать другие.
Пример God Object (нарушение SRP):
// Нарушение: Класс делает слишком много.
class OrderManager {
public void saveOrder(Order o) { /* ... */ }
public void calculateTax(Order o) { /* ... */ }
public void generateInvoice(Order o) { /* ... */ }
public void sendEmailNotification(Order o) { /* ... */ }
public void updateInventory(Order o) { /* ... */ }
}Решение (следование SRP):
// Каждый класс отвечает за одну задачу.
class OrderRepository { void save(Order o) { /* ... */ } }
class TaxCalculator { void calculate(Order o) { /* ... */ } }
class InvoiceGenerator { void generate(Order o) { /* ... */ } }
class NotificationService { void sendEmail(Order o) { /* ... */ } }
class InventoryService { void update(Order o) { /* ... */ } }Ответ 18+ 🔞
Ах ты ж ёпта, ну и намудрили же, блядь! Смотри-ка, есть у нас такая штука — God Object. Это не бог в прямом смысле, а скорее такой программистский идол, которого все боятся, потому что он нихуя не делает хорошо, зато делает всё сразу.
Вот представь себе, блядь, есть у тебя один класс. И он, сука, как тот универсальный солдат: и заказы сохраняет, и налоги считает, и счета выписывает, и письма шлёт, и склад обновляет. Во все дыры давалка, одним словом. А по науке-то, по этим вашим принципам SOLID, так нельзя! Первый же принцип, SRP, орет на всё горло: «Класс должен иметь одну, блядь, причину для изменения! ОДНУ!»
А тут у него причин для изменения — овердохуища. Захотел бухгалтер поменять формулу налога — трогай этот класс. Захотел маркетолог поменять шаблон письма — опять лезь в него. Системщик складскую логику поменял — и снова ты тут, в этом же файле ковыряешься. Один косяк в одном месте — и всё, пиздец, полетело остальное, что, казалось бы, вообще не связано. Связанность, блядь, высоченная! Протестировать эту хуйню — вообще отдельный ад, потому что он везде и сразу.
Смотри, как это выглядит в коде, просто пиздец:
// Нарушение: Класс делает слишком много.
class OrderManager {
public void saveOrder(Order o) { /* ... */ }
public void calculateTax(Order o) { /* ... */ }
public void generateInvoice(Order o) { /* ... */ }
public void sendEmailNotification(Order o) { /* ... */ }
public void updateInventory(Order o) { /* ... */ }
}Видишь? OrderManager. А по факту — OrderGodAlmightyDoEverythingAndThenSomeManager. Чистая хитрая жопа, которая рано или поздно тебе так впендюрит, что мало не покажется.
А как надо-то, спрашиваешь? Да элементарно, Ватсон! Разделяем эту манду с ушами на нормальные, вменяемые сервисы. Каждый пусть себе спокойно отвечает за свою одну, ебать, задачу. И живут они отдельно, и меняются независимо. Красота!
// Каждый класс отвечает за одну задачу.
class OrderRepository { void save(Order o) { /* ... */ } }
class TaxCalculator { void calculate(Order o) { /* ... */ } }
class InvoiceGenerator { void generate(Order o) { /* ... */ } }
class NotificationService { void sendEmail(Order o) { /* ... */ } }
class InventoryService { void update(Order o) { /* ... */ } }Вот так-то, блядь. Никакого бога, просто несколько трудяг, каждый на своём месте. И тестировать легко, и менять не страшно. А то создашь такого монстра — и потом сам от себя охуеешь, когда через полгода придётся в этот код лезть.