Is it bad form to try and have classes other than

Question

I'm trying to learn the correct way to use classes in my code, when it's not something obvious like a set of customers, dogs inheriting from animals, etc.

I've broken off large sections of code into "features" such as Installer.cs, Downloader.cs, UiManager.cs. The only way I can find to have those classes interact with each others' properties and methods is to make them all static, which I've been told in another question is the wrong way to go.

So my problem is one of 3 things:

1. There is a way to make classes talk to each other that I just don't understand yet.

2. Classes should never try to talk to each other, but perform one-off actions and then return something back to main/form1, which the main class can then use to pass into another class for a one-off action.

3. Classes are really only useful for making lots of instances, and there's some other structure entirely I need to learn about for abstracting large chunks of functionality out from the main class.

All the tutorials I can find and lectures I watch seem to only tell you how classes work, but not when and how to use them in a real product.

EDIT - A more specific example:

Say I have one string that is central to the entire app, and needs to be seen and/or modified potentially by every class. How do I move that information around the code without either having everything in one class or making it static?

I can't see a way to let that string live in Form1 without making it static (because all the form events and functions would need to be able to see it to pass it to a class).

I can't see a way to put the string into another class without having to make the string and the whole class static, so other classes can see into it.

Maybe there's something I'm missing about actually instantiating the classes, and making objects interact with each other.

Answer 1

Classes talk to eachother when they have a reference, in order for A to pass a message to B, A needs a reference to B (either an instance or static reference)

Classes can either talk to each other, or return information to another class that controlls the whole process (this is actually a design pattern)

For abstracting information from the main class (or any class) you have interfaces and abstract classes

The Design patterns book from the Gang of Four it's a must read in this case. Something else to keep in mind beside is the simplicity of your design, sometimes trying to fit to a design pattern just cause may end up creating more spaguethi code. As a rule of thumb always try to sepparate the presentation funcionality from the logic, and think of classes as persons talking to eachother and performing jobs (it's kinda weird iknow but sometimes it helps me to think this way)

Answer 2

I think all your intuitions are right.

1. No, there's not. Static or instance.

2. It's a design choice (and there's a lot out there). I'm a pragmatic, so I consider a design pattern that generates spaguethi code a bad design pattern choice. But a bad design pattern for a project can be a good design pattern for another project. Try to read the Head First Design Pattern book.

3. Yes, there are interfaces and abstract classes.

A few more thoughts:

I don't think the use of static methods or classes must be avoided. What must be avoided is the miss use of a static method or class, like the miss use of everything inside a language. But is very hard to define what's a miss use of a static, and because static methods or classes are particulary dangerous, people like to say to avoid the static keyword at all. A static method will be in memory unless you end your application, so if you don't dispose a connection inside a static method, you will have a very bad day.

I have a utility project, and inside the utility project I have a data class. The data class provides access to the database. It's a static class. Why?

Well, first of all, it is static because the connection string comes from the webconfig. So I have a static constructor (runs once when the application starts and the class is mentioned) who reads the webconfig and store the string in a static private member variable. I think it's a lot better than read the webconfig file and create a scoped variable 10 bilion times day. The methods are static because they are simple enough, meaning that they don't need a lot of configuration to work, they just need a few parameters and they are used only in the data access project. All my website users are using the same instance of the method (the static one), but everyone uses the static method with different parameters, so they get different responses from it (they share the pipe, but they drink different water). It's only necessary extra care inside the method to clean everything (dispose every scoped instance), because if you don't they will stay in memory. And finally, my bussiness is about data manipulation, a non static data class means a lot more memory usage than a static one (the cpu usage is almost the same in both patterns).

public abstract class Data
{

    [...]

    static Data()
    {
        #if DEBUG
            _Connection = ConfigurationManager.AppSettings["debug"];
        #endif

        #if RELEASE
            _Connection = ConfigurationManager.AppSettings["release"];
        #endif

        [...]
    }

    [...]

}

In the end of the day I use static when:

1. If it is simple enough (that I can control every aspect);
2. If it is small enough (I use extension methods to validations, and they are static) and;
3. If it is heavy used.

Besides that, I use layers to organize my project (poco + factory pattern). I have a utility project, then a entity model project, then a access project, then a bussiness logic project, then a website, a api, a manager, and so on. The classes in the utility project don't interact each other, but the classes inside the entity model project do (a class can have a instance of another class inside it). The entity model project don't interact with the utility project because they have the same level, they interact each other in another level, in the access project, but it's more intuitive in a data manipulation project.