0

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

30
  • 2
  • 3
    Sounds like a flavor of Premature Abstraction with a project twist. Jun 17 at 21:01
  • 1
    Terminology for wrong-headed design generally doesn't exist except in the form of meme-like phrases which people invent off-the-cuff as a way of trying to neatly frame some kind of common misguided mindset (For example the phrase Distributed Monolith is the kind of meme which conjures up all the pain of monoliths coupled with all the pain of microservice deployment for anyone who has ever had the misfortune of inheriting any such project) Jun 18 at 6:13
  • 1
    @Grubsnik Software Engineering doesn't really have much of its own terminology, most of the phrases you'll find are simply ordinary English Language words applied within a specific context and need clarifying by the people who use them. You could likely find many terms to describe it, but if you try to use those terms in conversation with other developers they'll just stare blankly at you and either ask you to explain exactly what you mean or just try to guess and interpret for themselves. Jun 18 at 6:58
  • 1
    obviously at least one must compile independently. are they solutions or projects? to me this just seems like a case of a different judgement on how pragmatic it is to follow best practice on a small code base. If you objected to a class being split into two where both shared a single responsibility or no interfaces or something there would be a violation of solid or something more concrete
    – Ewan
    Jun 21 at 12:09

2 Answers 2

1

What you describe could to be traits or mixin based code. These programming techniques try to promote maximal reusability and tend to therefore compartmentalize code in very small modules. Both techniques compose small classes/modules into larger ones using either an inheritance-like mechanisms or composition and inevitably result in complex dependency graphs.

There are family of problems where mixing and traits are very suitable, so it's not necessarily premature modularization.

(Of course, it may also be unrelated to these techniques and simply result of over engineering, or over-ambitions - there is no name for that as far as I know)

(P.S: I've eliminated microservices and serverless architectures from the list of candidates: these use many small components to achieve a high scalability, but none of them is characterized by "splitting a single coherent class into smaller classes").

1
  • This makes some sense. At least it might point to what the original authors were imitating, even if the actual code doesn't have use of these. The bigger question for me is when they split out code into multiple smaller separately compiled libraries, that still are 100% dependent on the main library to compile and run, and where they are always deployed together still
    – Grubsnik
    Jun 20 at 15:43
1

There is no such thing. Modularity is a basic part of the design of any system and the coarseness of it is not likely to change during the development time. Because you should have a pretty good idea about how the system is going to be used upfront.

Modularity and distribution touches the usability directly, it is not just some technical detail that may be worked out and refined later without changing the system on a functional level. Modularization may be pointless, but if so there would be nothing premature about it. It would just be a poor choice.

The way the company is organized may also be an issue: if different people are responsible for different parts it makes sense to split up the application accordingly.

6
  • There is no conways law at work in these scenarios. it's been perpetuated by 1-3 person teams. Modularization could be done later on if you learn that parts of the code could be recycled in a different project if it was spun off as a separate module, but in both of these cases there is no other such projects planned.
    – Grubsnik
    Jun 20 at 15:10
  • @Grubsnik Personal preferences aside, what would you say to be the cost of splitting things up? If it might ever be useful and it is cheap, I don't see a reason to not do it. Jun 20 at 16:52
  • Splitting things up that shouldn't be split means you get low cohesion and badly damages code readability, because a lot of the relevant logic is fragmented across a lot of tiny code snippets.
    – Grubsnik
    Jun 21 at 7:12
  • 2
    @Grubsnik No, mere splitting does not touch dependencies or cohesion at all. The parts will know each other and use each other just the same. Whether they are in different files and or classes does not change that. It would take a design change to do that, splitting is an implementation detail. You may still find it cumbersome to switch code files or scroll a bit but the model would not change. Jun 21 at 8:32
  • 1
    @Grubsnik: Why the focus on DLLs? It's in a separate project, not solution (by your own words), so I assume a project reference is being made. What does it matter if the project DLLs are separate or lumped together? This has no bearing on the code aspect.
    – Flater
    2 days ago

Not the answer you're looking for? Browse other questions tagged or ask your own question.