Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

ghabriel25's avatar

Fat service class

Please give your honest review about my service class. This class only called from model observer, wrapped within database transaction and handle

  • creating and deleting user activities
  • deleting notifications related to activities
Model Type Softdelete
UserActivity Polymorphic ✔️
Notification Polymorphic

Trying to consolidate it with dedicated class but dont know where to start, which part should be refactor.

1 like
2 replies
vincent15000's avatar

I'm not used to write so fat classes.

In this case, you could for example export the private functions in a trait and use this trait in the ActivityService class.

And if you want, you can even create several traits and group the private functions together according to the business logic.

A trait is usually used to be reused in several classes, but in this case it would only be a way to get a more readable code.

imrandevbd's avatar

I have to respectfully disagree with the suggestion to use traits here. Moving code into traits just to make a file shorter is an anti-pattern it sweeps the mess under the rug but doesn't fix the underlying architectural issue.

Right now, your ActivityService is turning into a God Class because it violates the Single Responsibility Principle. It's handling activity creation, activity deletion, and notification management across multiple distinct domain

Please or to participate in this conversation.