tag:blogger.com,1999:blog-33753991.post5633157884774541521..comments2023-09-01T06:00:23.693-07:00Comments on Geek Goddess: Passing Data Using Static ClassesBonniehttp://www.blogger.com/profile/11241425687786973525noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-33753991.post-43564390813662820842019-11-03T15:46:26.510-08:002019-11-03T15:46:26.510-08:00You're welcome, Tony! =0)You're welcome, Tony! =0)Bonniehttps://www.blogger.com/profile/11241425687786973525noreply@blogger.comtag:blogger.com,1999:blog-33753991.post-2641420838300162352019-05-03T13:14:54.331-07:002019-05-03T13:14:54.331-07:00Thanks, Vojislav!! =0)Thanks, Vojislav!! =0)Bonniehttps://www.blogger.com/profile/11241425687786973525noreply@blogger.comtag:blogger.com,1999:blog-33753991.post-38816350584951994652019-05-03T13:14:29.158-07:002019-05-03T13:14:29.158-07:00WhistlerHusky,
In the scenario laid out in the blo...WhistlerHusky,<br />In the scenario laid out in the blog post, we're talking about a LoginForm that only ever appears once, at application startup. The application (after a successful login) could then open those 5 other Forms and the static class/property would be available to those Forms. There would be no way for a user to update the static property, and the Forms themselves wouldn't do it either (if they did, then someone coded those Forms wrong).Bonniehttps://www.blogger.com/profile/11241425687786973525noreply@blogger.comtag:blogger.com,1999:blog-33753991.post-47307346201734259922019-05-03T13:13:57.482-07:002019-05-03T13:13:57.482-07:00Thomas,
I agree with you for non-trivial applicati...Thomas,<br />I agree with you for non-trivial applications, something more robust could be used. For this particular purpose and for the question on the Forums that I was talking about, the application seemed to be a simple application that would only require as simple process ... hence, the static class/property.<br /><br />I wrote a blog post close to 5 years ago that talks about Dependency Injection and Inversion of Control, so I'm no stranger to it (although I haven't had to use it years). If you're interested, here it is:<br />https://geek-goddess-bonnie.blogspot.com/2014/10/intro-to-ioc.htmlBonniehttps://www.blogger.com/profile/11241425687786973525noreply@blogger.comtag:blogger.com,1999:blog-33753991.post-86567194145159348112019-05-03T12:25:02.007-07:002019-05-03T12:25:02.007-07:00What if there are 5 forms open, and 1 of the forms...What if there are 5 forms open, and 1 of the forms that has the button event clicked. what happens? I don't think the other forms' UI will be updated. we might need to trigger an event not change static value directly.WhistlerHuskyhttps://www.blogger.com/profile/04142516618556977128noreply@blogger.comtag:blogger.com,1999:blog-33753991.post-57310213266417922802019-05-03T03:42:57.983-07:002019-05-03T03:42:57.983-07:00Hi Bonnie,
This is a great example that shows wha...Hi Bonnie,<br /><br />This is a great example that shows what they Static classes and how they are practial used on a simple case ;)<br /><br />VojislavAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-33753991.post-76869345148627240122019-05-01T01:00:45.282-07:002019-05-01T01:00:45.282-07:00For a very simple application, it's fine to us...For a very simple application, it's fine to use static properties or singletons. But it can quickly become messy when your application grows up. The approach I'd recommend for a real-world, non-trivial application, would be to use dependency injection. A IAccountService could be injected into every class that needs it. That's testable, maintainable, and doesn't introduce strong coupling.Thomas Levesquehttps://www.blogger.com/profile/17821784613704879657noreply@blogger.comtag:blogger.com,1999:blog-33753991.post-55869488895054757122019-04-30T22:15:19.778-07:002019-04-30T22:15:19.778-07:00Thomas,
>>The login form could expose an Acc...Thomas,<br />>>The login form could expose an AccountNumber instance property<<<br /><br />Yes, it could ... but let's think about that a bit:<br /> <br />Whatever bit of code that called the LoginForm would then have to access the AccountNumber property from the LoginForm and save it. Actually, the property should be an instance of an AccountClass containing an AccountNumber property and whatever other info is needed (instead of a static AccountClass that I talked about).<br /><br />Assuming that the code that called the LoginForm is the MainForm of the application (which, might not always be the case), it would have to pass that AccountClass instance to every other Form it opened (a CustomerForm, an OrderForm, a BillingForm, etc), in those Form's constructor. Consequently every single Form in the application that needed access to the Account info, would have to have a second constructor taking AccountClass as its parameter. <br /><br />Now, OK, that's not that difficult, I agree. But also, how is that really any different than utilizing the same info in a static AccountClass with static properties? With a lot less work?<br /><br />Another alternative that I did mention was using a Singleton, which I thought was overkill in this situation (and still do think so), but it probably is better than passing the instance of the AccountClass around through a constructor parameter to every other Form.<br /><br />A lot of developers say static classes/properties are bad while other developers say that global properties are bad ... but, in my opinion, that is over-simplifying. A lot depends on the application being developed, whether it's a simple app or a complicated app makes a world of difference as to how its architected.<br />Bonniehttps://www.blogger.com/profile/11241425687786973525noreply@blogger.comtag:blogger.com,1999:blog-33753991.post-21749637462635100732019-04-30T00:23:14.888-07:002019-04-30T00:23:14.888-07:00It's still a bad practice. There are many othe...It's still a bad practice. There are many other ways to achieve the same result, not necessarily more complex. For instance, the login form could expose an AccountNumber instance property, which you could get after displaying the login form.Thomas Levesquehttps://www.blogger.com/profile/17821784613704879657noreply@blogger.comtag:blogger.com,1999:blog-33753991.post-33200902899294044622019-04-29T17:58:52.072-07:002019-04-29T17:58:52.072-07:00This only really applies to this particular scenar...This only really applies to this particular scenario … needing information from a Login Form. This is for a Windows Form application. I'm pretty sure that will not affect thread safety or any of the other things you mentioned. <br />The values should not be changed anywhere else in the application, as they are supposed to be used only for display purposes. Perhaps I should have made that clearer in my post. Also, perhaps if I had made the static property's setter a bit more fool-proof so that it couldn't be set anywhere else in the application other than the Login Form.Bonniehttps://www.blogger.com/profile/11241425687786973525noreply@blogger.comtag:blogger.com,1999:blog-33753991.post-30812810060373227432019-04-29T13:43:10.148-07:002019-04-29T13:43:10.148-07:00Please don't do this, it's a terrible idea...Please don't do this, it's a terrible idea! You'll quickly end up with spaghetti code. Here are a few things you'll lose by doing this: thread safety, testability, maintainability. Also, good luck debugging situations where the static value was unexpectedly changed by unrelated code.Thomas Levesquehttps://www.blogger.com/profile/17821784613704879657noreply@blogger.com