A question or two about classes and when to use them.

I took a three year course in Computer Programming at a community college. We learned how to code using C++, COBOL (Ugh), VB 6.0, Java, and even had a unit on JCL/Mainframe as a lot of employers in my city are government and therefore quite archaic.:rolleyes:

Anyway, that was in 2001. I've been working primarily as a data analyst ever since but I've written my fair share of applications during that time as well - some of which have multiple end users and some are just data-loading programs.

It's been a couple of years since I wrote anything substantial and I'm starting to get the hang of VB.Net.

That's my background...now onto the questions...

I wrote a fairly large program back around 2003 that used "classes" in VB 6.0. The class was setup to build a record that would ultimately be loaded into an Oracle database. Even though I used classes back then and we covered them in school quite a bit, I'm STILL not entirely sure how best to incorporate them into my programs.

I try to write my applications into as many compartments as possible. For example, when someone hits the "Run" button on one of my loading apps the code within that button just calls a bunch of subs/functions.

E.g.

GetData()
AddToDataSet()
EliminateDuplicates(parameter(s))

This method works pretty well for me because when I look at the code it's easy to see the steps my program takes to run. I know based on the above that my program gets data, adds it to a dataset, and then eliminates duplicates - just as an example off the top of my head, not saying that's exactly how it works.

Anyway, at what point here would a "class" be more useful? To me, classes are more useful in shops with multiple programmers and applications where you build everything to be as reusable as possible.

For me, I may get a text file from someone that needs to be loaded into a database once a month. That text file is unique and I fail to see why my above method doesn't work just fine.

I guess what I'm saying here is...I hear a lot about about classes and how they're so useful, but I rarely see how they would be useful in my loading programs or small applications.

I guess I need a refresher more than anything. It's been over 10 yrs and I feel like I'm becomming that crotchety old "back in my day" kind of programmer.

You already ARE using classes. Every form is a class, the dataset is a class, the controls are classes. You would certainly agree that those are useful, right?

So, why would you create your own classes? Largely for the same reason that forms and controls are classes: You want to encapsulate the concept of some logical object that you want to use as a distinct entity. You might create your own control, or you might have some concept that has several pieces of data that you want to keep together as a single unit along with a set of methods that work with it, which is all that a form or control is.

Right.

I guess I was asking when would/should I build my own. For one off programs there's no point, unless of course maybe there's something like "validate client age" in which case I could reuse that code in other applications.

I remember about 10 years ago a colleague and I wrote our own class that was purely to validate data. It was a monster. Wonder where I saved it? LOL

I use them all the time. While it is generally spoken of as being the reason for creating object, code reuse isn't done all that often (at least not in the whole). I have come up with a few utilities that I want to be able to use in different applications, but those I turn into dlls, such as one for fish marking. However, within the dll, there are a whole bunch of objects. For example, I have a class for a mark. The mark has a name, a type, a placement, a value (some do, some don't), possibly up to two colors, and occasionally one other thing. So, I want to be able to pass marks around. I want to be able to have a collection of marks on a fish, and I want to be able to search those marks for the type and placement, while displaying the name and value of the mark (but almost never searching for the value). A class is an ideal way to handle this information, because I can keep the type, placement, value, colors, and the one other thing together. The name is a more complicated animal, because it generally is constructed from those other properties, and can come in different forms, so Name isn't really a member of the class at all, but a method that can take a couple arguments as to what kind of a name the user wants, and will respond with a string that is whatever name the mark has.

How else would you handle that kind of data if not in a class? A fish can have several marks on it, so you can't just use a set of variables for the mark. You could create a series of arrays, each one holding one property (such as the type, the placement, the value, and so on), but then you'd have to keep those arrays in sync, which could get awkward, since every mark would have a type and a placement, most would have a value, but few have colors. So, you COULD do it with a bunch of arrays, but what a horrible hassle that would be. A class is the only reasonble way to handle the data, and it has the added benefit that you can do things like add a method that returns the name for the mark. Better still, though I don't actually do this for the Mark class, I could implement a sorting routine, such that a collection of marks could be sorted by whatever made sense (but nothing does make sense, in this case, which is why I don't have a sorting routine for the class).

