c# Using code thats not in a form to reduce duplicate code?

Question

just finished one of my projects and about to start another. This is never taught in my university so i dont even know if it exists. Lets say for example you have the code...

MessageBox.Show("Hi");

Now i know i can call it in Form1. I also know i can call it in another form providing it is in a public class / void or something?

My question is, is there a library system where i can add 30-40 code snippits each to do their own job. So when i want to update sql or run calculations i just call a code file from a library?

Sorry if im missing something obvious google is driving me insane, i know what i want to ask, just not how to ask it! Hope you understand my question.. Thanks, Regards..

Answer 1

Of course. In your solution in Visual Studio you can add a Class Library project and fill it with all of the re-usable code that you want. Then any project in the solution can reference it by adding a Project Reference to that project.

Note that it's very easy to go overboard on something like this. Take, for example, your example:

MessageBox.Show("Hi");

The MessageBox class is tightly coupled to the user interface. So it belongs in the user interface objects. (The forms in this case.) This is because if you try to use it in your class library then you would need to add user interface libraries to that class library, making it more tightly coupled with that specific user interface implementation. This makes the class library much less portable and less re-usable because it can only be used by projects of that same user interface technology. (Can't be used by web projects, for example.)

So you'll want to think about each common utility that you encapsulate into its own re-usable code. Does it belong in the UI, in the business objects, in the data access, etc.? If it's tightly coupled with a specific periphery technology (user interface technology, data access technology, etc.) then it probably belongs there.

One approach to this would be to have multiple "common utilities" libraries. Using a contrived naming scheme, a larger enterprise domain solution might have projects like this:

• Domain.BusinessLogic (class library, referenced by everything)
• Application.Forms.AdminPanel (forms application)
• Application.Forms.OperationsPanel (forms application)
• Application.Forms.Common (class library, referenced by other Forms apps)
• Application.Web.PublicWebsite (web application)
• Application.Web.Common (class library, referenced by other Web apps)
• Infrastructure.DataAccess.SQLServer (class library, dependency-injected into the Domain)
• Infrastructure.Vendor.SomeService (class library, dependency-injected into the Domain)
• etc.

So you have a core business logic project, which contains anything that's universal to the entire business domain in which you're working. It should have no dependencies. (Not rely on user interfaces, databases, frameworks, etc.) Then you have applications of various technologies, into which are mixed class libraries which have application-coupled common functionality. And finally you have the other periphery of the domain, the back-end dependencies. These could be your data access layer, integrations into 3rd party systems and services, etc.

As any given piece of functionality is abstracted into a common utility to reduce duplication and increase re-use, take care to keep your code-coupling low so the "common utilities" aren't tightly bound to "uncommon dependencies." All too often in the industry there's an increase in tight coupling with code re-use. (See the Single Responsibility Principle.) So exercise good judgement to avoid that.

There's nothing inherently wrong with writing the same piece of code ("same" by keystrokes alone, not necessarily by conceptual purpose) more than once if it serves more than one responsibility and those responsibilities should not be mixed.

Answer 2

It sounds like you want to use static methods. Group your routines by what they do, and put them in a static class, .e.g

internal static class Utility
{
    public static void Method1(int whatever)
    {
        // do stuff
    }

    public static void Method2(string another)
    {
        // do other stuff
    }

}

You can then call them like:

Utility.Method1(7);
Utility.Method2("thingy");