tag:blogger.com,1999:blog-7442262522977329981.post3417327235884404827..comments2011-04-05T13:55:41.825-05:00Chris Ammermanhttps://profiles.google.com/118440544456036580001noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-7442262522977329981.post-77151657746561431242011-04-05T13:55:41.825-05:002011-04-05T13:55:41.825-05:00Alex,<br /><br />Assembly proliferation worries people, and I think that the reason for this isn&#39;t completely ill-founded. An assembly is more opaque than a class. It feels like a firmer boundary. It sends a message, and that shouldn&#39;t be discounted. Such boundaries should be constructed with great care. It&#39;s important that they be meaningful.<br /><br />I think that people too often use the number of assemblies as a proxy measurement for complexity, or for appropriateness of divisions. But they do this because they&#39;ve been burned before, and it has been a reliable indicator. However, when broken out very deliberately, and for the purpose of separation of concerns/responsibilities, I think that there is nothing inherently dangerous about it.<br /><br />One big challenge in solutions with a lot of projects is that of complex dependency networks. This doesn&#39;t mean there are too many projects/assemblies, however. Rather it means that responsibilities are not well-separated. With a many-project solution, layers of responsibility should emerge, where you can draw lines through (see the little graph image in my <a href="http://www.turbulentintellect.com/2011/03/yagni-abuse.html" rel="nofollow">&quot;Yagni Abuse&quot;</a> post) and show that as a rule, dependencies only go in one direction across a layer boundary, and preferably don&#39;t cross more than one layer boundary.<br /><br />If you can&#39;t identify layers like this, if you have more of a net, or cycles, then responsibilities are being spread around too much. You may have good decoupling, but not enough <b>cohesion</b>. That is the real thing to keep watch of. Separate your projects/assemblies all you want, but keep an eye on your cohesion, because that&#39;s what holds everything together in the right way and protects against chaos. =)Chris Ammermanhttp://www.blogger.com/profile/13199328747453354231noreply@blogger.comtag:blogger.com,1999:blog-7442262522977329981.post-9019592801025085222011-04-05T13:23:40.856-05:002011-04-05T13:23:40.856-05:00I&#39;ve found that SRP and composition go well together and I&#39;ve found that often times if my classes get much longer than 100 lines that I&#39;m likely missing opportunities to identify violations of SRP that can be solved through composition.<br /><br />I&#39;m currently struggling with SRP at the project level. There&#39;s sufficient temptation and even pressure to reduce the number of assemblies a project references but I&#39;ve found that some of the cleanest code I&#39;ve read/written usually has a lot of external dependencies where each library focuses on addressing one limited area. What are your thoughts on this kind of application of SRP?<br /><br />Nice post!Alexhttp://www.blogger.com/profile/06478435817434716597noreply@blogger.com