Is bad form to try and not interact with each other classes other than main / form1?

Question

I am trying to learn the correct way to use classes in my code when it is not something obvious, like a set of clients, dogs, inherited from animals, etc.

I have broken large sections of code into “functions”, such as Installer.cs , Downloader.cs , UiManager.cs . The only way I can find these classes to interact with each other's properties and methods is to make them all static, as I was told in another question, this is the wrong way.

So my problem is one of three things:

• There is a way to get classes to talk to each other, which I don’t understand yet.

• Classes should not try to talk to each other, but perform one-time actions and then return something back to main/form1 , which the main class can then use to move to another class for a one-time action.

• Classes are really only useful for creating many instances, and there is some other structure that I need to learn in order to abstract large pieces of functionality from the main class.

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

EDIT is a more specific example:

Let's say I have one line that is central to the entire application, and it needs to be seen and / or modified potentially for each class. How to move this information around the code without having only one class or static?

I see no way to let this line live in Form1 without making it static (because all the events and functions of the form should be able to see in order to pass it to the class).

I see no way to put a string in another class without having to put the string and the whole class, so other classes can see in it.

Perhaps there is something that I miss, actually creating instances of classes, and creating objects that interact with each other.

Answer 1

I think all your intuitions are right.

• No no. Static or instance.

• This is a design choice (and there are many there). I am pragmatic, so I am considering a design template that generates spaguethi code for poor template design. But a bad design pattern for a project can be a good design pattern for another project. Try reading the Sample First Design book.

• Yes, there are interfaces and abstract classes.

A few more thoughts:

I do not think that static methods or classes should be avoided. What to avoid is to skip using a static method or class, for example, skip using everything inside the language. But it’s very difficult to determine what to skip using static, and because static methods or classes are especially dangerous, people like to talk to avoid the static keyword at all. The static method will be in memory if you do not finish your application, so if you do not establish a connection inside the static method, you will have a very bad day.

I have a utility project, and there is a data class inside the utility project. The data class provides access to the database. This is a static class. Why?

Well, firstly, it is static, because the connection string comes from webconfig. Therefore, I have a static constructor (it runs once when the application starts and the class is mentioned) that reads webconfig and stores the string in a static private member variable. I think this is much better than reading the webconfig file and creating a variable with a range of 10 billion once a day. The methods are static, because they are quite simple, which means that they don’t need a large configuration to work, they just need a few parameters, and they are used only in the data access project. All users of my site use the same instance of the method (static), but each uses a static method with different parameters, so they get different answers from it (they share the channel, but drink different water). This is only necessary in order to clear everything (dispose of each instance with an area), because if you do not, they will remain in memory. And finally, my business is about data manipulation, not a static data class means much more memory usage than static (CPU usage is almost the same for both patterns).

 public abstract class Data { [...] static Data() { #if DEBUG _Connection = ConfigurationManager.AppSettings["debug"]; #endif #if RELEASE _Connection = ConfigurationManager.AppSettings["release"]; #endif [...] } [...] } 

At the end of the day, I use static when:

• If it's simple enough (so that I can control every aspect),
• If it is small enough (I use extension methods for verification, and they are static) and;
• If it is heavily used.

In addition, I use layers to organize my project (poco + factory pattern). I have a utility project, then an entity model project, then an access project, then a business logic project, then a website, api, manager, etc. The classes in the utility project do not interact with each other, but the classes inside the project are entity models (a class can have an instance of another class inside it). The entity model project does not interact with the utility project because they have the same level, they interact with each other at a different level in the access project, but it is more intuitive in the data processing project.

Answer 2

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

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

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

The book of design templates from Gang of Four should be read in this case. Something else to keep in mind is the simplicity of your design, sometimes trying to adapt to a design pattern, simply can lead to more spaguethi code being created. As a rule, always try to separate the presentation functionality from logic and think of classes as people talking to each other and doing tasks (this is strange, but sometimes it helps me to think so).