Kotlin Code Smell 24 - Tackling Too Many Attributes
Trimming the Attribute Fat

I've started to work as a software engineer at 2014, however, I started to write code at high-school.
My first language was Assembly, but still, I fall in love with the possibilities to make the computer to do as you wish, shortly after that I started to write in C.
Later on I studied a practical engineering in electricity, and during this time discovered that I preferred much more writing code than design electrical components.
As a result of this understanding I decided to switch and study bachelor degree in computer science in Reichman university, where the focus was of the Java language.
Today I'm working at SumUp using Kotlin, SpringBoot & Micronaut, Cassandra and Kafka
Problem
Low Cohesion
Coupling
Maintainability
Readability
Solution
Identify methods related to specific groups of attributes.
Cluster these methods together.
Break down the original class into smaller, more focused objects based on these clusters.
Replace existing references with new objects.
Examples
- DTOs
- Denormalized table rows
Sample Code
Wrong
class ExcelSheet (
val filename: String,
val fileEncoding: String,
val documentOwner: String,
val documentReadPassword: String,
val documentWritePassword: String,
val creationTime: LocalDateTime,
val updateTime: LocalDateTime,
val revisionVersion: String,
val revisionOwner: String,
val previousVersions: List<String>,
val documentLanguage: String,
val cells: List<Cell>,
val cellNames: List<String>,
val geometricShapes: List<Shape>,
)
Right
class ExcelSheet (
val fileProperties: FileProperties,
val securityProperties: SecurityProperties,
val datingProperties: DocumentDatingProperties,
val revisionProperties: RevisionProperties,
val languageProperties: LanguageProperties,
val content: DocumentContent,
)
// The object now has fewer attributes, resulting in improved
// testability.
// The new objects are more cohesive, more testable, and lead to fewer
// conflicts, making them more reusable. Both FileProperties and
// SecurityProperties can be reused for other documents. Additionally,
// rules and preconditions previously found in fileProperties will be
// relocated to this object, resulting in a cleaner ExcelSheet
// constructor.
Conclusion
Bloated objects know too much and are very difficult to change due to cohesion.
Developers change these objects a lot, so they bring merge conflicts and are a common problem source.




