Should I Use Classes The Ways I Have Been?

Posted 04 March 2013 - 06:07 PM

So people in here always tell me to use classes and I have been but I have a few questions regarding these classes but this will throughly answer most of my questions.

First if a class instance is continuously being created over and over again does this inhibit performance Vs's say using a static class? For instance I have a class that helps output a string of the current font used and it gets fired every single time someone types a letter in the richtextbox like so

What the above code allows is the changing of a font type for multiple objects types in classes for instance a Richtextbox but you could create another class for changing the font for a menu or a label etc. etc.

Am I being obsessive using classes for even simpler things like this or is this good code?

LAST BUT NEAT LEAST For some things that will be used the same way over and over again in a particular way that can't change I figured static classes were better for example in my creation of a new tab I use

Re: Should I Use Classes The Ways I Have Been?

For instance I have a class that helps output a string of the current font used and it gets fired every single time someone types a letter in the richtextbox like so

You would be better off making a static method in this. That way you don't create an instance of hte class every time you want perform that function.

Quote

Second I hope I haven't become too obsessive

You have. A class for one method is... well... silly.
Take your design queues from the .NET framework. Notice how they group large numbers of things in a namespace or class because they make sense?

System.IO.Directory -

System.IO.Ports.Serial -

System.Windows.Forms -

Last but not least-
I don't think you really grasp the concept of static.
Think of it as one instance that shares everything across multiple uses. If you make a class static you can't make unique individual instances of it.
If you make a static DodgeRam class, then there will only every be one DodgeRam. You can't make a white one, and a blue one and a green one.

The way you are making these static classes to form a specific styled control doesn't make sense in the real world. Why would you want to make numerous RichTextBoxes that all are located at 6,6?

Frankly, the way you are doing this I think you would be better off with WPF where you can define a style for a control that includes the color, size, border curve radius and so on. That way you can make a BlueButton style and GlassButton style etc.

Re: Should I Use Classes The Ways I Have Been?

For instance I have a class that helps output a string of the current font used and it gets fired every single time someone types a letter in the richtextbox like so

You would be better off making a static method in this. That way you don't create an instance of hte class every time you want perform that function.

Quote

Second I hope I haven't become too obsessive

You have. A class for one method is... well... silly.
Take your design queues from the .NET framework. Notice how they group large numbers of things in a namespace or class because they make sense?

System.IO.Directory -

System.IO.Ports.Serial -

System.Windows.Forms -

Last but not least-
I don't think you really grasp the concept of static.
Think of it as one instance that shares everything across multiple uses. If you make a class static you can't make unique individual instances of it.
If you make a static DodgeRam class, then there will only every be one DodgeRam. You can't make a white one, and a blue one and a green one.

The way you are making these static classes to form a specific styled control doesn't make sense in the real world. Why would you want to make numerous RichTextBoxes that all are located at 6,6?

Frankly, the way you are doing this I think you would be better off with WPF where you can define a style for a control that includes the color, size, border curve radius and so on. That way you can make a BlueButton style and GlassButton style etc.

Thanks for your help friend; that makes sense. I use classes for more elaborate things too but I can see where you are coming from I'm overdoing it for just one method there...I'm curious what you mean about the RTB being at 6,6? I'm doing this because the user is creating another tab in my program and it opens up another tab in the tab control identical to the preceding one. Why is that bad?

Re: Should I Use Classes The Ways I Have Been?

3 months from now you've made significant upgrades to this app. The tabs now resize and scale when the window resizes. 6,6 is no longer the position of the control on the first tab.

What if you upgrade this so the user can reposition all the controls on tab one?

If you want the new control to be the same size and location as its counterpart on the first tab, then get the properties right off the one on the first tab.

Also, hand coding for every control is a maintenance nightmare. If you update tab one's features then you have to recode this part too.
Assuming the new tab is a complete copy of the first tab, then do that. If you make a proper .Clone() method that loops through the .Controls of the first tab and duplicate them on the second tab, using their .Type to dynamically make a new control. HEck... double check... maybe a tabpage already has a .Clone() method...I forget. If it does you can use it. If it doesn't, write one.

Re: Should I Use Classes The Ways I Have Been?

Posted 05 March 2013 - 12:52 PM

