title: Simple tips to reduce coupling
body: <p>I have a large .NET web application. The system has projects for different intentions (e.g. CMS, Forum, eCommerce), and I have noticed a (naive) pattern of calling on another project's class. For example, the ecommerce module needs functionality to generate a file on the fly for products, and I call and reference a method in the CMS to do this, because file handling is really a job for the CMS.</p>
  
  <p>Obviously (and I know why), this is bad design and a case of high coupling.</p>
  
  <p>I know a few ways to handle high coupling, like restructuring the project (although I don't really think this is a robust solution), but what else can I do to reduce high coupling? Any simple tips? Also, it would be good to know why/how they reduce coupling. I use .NET 3.5 and Sql Server 2005 so things like JMS (which I keep coming across in my search for tips on this design issue), are not applicable.</p>
  
  <p>Thanks</p>
  
  <hr>
  
  <p>BTW,</p>
  
  <p>One of the reasons I ask this is that I have read the previous questions similar to this but usually if a question that has been asked before is asked again, different tips can be learnt as different people reply to the post.</p>
  
  <p>I know of dependency injection/IOC, but I am interested in the small things that can be done to reduce coupling.</p>
  
  <p>How could I choose between using a static class, or an interface-derived class, or the IOC approach when deciding on <em>how</em> to reduce coupling? Also, I could develop a web service which could call a static class - mixing up the approaches in my solution.</p>
  
  <p>The interesting thing is that in my application, I don't want it to be disjointed. So I just have a forum, ecommerce system, and any other module required, but everything has to gel into one site so each module (which is represented as a dedicated project in my Visual Studio solution) needs to know about every other module and work with it. So for example, I might have a module which handles user profiles (working with ASP.NET membership, roles, etc), but this will work with the forum module as a user on the forum will be a registered user on the site (one login throughout), and his or her profile will be coming from the user profile module. This is as opposed to seperate profiles as seen on other sites I've come across).</p>