Another example would be the complex names I'm using for some logical structures at a hatchery. I want to be able to sort the names in some order, but the names might be something like Vat1, Vat1A, Vat2, Vat2A, and so on. That will sort ok until I get to Vat10, which will sort before Vat2, so it will sort out as Vat1, Vat10, Vat1A, Vat2, etc. The names are more complicated than that, too, so they have a prefix, a body, a number, and a suffix. Furthermore, I want to be able to sort them in a totally custom order, so they have an ordinal value that will be used for those cases where I don't want a normal sort order.

So, the vat name has five components to it. If I didn't use a class, how would I even store that thing? The only obvious solution would be a bunch of synced arrays, again, but sorting that would be flat out impossible. Instead, I created an object that had those five components as members, overrode the ToString method to produce the full name by putting the components together on demand, and implemented the IComparable interface so that a collection of Vats could be sorted. The way the sorting works is that, if there is an ordinal, the vats sort by the ordinal, and if there is no ordinal, the vats sort by the name components such that Vat 10 comes after Vat 9 rather than after Vat 1. That sort code is super easy, too, and now I can just use Array.Sort to correctly sort an array of vats.

So, classes end up being used all over the place. Whenever you want to pass around a set of related data, or have a collection of sets of related data, or have methods that only make sense with a set of related data, that's when classes are ideal.

I am a late comer to OOP as well.
What I have found is that some topics are better suited to an object oriented solution others are not.

If you want to delve into using them I suggest you pick something fun to do to get into the mindset.

Quote:

---

Originally Posted by The_Grudge

For one off programs there's no point

---

Absolutely not. You should create a class for every logical object in your project. If you start out thinking that it's not worth it for this project and that project you will undoubtedly end up getting caught out at some point where a project gets unwieldy and you have to maintain it. Start out with good habits and they will become second nature. It takes a bit of extra time at first but simple project are the places to learn things. Don't wait until you're working on a complex project to learn then things that you'll need to use in that project. Learn them on the easy stuff where it's much easier to isolate them.

Quote:

---

How else would you handle that kind of data if not in a class?

---

With a struct or a record. You don't need OOP to pass around related data (although structs are kinda OOPy, they do describe "things").

I think the real power of OOP comes from the other thing Shaggy touched on: the ability to add a method. Or in techy words, the ability to have behaviour co-located with state. To extend Shaggy's fish marks example, say your name could be made up of any combination of the other properties (type, placement, value, two colours and the one other thing). A procedure to return the name would have to receive all those elements along with some sort of configuaration indicator to tell it which to actually use. It ould look something like this:-

name = GetName(type, placement, value, colour1, colour2, thing, configuration)

That's a pretty chunky looking method signature. An OOP one would look like this:-
name = Fish.GetName(configuration)
...no need to pass all the type and colour info in because the fish already knows it.

I think all the benefits of OOP start with that colocation of behaviour and state, whether it's encapsulation, abstraction, inheritance etc. The trouble is it's really hard to explain how those things come from it, or even why they're beneficial, until you start using it and reaping the rewards. It's certainly hard to explain as evidenced by the fact that I've just written and rewritten and finally abandoned several lengthy explanations because I realised they were becoming garbled nonsense. I think the only way you can appreciate it is to dive in, get it wrong a few times and then slowly learn from your errors. Any paradigm shift is painful at first but that doesn't mean it's not worth persisting with.

Another point, OOP is not always the right choice. Procedural code can often be a better one. Recently I wrote a set of stateless services to access properties of a clustering model. When I first started it I tried to create classes to describe the model, the clusters, the variables etc. It didn't take me long to realise that all the methods in my classes were static, so the classes could be static too. And if the classes were static that meant they had no state - so they were really just old school modules. I'd wasted a lot of time trying to shoehorn object orientation into an essentially procedural problem. I guess the clue should been that I was writing stateless services which are by definition, procedures but you live and learn.

The problem is, until you've spent some time getting used to object orientation you are unequipped to know when it will be worth it and when it will be a waste of time. That will only come with practice.