I second tlhIn`toq's sentiments. You are getting carried away, and I think you are missing the point.

The thing you have to realize about classes is that they are a tool for managing complexity, and making our lives easier as developers. Your CFontChangePrompt<T> class hierarchy is completely opposed to this idea. It makes an incredibly simple bit of code, extremely complicated - (see Accidental Complexity). Worse than that actually, you've made it completely confusing.

That code that brings up the font dialog is perfectly okay in the UI class, since the UI class's job is to handle the UI

Quote

Is this a proper time to use static classes?

As has been mentioned, there is no need for you to use static where you have, and hiding all that object creation logic behind a wall of static methods is very inflexible, and unnecessary. In this case, as you are creating UI controls, keep that code in the UI class where it belongs.

My general opinion/advice on static methods (and static classes) is that they do still have a place, but you should think hard before finally opting for a static method or class. Sometimes it is the right solution, but many more times, it isn't.

Put simply, static members aren't OO. If you designing an application using the OO paradigm, and you want it to be flexible and testable, your use of static members should be limited.

This post has been edited by CodingSup3rnatur@l-360: 05 March 2013 - 01:07 PM

Re: Should I Use Classes The Ways I Have Been?

3 months from now you've made significant upgrades to this app. The tabs now resize and scale when the window resizes. 6,6 is no longer the position of the control on the first tab.

What if you upgrade this so the user can reposition all the controls on tab one?

If you want the new control to be the same size and location as its counterpart on the first tab, then get the properties right off the one on the first tab.

Also, hand coding for every control is a maintenance nightmare. If you update tab one's features then you have to recode this part too.
Assuming the new tab is a complete copy of the first tab, then do that. If you make a proper .Clone() method that loops through the .Controls of the first tab and duplicate them on the second tab, using their .Type to dynamically make a new control. HEck... double check... maybe a tabpage already has a .Clone() method...I forget. If it does you can use it. If it doesn't, write one.

I have no idea why I didn't think of this? I do apologize for my ignorance but you are totally right about that and you are totally right to just use the first tabs properties...I just don't understand why I didn't think of that ughs. Good Suggestions!!

ALSO there isn't a clone method but I can write my own. Is it possible to extend the methods in something like a tabpage using that class so you could just type Tabpage.clone(). IF so how would you go about doing that? Otherwise I will just create a normal class

Re: Should I Use Classes The Ways I Have Been?

Posted 06 March 2013 - 01:49 PM

Just a good example of why we say no amount of reading can equal building, building and more building. There's no educational experience the compares to coding yourself into a corner and having to find a solution... or dropping 100 hours on a brute force method only to have some smart arse say "what about these 10 lines as a more elegant way?" Both are lessons that sink in and aren't soon forgotten.

Re: Should I Use Classes The Ways I Have Been?

Posted 06 March 2013 - 06:47 PM

tlhIn`toq, on 06 March 2013 - 01:49 PM, said:

Just a good example of why we say no amount of reading can equal building, building and more building. There's no educational experience the compares to coding yourself into a corner and having to find a solution... or dropping 100 hours on a brute force method only to have some smart arse say "what about these 10 lines as a more elegant way?" Both are lessons that sink in and aren't soon forgotten.

I created this and notice I'm adding an event to the richtextbox upon creation and I want it to change the toolstrip label to the current font in the selection of the new textbox in the tab. I could have duplicated the properties using getproperties but this actually seems to amount to more lines of code than what I have here. I'm more worried about that event but one event per new tab with a RichTextBox but I'm assuming that wouldn't be a problem since I have a dipose tab.

I would definitely assume this is a great time to use a class like I did with essential encapsulation of private methods and one public method exposed for example. That said that event if someone would explain why or why that isn't safe that would help a lot.

Re: Should I Use Classes The Ways I Have Been?

Posted 06 March 2013 - 07:02 PM

If all these tabs are just copies of a set format, then why not make a UserControl? You can design the look, fonts, placement, custom events... everything then just make new instances of the UserControl.

The tab represents an object of some type, right? So one object means one control to represent it.

Re: Should I Use Classes The Ways I Have Been?

Posted 07 March 2013 - 02:13 AM

tlhIn`toq, on 06 March 2013 - 07:02 PM, said:

If all these tabs are just copies of a set format, then why not make a UserControl? You can design the look, fonts, placement, custom events... everything then just make new instances of the UserControl.

The tab represents an object of some type, right? So one object means one control to represent it.

That wouldn't work I don't think because a tabpage can't be added to a usercontrol without a tabcontrol or whatever correct? The object is a tabpage with a richtextbox but you can't make a user control out of that unless I'm missing something? Otherwise my above event should be safe and all.

When the focus is on any given RichTextBox within a TabPage, the RichTextToolBar two levels up needs to reflect the current styles, and also be able to apply new styles. When the focus switches to a different tab, the previous tab's styles should not be affected.

I tried to convince the UI designer that this is easier to implement. But he (correctly) pointed out that it was ugly:

Re: Should I Use Classes The Ways I Have Been?

Posted 07 March 2013 - 08:19 AM

What's ugly about that? Its clean design.

Again, if all that care and concern is being spent on the theme and style of the GUI then move the project to WPF where you can define a style. You can even design 5 styles and let the user decide what they like: BlueGlass, RedBrick, PolishedMetal, AlienGreen, SystemDefault

All this work on doing this in WinForms is like spending 5,000 hours to stylize a 1980 Ford Fiesta.

When the focus is on any given RichTextBox within a TabPage, the RichTextToolBar two levels up needs to reflect the current styles, and also be able to apply new styles. When the focus switches to a different tab, the previous tab's styles should not be affected.

I tried to convince the UI designer that this is easier to implement. But he (correctly) pointed out that it was ugly:

That's correct and yes the object is heavily based on a tabpage since I want the user to be able to open up NEW TABS and the way to reference the font etc. of the RTB is by adding a tag to the new tabpage of the RTB.

This can't be done in a user control but perhaps this guy is right. Maybe windows forms is just getting dated and I should look in WPF

Re: Should I Use Classes The Ways I Have Been?

Posted 07 March 2013 - 11:14 PM

Yes, abandon WinForms and go WPF.

WPF subtly pushes you towards better code designs. If you find yourself writing code that looks like WinForms code in WPF, there are two possibilities: you are doing things wrong, or you are overriding the default behavior of a control. More likely than not, it's the former. In my experience, the need the override the default behavior of a control only occurs when you are trying to implement a Silverlight, Windows 7, or Web 2.0-like effect in WPF because the control doesn't exist (yet). (For example, implementing your own autocomplete in earlier versions of WPF.)