26 lines
1.7 KiB
Plaintext
26 lines
1.7 KiB
Plaintext
![]() |
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.
|
||
|
|
||
|
== 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.
|
||
|
|