Where to put Delegates in .Net Solution [closed]

Question

I have a C# .Net collection of solutions which started as a proof of concept, and has grown to almost 15 different projects. I am currently in the process of rewriting the whole product family, and trying to maintain best practices to the best of my abilities, with future-proof organisation.

I have done some research, and I am still unclear on the best place to keep delegates in a multi-project product to minimise the likelihood of a need for refactoring in the future.

I would assume the general consensus is that you place them anywhere that makes sense for the use case, but in general I feel there is a best way to structure everything in a solution to minimise problems, promote positive modularity, and ease maintenance.

In many cases it is recommended that they travel with where they are used; presumably declared in the namespace above the class file, which in my case would translate to my common library with the common interfaces which mandate the events. I currently have delegates in their own file, in a 'delegate' namespace. Is there an oversight I am making by doing so, or am I overcomplicating the use case for delegates - or is this inline with current usage expectations?

I have done the typical searches, but haven't found anything credible nor substantial; however this could be a consequence of poor keyword selection.

Answer 1

I would assume the general consensus is that you place them anywhere that makes sense for the use case, but in general I feel there is a best way to structure everything in a solution to minimise problems, promote positive modularity, and ease maintenance.

Well yes, in the general case, you can just put everything wherever you please it. However, the problems start when you're working in a team. In a team, other people have to understand the structure of the program to be able to create code effectively. That implies consistency, which is the end goal.

So, it's not just a matter of intuition; in all the companies that I've worked in, I've started by writing a coding standard and aggressively enforcing it everywhere. In this coding standard, I usually put a ton of good/bad practices involving threading, static use, placement of variables / classes, etc.

Iirc this link http://se.inf.ethz.ch/old/teaching/ss2007/251-0290-00/project/CSharpCodingStandards.pdf and https://msdn.microsoft.com/en-us/library/ff926074.aspx will give you a head start, although the former is a bit outdated and both don't really answer your question. It might however help with what you're trying to achieve in the long run.

[...] I currently have delegates in their own file, in a 'delegate' namespace. Is there an oversight I am making by doing so, or am I overcomplicating the use case for delegates - or is this inline with current usage expectations?

A common library with interfaces makes sense. An interface is essentially a contract between 'client' and 'server', which is an important asset for decoupling a piece of software.

You have to realize at this point that the 'interface' part is a functional decomposition, not a technical one. In other words: the fact that you need an 'interface' library is a matter of contract, not of technical constructs. As such, I don't see why you would ever put classes in a 'classes' folder and why you would put delegates in a 'delegates' folder. In short, a 'delegates' folder doesn't make any sense to me. Put the stuff where it belongs.

At this point, you have a decision to make. (1) You can put a delegate in a single file, (2) you can put a delegate in the class file where it's used (I usually use delegates for a single purpose), (3) you can do both depending on single / multi purpose and (4) you can put single-purpose delegates nested within the class. This basically means you're treating a delegate as a function pointer description, and don't see it as a real 'class'.

Looking at functional decomposition, you can argue that a function pointer belongs to a class, just like methods.

So to concluse. Personally I usually go for option (2) or (3) because it's brief, clear and concise, and doesn't have an impact on the amount of 'typing work' like (4) . Picking (1) will probably bloat your application with small files that have little or no purpose, which will confuse other developers.