Modulaization Startegies

Started by
0 comments, last by Shaarigan 4 years, 2 months ago

Hello folks,

I'm in refactoring again and at a point where I want to reorganize (yes he said it again) my framework code. Reading through the net and some Javascript/ NPM documentation, it feels like having smaller modules is always preferred in opposite to large framework libraries.

The reason I'm thinking about this again, is that most of my code is used to build small tools which can be compiled and copied easily without the need of also adding some external libraries to them. This might sound odd, especially because Microsoft has a different thinking of C# best practice but it has some advantages. The tools get smaller in total and they don't need any external dependencies except for the .NET Runtime stuff. It is easier to install and reorganize code modules and I plan to again provide some kind of package service that can install new modules into the global folder as same as per project, simply you get what you need approach here.

I'm focussing to C# as tooling language and C++ as engine code language at the moment (maybe there will be more one day if needed) so as I can tell, in C++ this comes with no cost at all as modules are static libraries and they are supposed to be linked together anyways. For C# this is a bit more tricky but our build tool is able to handle this and simply adds some auto generated folders and linked files to a Visual Studio project.

So I'm corious to hear your thoughts and experience

This topic is closed to new replies.

Advertisement