A team breaks a 3,000-line god class into several files using C# partial classes, Ruby class reopening or Objective-C categories, without moving a single member out of the type. Has cohesion improved? Explain what each mechanism actually changes.

## The claim under test "We split the god class into six files, so it is now cohesive." This confuses two different things: the *presentation* of a type (how its source is laid out for readers and version control) and its *structure* (which members exist, which state they share, and which reasons cause them to change). Cohesion is structural. A common operationalisation is to look at the class's fields and ask, for each pair of methods, whether they touch any field in common. A god class is one where that relation partitions into several disjoint clusters - a group of methods around the persistence fields, another around the formatting fields, another around the cache fields. Those clusters are the classes that want to exist. None of the three mechanisms in the question touches a single edge in that graph. ## What each mechanism really does **C# partial classes.** The compiler concatenates the parts before doing anything else; there is exactly one type in the assembly, with one field list and one member list. The feature was introduced for a specific and legitimate reason: keeping designer- or tool-generated members out of the file a human edits, so regeneration never clobbers hand-written code. That is a split by *origin*, and it genuinely reduces merge conflicts. It does not reduce responsibilities. A reviewer opening one part cannot see whether a method in another part also writes the field being modified - so the split can actively make the coupling harder to see. **Ruby class reopening.** Ruby classes are open at runtime: any file, at any point during load, can reopen `class Invoice` and add or replace methods. Splitting a class this way changes the nature of the problem rather than its size. The member set is no longer knowable from any one place, it depends on which files were required and in what order, and a later definition silently replaces an earlier one with the same name. Python's equivalent (assigning to a class attribute after definition) and JavaScript's prototype assignment have the same character. A design that was merely too big becomes one whose shape cannot be determined statically - the cohesion question becomes unanswerable, which is not the same as answered well. **Objective-C categories.** A category adds methods to an existing class from another file, and crucially from another compiled library. If two categories define the same selector, the winner is whichever loads last, and the runtime emits no diagnostic. This is why Apple's guidance is to prefix category method names. Swift inherited the idea as extensions and hardened it: extensions within a module are a fine organisational tool, but adding a *protocol conformance* to a type you do not own, for a protocol you do not own, is global by nature. Two modules doing it produce a link-time coin flip, so Swift now asks you to write `@retroactive` to say you accept the risk. **Rust as the contrast.** Rust lets you write as many `impl` blocks for a type as you like, in as many files as you like inside the crate. But the orphan rule refuses `impl SomeoneElsesTrait for SomeoneElsesType`, guaranteeing that for any (trait, type) pair the whole program has exactly one implementation - coherence. The price is newtype wrappers when you genuinely need the missing combination. The design point is that a code-organisation feature and a global-extension feature are different features, and the languages that conflated them pay for it with collisions. ## Where the split *is* useful Generated versus hand-written code, platform-specific parts of one type, and test-only additions in a language where that is safe. All of these are splits along an axis other than responsibility, and none is claimed to improve cohesion. It is also legitimate as a *transitional* step: split by cluster into parts, verify that each part touches a disjoint set of fields, then promote each part into a real collaborator. The mistake is stopping at step one and declaring victory. ## The verdict to give in an interview Cohesion is unchanged; readability of a single file improved; in Ruby and Objective-C, coupling got worse because the type became open to definition from places it never names. The real fix is to extract the field cluster along with the methods that touch it into a new type the original delegates to - after which the original's remaining methods share state again and the metric moves for a reason.