Is there an accepted name for what it's called when someone takes are relative small codebase and splits it up into many tiny libraries, containing just a few or even just a single class, or likewise splitting up a single coherent class into multiple smaller classes that depend on each other.
During my travels, I've twice come across projects that have been atomized in this way, where a single application contains 25+ tiny projects with a complex dependency graph, that all rolls into one application which compiles into less than a single MB of code while running on dedicated servers with hundreds of GB of storage available.
I am looking to discuss this pattern of coding with the other developers, but I am lacking knowledge about established vocabulary on this subject.
Can anyone suggest what this pattern (or anti-pattern) is called, and under which cases you may want to employ it, since I'm moderately certain that is has been employed to an extreme in the wrong context
Edit: The core behaviour I'm investigating is the practice of migrating a coherent and single purpose codebase into multiple ultra-skinny library-projects with low-cohesion that are still tightly coupled with the rest of the original codebase.
While the code now compiles into an executable and 11 dlls, none of those dlls are possible to reuse independently. They have so many cross references that one of these libraries is just a collection of interfaces to break cyclic dependencies to allow the solution to compile at all.
Second edit Promoted from a comment to one of the answers given:
I mean splitting, as in being moved to a separate project and compiled into a .dll file, in this case I have the main executable. This uses a class in .dll A, .dll A is implementing an interface that are defined in .dll B, as well as interacting with 2 other interfaces defined in B. The 2 other interfaces used, are defined in .dll file C and .dll file D, which in turn are also reliant on B. Neither A, B, C or D are used anywhere outside of the main executable, and there is no past, current or future requirement to be able to have multiple different implementations of A, C or D