Local Butterfly is a structural anti-pattern for a component with many immediate dependents.
The scope of dependents is limited to immediate dependents that directly access, use, reference, or contain the Local Butterfly.

These issues arise from the tight coupling between the component and its dependents, which can lead to a lack of flexibility, maintainability, and scalability in the system.

== Why is this an issue?

Any changes or modifications to the component with a large number of immediate dependents may require updates in multiple places.
This can make it challenging to introduce new features or make changes without impacting the entire system.
The lack of flexibility can hinder adapting to evolving requirements or business needs.

The tight coupling between the component and its immediate dependents can make the codebase more complex and harder to understand.
This can lead to difficulties in maintaining and debugging the system.
When a change is required, it may be challenging to identify all the affected areas, increasing the risk of introducing bugs or unintended side effects.

As the number of immediate dependents increases, the component's scalability can be compromised.

Only basic Interfaces or utility classes should be allowed to become Local Butterflies.

=== Exceptions

* The rule ignores simple components (class/record/interface). Simple components are less subject to being changed, so
  the likelihood of breaking a lot of other places is reduced. The rule considers a component simple when the number
  of "public field count + public method count + public method parameter count" <= 10. And `Object` methods `equals`,
  `hashCode`, `toString` and `compareTo` are ignored in the computation.
* The rule has a different threshold for "data classes", classes with only public constructors/getters/setters/fields,
  and a maximum of one other public method (ignoring `equals`, `hashCode`, `toString` and `compareTo`). In this case,
  the threshold is doubled.

== How to fix it

To mitigate these issues, it is recommended to consider alternative design patterns that promote loose coupling and separation of concerns.
By decoupling the component from its immediate dependents, such as using interfaces or abstractions, it becomes easier to modify, maintain, and test the system.
This promotes better flexibility, maintainability, and scalability in the long run.

