# Code Smell 31 - Accidental Methods on Business Objects

*Adding persistence, serialization, displaying, importing, exporting code to an object bloats its protocol and brings coupling.*

# Problems

- Readability

- Coupling

- Maintainability

# Solutions

1. Keep your objects clean.

2. Decouple business objects.

3. Separate accidental concerns: Move Persistence, Formatting, Serialization to special objects.

4. Keep essential protocol using [bijection](https://maximilianocontieri.com/the-one-and-only-software-design-principle).

# Examples

- Persistence

- Identifiers

- Serialization

- Formatting

# Sample Code

## Wrong

%[https://gist.github.com/mcsee/11c5f7da7d9c54a05456102e128d010d]

## Right

%[https://gist.github.com/mcsee/47847ea77875bb6f6e5e1cba2e914b05]

# Detection

It is difficult (but not impossible) to create linting rules based on naming and hinting for suspect names.

# Exceptions

- Some frameworks force us to inject dirty code in our objects. (For example identifiers).

We should try to use better languages/frameworks.

# Tags

- Declarative

# Conclusion

We are very used to see business objects polluted. This is normal. We need to reflect on the consequences and coupling from these designs.


# Credits

Photo by <a href="https://unsplash.com/@robertbye">Robert Bye</a> on <a href="https://unsplash.com/s/photos/mess">Unsplash</a></span>

* * *

> Simple things should be simple, complex things should be possible.

Alan Kay

%[https://mcsee.hashnode.dev/software-engineering-great-quotes]

* * *

This article is part of the CodeSmell Series.

%[https://mcsee.hashnode.dev/how-to-find-the-stinky-parts-of-your-code]