[–] 2308482093842 0 points 3 points (+3|-0) ago  (edited ago)

Static classes can sometimes make sense, but often they are just a quick and dirty hack and they make your code harder to extend in the future.

Only if there's no way in hell that you could ever use a second instance of something, only then a static class makes sense.

But 99.9% of the time, you can actually Benefit from allowing more than one instance.

Often, beginners initially like static classes, because you don't have to pass the objects to all your other objects, which is tedious.

But there is a middle Ground:

public class ChannelModel
{
    public static ChannelModel Default { get; } = new ChannelModel();
    ...
}
public class ViewModel
{
    ChannelModel ChannelModel { get; set; }
    public ViewModel(ChannelModel ChannelModel = ChannelModel.Default)
    {
        this.ChannelModel = ChannelModel;
    }
}

Now you have your "static" instance that you don't have to pass around, but you can have multiple instances, since the class is not static.

[–] poloport 0 points 0 points (+0|-0) ago 

Thanks dude! I knew how static classes worked, but that work around is really useful!

[–] auto_turret [S] 0 points 0 points (+0|-0) ago  (edited ago)

Cool man, I did use something exactly like that to access my Receive() in my CaptureEngine class from my RS232Functions class. Something to the effect of

private RS232Functions _instance = new RS232Functions(); public RS232Functions Instance { get { return _instance; } }

and

// Create function call on data received serial.DataReceived += new System.IO.Ports.SerialDataReceivedEventHandler(CaptureEngine.Instance.Recieve);

to use it.. so far that's been working out for me.

[–] grim89 0 points 2 points (+2|-0) ago 

Static classes are generally considered an anti pattern and have few and very specific uses cases (don't remember them of the top of my head). In your example you don't need a static class so u shouldn't use it. All you need to do is pass the instance of ChannelModel to the classes that use it. So let say your ViewModel.cs need ChannelModel you do something liked this.

 public class ViewModel 
    {
     ChannelModel  _channelModel ;
        public ViewModel (ChannelModel  channelModel)
        {
            _channelModel = channelModel;
        }
     }

You should look into Dependency Injection and Inversion of Control since is pretty much a standard now.

Dependency Injection (DI) vs. Inversion of Control (IOC)

[–] roznak 0 points 1 points (+1|-0) ago 

IoC tends to turn out into very messy code and hard to reverse engineer. If you did not create the code yourself or were part of it then you are toast.

In a perfect world where programs are perfect, analysis done right and developers never make mistakes, then IoC is good. But the hard reality is that when you inherit code that you started but others took over and they tell you fix the bugs.

On top of that IoC, actually explodes the amount of code that you need exponentially to do the exact same job.

The sad reality is that if jump on this IoC bandwagon, your brain gets trapped that this is the only possible solution and you lose the ability into train your brain into creativity. You become slave of the code, instead of the master.

[–] auto_turret [S] 0 points 0 points (+0|-0) ago 

On top of that IoC, actually explodes the amount of code that you need exponentially to do the exact same job.

Exactly what I observe. Coming from firmware programming where sometimes your usable ram is measured in BYTES, I kept initially gravitating towards trying to make every bit and byte count. Well, it just don't work that way in Windows app coding..

I can see how it could be quite helpful in swapping modules down the road, and my small app so far seems it could be easily followed and understood without excessive commentary.

[–] auto_turret [S] 0 points 0 points (+0|-0) ago 

Thanks for the reply. I'm drawing out my program for the umpteenth time, it is slowly starting to click I think..

I believe my trouble is, I keep reverting to thinking like I'm coding a microcontroller which keeps me running into roadblocks.

Referencing your code: I see what you did there, didn't realize I could pass along the whole instance and it's current state.

I believe now, if I put an event listener in that ViewModel constructor instead, and stick _channelModel = channelModel in a method that will call, it should listen for a newdata available event and update itself accordingly, so long as I've created a new ViewModel instance in my main program.

I'll give it a shot. Thanks man, that was super helpful. Going to check out the links you've provided.

[–] whambamthankyouham 0 points 1 points (+1|-0) ago 

Static class -> When you only want one of something.

If you create a level in a game as a class, you (typically) only want one instance of that level.

[–] roznak 0 points 0 points (+0|-0) ago 

If you start with static classes first then you will end up having code that is not extendable and thread safe. Also you can always nail down a dynamic class as static like a singleton.

I tend to initialize static classes at my Main() first. This way I have a predictable place where the code gets initialized.

[–] auto_turret [S] 0 points 0 points (+0|-0) ago 

Scratch the last comment, got rid of the static from SerialPort too. I think I've pretty much got this concept down, now. Been banging my head for a month, then finally came to you guys for advice. Turns out that's exactly what I needed!

[–] roznak 0 points 0 points (+0|-0) ago 

Nice to hear.

[–] auto_turret [S] 0 points 0 points (+0|-0) ago 

I've re-written the darn thing again, but this time using the dependency inversion principle. NOW things make more sense.. high level modules don't depend on lower level modules, but rather abstractions that don't rely on details.

Works for everything BUT the serialport functions. It appears it must be static or my port won't stay open.