Блог

Мне нравится, как концепции могут быть разделены, когда решение разбито на несколько библиотек классов. Например:

 System.IO.csproj,            Stream class
System.IO.Net.csproj,        NetworkStream class
System.IO.Filesystem.csproj, FileStream class
System.IO.Extensions.csproj, bunch of classes which builds on top of System.IO
  

Таким образом, я могу быть почти уверен, что Stream class ничего не знает о NetworkStream , как и должно быть. Когда кто-то пытается создать хак с участием NetworkStream внутри Stream класса, он получает ошибку компилятора, отлично!

Аналогичным образом, когда кто-то пытается добавить какой-то метод в Stream , который принимает в качестве аргумента что-то из расширений, он также получает ошибку компиляции, отлично! Иногда люди пытаются создать зависимость, которая никогда не должна существовать.

Есть ли способ аналогичным образом разделить понятия в одной библиотеке классов?Если не применять это, есть ли хотя бы способ протестировать это?

По моему опыту, лучше всего работает несколько библиотек классов, и легко управлять ссылками на них (это принудительное исполнение), но кажется непрактичным иметь большое количество библиотек классов. У меня часто есть некоторый код ядра, затем есть куча расширений, затем есть расширения 2-го уровня, Которые используют другие расширения и т.д. В идеальном мире каждое расширение было бы отделено от другого.

Тогда есть приложение или библиотека, которая использует функциональность, и с ее точки зрения, лучше всего, когда все является одной библиотекой классов.