A codebase has a class holding unrelated helpers - string padding, date arithmetic, a retry loop - grouped only because they had nowhere else to live. Classify that grouping, and explain why the same three functions in Python, Go or Rust would usually not produce a class at all.

## What is being classified Cohesion asks one question about a set of members: *why are these together?* Coincidental cohesion is the weakest answer - "because someone needed a place to put them". Nothing about string padding constrains date arithmetic; changing one can never change the other; and no reader can predict from the name what else is inside. The diagnosis is a property of the *grouping*, and it is language-independent. What is language-dependent, and what interviewers are usually probing, is the **shape** the grouping is forced to take. ## Why the class exists at all in some languages Java requires every declaration to be a member of a type. If you want a reusable function and there is no natural owner for it, the language gives you exactly one move: a class with static members, conventionally made final with a private constructor so nobody instantiates it. That class is a namespace wearing the costume of a type. It has no state, so no invariants; no instances, so no identity; no meaningful subtype. Every OO expectation the keyword `class` sets up is false for it. C# is in the same family and formalises the workaround: `static class` is a compiler-enforced namespace-only type. It then goes further with **extension methods**, which are static methods the compiler lets you call in member position. `s.PadTo(10)` reads as though `String` grew a member. Crucially this is still static dispatch resolved at compile time and scoped by the `using` in effect - it changes where a reader looks for the code, not who owns it. Kotlin permits top-level functions outright. On the JVM the compiler still emits a synthetic file class, so the runtime artefact looks the same as Java's - but the *source* stops pretending there is a type, which is the part that matters for a human classifying the design. ## The same code where free functions are native Python, Go, Rust and C++ never needed the workaround. In Python the natural home is a module: `import dateutils` then `dateutils.add_business_days(...)`. In Go the unit is the package, and the standard library is a lesson in naming those packages for concepts - `strings`, `time`, `errors` - rather than for their role in your build. Rust has free functions in modules with `pub` controlling reach. This is why a Go `util` package is criticised in exactly the language Java reviewers use for a `Utils` class: the failure is the same coincidental grouping, just measured at package granularity. The languages differ in the *unit* the smell attaches to, not in whether it is a smell. ## What each choice actually costs - A static-only class costs conceptual honesty: readers must know it is not a real type, and tooling (mocking, subclassing, dependency injection) that works on types does not usefully apply. - A module of free functions costs discoverability: there is no receiver to autocomplete from, so the function is only findable if you already know the module's name. - Extension methods buy discoverability back but bind statically. If the owning type later adds a real member with the same name, the member wins on recompile and behaviour changes silently. ## How to classify a concrete dump Ask, member by member: does this member read or write any state the group shares, and does it change for the same reason as its neighbours? For a helper dump the answer is no on both counts for every pair. Compare that with a class whose methods all touch the same two fields - that group is held together by state, and file layout is irrelevant to the verdict. ## What actually fixes it Moving the helper to the type it is really about (date arithmetic belongs to a date type, or to a small module named for dates), or promoting a genuinely reusable concept into a small named module. The retry loop is not a helper at all - it is a policy object with its own configuration, which is the tell that it was in the wrong bag. Renaming `Utils` to `StringUtils` narrows the bag but does not change the kind of cohesion; splitting by concept does.