-
what's so great about classes?
I'm having a hard time with this concept.
Would something like this be the idea behind a class...?
Say I want to be able to specify a market, and for that market, I'd like to get back all the residential customers who have purchased $1000 or more in the last year...Specifically, I want the customer's name, dollar amount of purchases in the last year, and address.
So, I would "set" the market. Then the class functions would do the processing to find the qualifying customers, and I would "get" the name, total sales and address...
Is that more or less the idea? Then any other program that needs customer name, sales and address based on market number would create an instance of an object based on this class?
Thanks,
Jeff
-
Re: what's so great about classes?
Not really. A class is supposed to be the definition of something that can be instantiated. An instance of a class is an object. OOP is supposed to mimic the real world. Think about objects in the real world. You could tell me what makes a dog a dog, right? That description is the Dog class. Each dog running around is a Dog object, i.e. an instance of that class.
Each one of those Dog objects has all the characteristics and behaviours that make them a Dog, right? In programming terms, those characteristics and behaviours are properties and methods. Each Dog object has all the same characteristics, but different values for those characteristics, e.g. every Dog has a fur colour, but each Dog's fur colour is slightly different.
If you were creating a pet sim game, your app might indeed have a Dog class. Other applications will define and use lots of other classes. When it comes to programming, you will also define classes to represent more abstract things as well. Consider data access. There is one class that represents the connect to the database. There is another class that represent the SQL command executed over that connection. There is another class that represent the table of data.
In your case you would define a class to represent a customer and their total purchases. Your class might have properties for the customer information, or you might already have a Customer class that contained all that information so this new class could just expose that via a single property. It would then add another property for the total purchases. Your data access class would create the connection and execute the command, then create and populate instances of your own classes with the data it retrieved.
-
Re: what's so great about classes?
Yeah, that sounds like a plausible description.
A class is a chunk of data and methods that work on that data. In your case, you do have a chunk of data that is wrapped in the market class, and you do have a set of functions that work against that data, so it's a fair example.
-
Re: what's so great about classes?
Ha, cross posted with JMC and gave a different answer. Stand by it, too. A market could easily be an object. I would agree that the customer would also be a good candidate for a class, but the market could be, as well.
-
Re: what's so great about classes?
Quote:
Originally Posted by
Shaggy Hiker
Yeah, that sounds like a plausible description.
A class is a chunk of data and methods that work on that data. In your case, you do have a chunk of data that is wrapped in the market class, and you do have a set of functions that work against that data, so it's a fair example.
So, the next time somebody wants something a little different. Instead of the residential customers, they want residential customers with good credit. Now, do I make another class for this, where most of the code is the same, but just minor difference? Or they want commercial customers instead of residential.
Let's say I know that I'm going to have lots of requests like this, but they're all going to have slightly different "wrinkles". Would I still make a class for something that's probably only going to be used by one application? Or, make a more general class -- ( say, I know they always will want the customers whose numbers are greater than 10, and they will always want at least the name and address). Would I just put that general stuff inside the class, and then code the particulars outside of the class?
-
Re: what's so great about classes?
Quote:
Originally Posted by
Shaggy Hiker
Ha, cross posted with JMC and gave a different answer. Stand by it, too. A market could easily be an object. I would agree that the customer would also be a good candidate for a class, but the market could be, as well.
Yeah, I appreciate both you guys taking the time to answer me. No offense, JMC, but if I see another reference to cats and dogs I think I'm going to scream! :):lol::p
-
Re: what's so great about classes?
here are some good & simplistic (of course made simplistic ) tutorials
OOP by madhusudan
OOP by GedMead
OOP in MSDN
-
Re: what's so great about classes?
Quote:
Originally Posted by
Jefals
So, the next time somebody wants something a little different. Instead of the residential customers, they want residential customers with good credit. Now, do I make another class for this, where most of the code is the same, but just minor difference? Or they want commercial customers instead of residential.
Let's say I know that I'm going to have lots of requests like this, but they're all going to have slightly different "wrinkles". Would I still make a class for something that's probably only going to be used by one application? Or, make a more general class -- ( say, I know they always will want the customers whose numbers are greater than 10, and they will always want at least the name and address). Would I just put that general stuff inside the class, and then code the particulars outside of the class?
No, you don't need a separate class for each type of customer, unless they differ from each other in a very significant way. A customer is a customer and the type is just one of its properties.
A class can have properties/fields, behavior (subs/functions), events.
What you are saying is just a property of the customer. So
Customer Type (Residential/non-residential etc.)
Credit (good/bad etc.)
A class will always be required. It is a like a template for your objects. It helps in creation of your objects and defines its properties, behavior and events.
It is always a good idea to code your classes in a general way, though if you know that you will never never need any customer data with number less than 10, you can put the restriction inside the class.
-
Re: what's so great about classes?
Quote:
Originally Posted by
Pradeep1210
No, you don't need a separate class for each type of customer, unless they differ from each other in a very significant way. A customer is a customer and the type is just one of its properties.
A class can have properties/fields, behavior (subs/functions), events.
What you are saying is just a property of the customer. So
Customer Type (Residential/non-residential etc.)
Credit (good/bad etc.)
A class will always be required. It is a like a template for your objects. It helps in creation of your objects and defines its properties, behavior and events.
It is always a good idea to code your classes in a general way, though if you know that you will never never need any customer data with number less than 10, you can put the restriction inside the class.
But the functionality to return the set of customers I'm interested in changes. One application wants to see customers regardless of their credit, the other only wants those with good credit. Do I understand you correctly then, that I would want the class to return the credit where I could examine it external to the class?
-
Re: what's so great about classes?
Quote:
Originally Posted by
make me rain
Great! Thanks for this!
-
Re: what's so great about classes?
Quote:
Originally Posted by
Jefals
No offense, JMC, but if I see another reference to cats and dogs I think I'm going to scream! :):lol::p
It's one of the easiest analogies to describe and understand. You should not disregard something because of the real world example it uses. What you should do, is re-read everything he said and try to understand it, because your later posts indicate that you don't.
Quote:
Originally Posted by Jefals
But the functionality to return the set of customers I'm interested in changes. One application wants to see customers regardless of their credit, the other only wants those with good credit. Do I understand you correctly then, that I would want the class to return the credit where I could examine it external to the class?
First off, you have mentioned two different applications. Now, to us .NET people you are talking about two completely separate executables. Is this the case? Everything is .NET is a class (I'm purposely ignoring Structures because I don't want to explain it). When you are dragging a button onto your form and double clicking it, you are doing two things:
1) Adding an instance of a Button class to an instance of the Form class.
2) Creating an event handler for the 'Click' event of the Button class inside the Form class.
Say you had your proposed Customer dilemma:
vb.net Code:
'//this class represents a person that is a customer, whether their
'//credit is good or bad. what we do is define ways to indicate to
'//ourselves if it's good or bad
Public Class Customer
Private _name As String
Public Property Name() As String
Get
Return Me._name
End Get
Set(ByVal value As String)
Me._name = value
End Set
End Property
Private _hasGoodCredit As Boolean
Public Property HasGoodCredit() As Boolean
Get
Return Me._hasGoodCredit
End Get
Set(ByVal value As Boolean)
Me._hasGoodCredit = value
End Set
End Property
End Class
'//here is a sample method that writes out the customers
Public Sub WriteCustomers()
Dim customers = New List(Of Customer)()
customers.Add(New Customer() With {.Name = "John Smith", _
.HasGoodCredit = True})
customers.Add(New Customer() With {.Name = "Jane Smith", _
.HasGoodCredit = False})
'//these are all the customers with good credit
For Each customer In customers
If customer.HasGoodCredit Then
Console.WriteLine("I, {0}, have good credit", customer.Name)
End If
Next
'//these are all the customers with bad credit
For Each customer In customers
If Not customer.HasGoodCredit Then
Console.WriteLine("I, {0}, have bad credit", customer.Name)
End If
Next
'//these are all the customers
For Each customer In customers
Console.WriteLine("I, {0}, have a credit rating", customer.Name)
Next
End Sub
As you can see, all the Customer class is doing is representing someone that is a customer. All I'm doing is creating two "people" that I want to represent as customers with some type of credit rating. Whether I want to see them with good or bad credit is separate from the Customer class.
-
Re: what's so great about classes?
Quote:
Originally Posted by
ForumAccount
It's one of the easiest analogies to describe and understand.
yes...and one of the most overused also. That's why I don't need to see it again..I understood it the first time I saw it, and I've seen it at least dozens of times by now.
[qoute] What you should do, is re-read everything he said and try to understand it, because your later posts indicate that you don't..[/QUOTE]
There is absolutely NO WAY, at this stage I'm going to understand everything JMC tells me -- Don't get me wrong; I really appreciate his efforts, and I do get nuggets of understanding from his answers, but most of what he says is way over my head at this point.
Quote:
First off, you have mentioned two different applications. Now, to us .NET people you are talking about two completely separate executables. Is this the case?
yes
Quote:
Say you had your proposed Customer dilemma:
vb.net Code:
'//this class represents a person that is a customer, whether their
'//credit is good or bad. what we do is define ways to indicate to
'//ourselves if it's good or bad
Public Class Customer
Private _name As String
Public Property Name() As String
Get
Return Me._name
End Get
Set(ByVal value As String)
Me._name = value
End Set
End Property
Private _hasGoodCredit As Boolean
Public Property HasGoodCredit() As Boolean
Get
Return Me._hasGoodCredit
End Get
Set(ByVal value As Boolean)
Me._hasGoodCredit = value
End Set
End Property
End Class
'//here is a sample method that writes out the customers
Public Sub WriteCustomers()
Dim customers = New List(Of Customer)()
customers.Add(New Customer() With {.Name = "John Smith", _
.HasGoodCredit = True})
customers.Add(New Customer() With {.Name = "Jane Smith", _
.HasGoodCredit = False})
'//these are all the customers with good credit
For Each customer In customers
If customer.HasGoodCredit Then
Console.WriteLine("I, {0}, have good credit", customer.Name)
End If
Next
'//these are all the customers with bad credit
For Each customer In customers
If Not customer.HasGoodCredit Then
Console.WriteLine("I, {0}, have bad credit", customer.Name)
End If
Next
'//these are all the customers
For Each customer In customers
Console.WriteLine("I, {0}, have a credit rating", customer.Name)
Next
End Sub
As you can see, all the Customer class is doing is representing someone that is a customer. All I'm doing is creating two "people" that I want to represent as customers with some type of credit rating. Whether I want to see them with good or bad credit is separate from the Customer class.
Thanks for this. I see you have all the code inside the class, and I execute whatever functions I need to get back the set of customers I'm after.
THis clears it up a lot for me...Thanks again!
-
Re: what's so great about classes?
Your market can either be a class or an object. If your market is going to change, you can make the market a general class and a set of functions and fields that all of your 'other' markets will use. This is where you use inheritance to use the base standard market class and make new inherited class with new functions and fields based on what your new market requires.
-
Re: what's so great about classes?
Quote:
Originally Posted by
zero_coke
Your market can either be a class or an object. If your market is going to change, you can make the market a general class and a set of functions and fields that all of your 'other' markets will use. This is where you use inheritance to use the base standard market class and make new inherited class with new functions and fields based on what your new market requires.
AAAUGGHH!!! Just when I thought I had it! I haven't studied inheritance yet, so not sure what that's all about, but I was thinking that "Market" was going to be a variable that I would pass as a property into the class, and the the functions inside the class would use that variable/property to find the customers belonging to that market. Isn't that how it works?
-
Re: what's so great about classes?
It could be.
Doesn't that clear it all up??
Actually, from your description, it does sound like you would pass in the market and use that to select the customers. It would be kind of like a query variable, and might be nothing more than a string.
Inheritance is interesting. You had industrial customers...and something else. How about retail customers for the other group. Both are customers, but they might be somewhat different. Therefore, you could make a Customer class, which would hold the functionality that is common to both. They might both have a function called BuildCredit(), but the industrial customers might need to have that function behave differently from retail customers. So the Customer class would have the function, and declare it Overridable, or Must Override. Then you could create a IndustrialCustomer class that inherited Customer, and a RetailCustomer class that inherited Customer. Both classes would have the BuildCredit function, but the version for the IndustrialCustomer would be different from the version for the RetailCustomer.
Now you can create a collection of Customers. Since every inherited class can be cast as an instance of its base, a collection of Customers can hold RetailCustomers or IndustrialCustomers or both. They are all just Customers in that collection, and their actual type doesn't matter to the collection. However, if you then call BuildCredit on an item in the collection, then if the item is really a RetailCustomer, then that version of BuildCredit is called. If the item is really an IndustrialCustomer, then their version of BuildCredit is called. You don't have to know which type it is, the right version of the method will be called.
That would be runtime polymorphism, and quite frankly, there are few times that it is all that useful.
This answer sucks.
-
Re: what's so great about classes?
Quote:
Originally Posted by
Shaggy Hiker
This answer sucks.
DANG! This answer sucks?! I thought this was going to be it, till I read that! :rolleyes:
I actually think with all the help I've gotten now, I could muddle thru this and make it work!
-
Re: what's so great about classes?
If you draw yourself a Venn diagram, the middle part would be fields and functions that ALL of your markets will use. The part that is not shared by all of the markets would be an inherited class of the middle shared class.
So essentially you are making 1 class that will have properties that you want every market to have. Then, when you want to make a new market with added features, you inherit this 'base' standard class and add your new fields/functions. That's how inheritance works. You don't need to re-define the functions you did in your base standard class. Do you understand now?
So here:
My base standard class is this:
Quote:
public class TemplateForAllMarkets{
private int x;
private int y;
private double d;
public function cashierCount{}
public function collectMoney{}
}
Now, let's say I want to make a new market that 'improves' on the base class:
Quote:
public NewMarket inherits TemplateForAllMarkets{
private ooo_la_la;
public function magicalDrinks{}
}
This NewMarket class will contain all the fields and functions that your TemplateForAllMarkets class had plus these new ones that you made.
Just read up on a little and you'll get the hang of it. There are some rules on how you can access the variables and such in inherited classes so yeah those are the little technical details, but I believe from what you wanted in your original post this is the way to solve your problem I guess...
-
Re: what's so great about classes?
Thanks ZeroC,
I've been thinking about this off and on now, and seems to me like, as with many things, there would be several ways to approach this. Remember the idea is that, today, a user comes to me and says, "Jeff, I need the name / address of all customers in the southeast".
Next week, it's "Jeff I need all residential customers in the company with good credit. I need their name/address, and credit score". After that it might be, "Jeff, I need name/address/credit score and date of last purchase, for all customers in the Northeast with annual sales over $5,000".
So, I never know what I'm going to need to extract, and what the parameters are going to be -- but, I know that somehow if I can build some common functionality that might just need a little "tweaking", it will make my life easier.
Based on what I've learned from you guys so far, I think I would consider each of these requests as a separate application, although I might start one application by copying what I've already done on one of the prior ones.
Or I might just add functions to my class of customers to extract, based on the different parameters, and then my modules would call whatever function was appropriate.
And now with what I think I'm learning from you re. inheritance, I might use that to get the customers I need.
Anyway, I think this is all a lot clearer to me now after this discussion -- UNLESS my mind is totally muddled and you guys tell me I actually haven't got a CLUE what I'm talking about! :sick:
-
Re: what's so great about classes?
Classes are nice for referenced data on the stack, but have you guys discussed the Structure type as well? :D
Anyway, yes, classes are the best solution to most things. I can remember having variables like this:
Quote:
SelectedItemInformationText
SelectedItemInformationLocation
SelectedItemInformationLine
SelectedItemInformationErrorCode
SelectedItemInformationErrorText
SelectedItemInformationName
SelectedItemInformationFile1
SelectedItemInformationFile2
SelectedItemInformationWDir
After making a class named "ItemInformation" it all became so much easier to understand. I believe the main usage for classes is when you have to store "shared information" that has to be the same for multiple variables, like Item information.
-
Re: what's so great about classes?
Yep, from the sound of what you're trying to do, it seems like you would need multiple classes with a common interface. Look up interfaces and how they can tie in multiple classes and allow you to extract information out of your many classes. That in my opinion is one approach, but like I said, you can also use inheritance or just build yourself a .net application with multiple datagridview controls and put the info in there. You can use its sort feature and build yourself a mini-database and whatnot. It's sort of like using excel except you're coding a program to interact with the data. Not sure, I hope this helps. Good luck!
-
Re: what's so great about classes?
Quote:
Originally Posted by
zero_coke
Yep, from the sound of what you're trying to do, it seems like you would need multiple classes with a common interface. Look up interfaces and how they can tie in multiple classes and allow you to extract information out of your many classes. That in my opinion is one approach, but like I said, you can also use inheritance or just build yourself a .net application with multiple datagridview controls and put the info in there. You can use its sort feature and build yourself a mini-database and whatnot. It's sort of like using excel except you're coding a program to interact with the data. Not sure, I hope this helps. Good luck!
oh great -- Interface -- another new buzzword :eek: gee, thks!
just kidding :)
-
Re: what's so great about classes?
Quote:
Originally Posted by
bergerkiller
Classes are nice for referenced data on the stack, but have you guys discussed the Structure type as well? :D
No, and we haven't discussed "referenced data on the stack" either. What the heck is that?
Quote:
I believe the main usage for classes is when you have to store "shared information" that has to be the same for multiple variables, like Item information.
This doesn't sound like it applies to my situation then. Today I need an application that retrieves certain columns of information (properties) about a set of customers that meet certain parameters. Tomorrow I need a new application because the set of properties I need to report is different, and the selection parameters are different... I don't see that I'm needing to share anything. So, if you're correct, maybe I don't need classes at all! What do you think?
-
Re: what's so great about classes?
Quote:
Originally Posted by
Jefals
No, and we haven't discussed "referenced data on the stack" either. What the heck is that?
An irrelevant implementation detail of the .NET framework.
If anyone starts talking about "stacks" and "heaps" when discussing the difference between classes and structures, then stop listening to them. It's not that they're wrong, but firstly, they're not 100% correct, and secondly, it doesn't matter. (And I am not going to confuse you with the differences between them that do matter at this stage.)
At your level, banish structures from your mind because they have subtly different characteristics that will cause you to chase your tail in bug hunting.
-
Re: what's so great about classes?
Quote:
Originally Posted by
bergerkiller
I believe the main usage for classes is when you have to store "shared information" that has to be the same for multiple variables, like Item information.
No. A class is a way of modelling your problem domain. I have written plenty of classes that contain only a single variable. I've written some that have exactly the same capabilities as the primitive type they're wrapping - and no, that's not a waste of time.
-
Re: what's so great about classes?
Quote:
Originally Posted by
Jefals
I've been thinking about this off and on now, and seems to me like, as with many things, there would be several ways to approach this. Remember the idea is that, today, a user comes to me and says, "Jeff, I need the name / address of all customers in the southeast".
Next week, it's "Jeff I need all residential customers in the company with good credit. I need their name/address, and credit score". After that it might be, "Jeff, I need name/address/credit score and date of last purchase, for all customers in the Northeast with annual sales over $5,000".
So, I never know what I'm going to need to extract, and what the parameters are going to be -- but, I know that somehow if I can build some common functionality that might just need a little "tweaking", it will make my life easier.
Based on what I've learned from you guys so far, I think I would consider each of these requests as a separate application, although I might start one application by copying what I've already done on one of the prior ones.
Or I might just add functions to my class of customers to extract, based on the different parameters, and then my modules would call whatever function was appropriate.
And now with what I think I'm learning from you re. inheritance, I might use that to get the customers I need.
Anyway, I think this is all a lot clearer to me now after this discussion -- UNLESS my mind is totally muddled and you guys tell me I actually haven't got a CLUE what I'm talking about! :sick:
I think you're actually using the wrong tool for the job. Sounds to me that you'd be best off with a report generating tool and some a SQL query for each report.
-
Re: what's so great about classes?
Quote:
Originally Posted by
Evil_Giraffe
I think you're actually using the wrong tool for the job. Sounds to me that you'd be best off with a report generating tool and some a SQL query for each report.
You're absolutely correct, and I know it. I started this to try and understand classes. Ignoring that it's the wrong tool, -- let's say that there are just a few customers that fit each scenario and maybe our marketing folks who make these requests to me, want to scroll thru these accounts so they can decide if they want to call them and offer them a special promotion or something.
In the couple of days this thread has been going, and with all the input from you guys, and more studying I've been doing some of which involved education at some of the sites folks here have recommended, I think I've got the fundamentals down. There are a bunch of details that still have to float around the brain cells for a while, and just need me to practice with -- ideas like protected variables, friend functions, shared functions -- but I understand the concepts now, so that was my goal all along.
Without getting too crazy, I can't really tell you how valuable I think these forums are, and how much I appreciate everyone that takes their time to educate us "newbies"...Sincere thanks to all of you!
-
Re: what's so great about classes?
Learning OO programming by attempting to apply the principles to a problem to which they are ill-suited seems somewhat dubious. Part of the skill in OO (and, in fact, any technique) is knowing when not to use it.
-
Re: what's so great about classes?
Learning OO programming by attempting to apply the principles to a problem to which they are ill-suited seems somewhat dubious. Part of the skill in OO (and, in fact, any technique) is knowing when not to use it.
Wouldn't you agree, that this scenario would make sense given the revision I mentioned? Namely, this is a user interface; the user enters a few parameters the describe which customers she wants returned -- and only a handful -- say 3 or 4 -- will meet the criteria. So, their info. shows up, one customer at a time, in text boxes on her screen. Any reason why a VB interface wouldn't make sense for that?
-
Re: what's so great about classes?
No, but "VB" is not the same as "modelling your problem domain with classes"
The revision you described would probably be best coded as selecting the report they want from a menu or some such, running some SQL on the database, getting back a dataset that you bind to a gridview.
It's still a report no matter how you dress it up. You certainly don't need a "Customer" class for this.
However, if we consider this in the context of a larger application, such as a Customer Relations Manager system, it would absolutely make sense to have a Customer class, and to have ways of searching for customers that fit certain criteria. You would have behaviour associated with the Customer class, however, and screens for interacting with the Customer instances. As described, you are still talking about a flat report with no associated domain behaviour - just scrolling through the data.
-
Re: what's so great about classes?
Quote:
Originally Posted by
Evil_Giraffe
No, but "VB" is not the same as "modelling your problem domain with classes"
The revision you described would probably be best coded as selecting the report they want from a menu or some such, running some SQL on the database, getting back a dataset that you bind to a gridview.
It's still a report no matter how you dress it up. You certainly don't need a "Customer" class for this.
Well, then, let me try this;
Other than as an educational exercise, would you use visual basic to find out if a dog can bark or how many legs he has?
Or to write Hello World to your PC?:)
-
Re: what's so great about classes?
I'm not saying don't use classes. I'm saying that all the scenarios presented thus far are not the strong suit of OO, and would be where you should drop down to SQL and use the set based logic available there.
In a larger system where other behaviour was already attached to the concept of a Customer, you might want to put in a O/R mapping layer (either hand rolled or using an O/RM tool such as NHibernate, Linq2SQL, Entity Framework), but for the reports you're talking about you'd just have to subsequently pull out all the properties into a tabular format anyway, so it seems like a useless (actually, harmful) abstraction.
-
Re: what's so great about classes?
Quote:
Originally Posted by
Jefals
Well, then, let me try this;
Other than as an educational exercise, would you use visual basic to find out if a dog can bark or how many legs he has?
Or to write Hello World to your PC?:)
If introducing the concept of a Dog, a Bark, or a Leg helped me, then yes I would model them with classes.
Going back to your original question: "What's so great about classes?"
The answer is: it allows the modelling of concepts in your problem domain that gives you a higher level language with which to program.
If you don't need the concept (and slinging some data from a database onto a grid view does not need the concept of a customer) then that benefit isn't really helpful, so in those circumstances, the answer, really, is "not so much".
-
Re: what's so great about classes?
Quote:
If introducing the concept of a Dog, a Bark, or a Leg helped me, then yes I would model them with classes.
No you wouldn't; remember, my qualifier -- "other than for educational purposes" -- what other purpose could you possibly have for this scenario!
And this was the same purpose I introduced my customer situation. Well, you can respond or not, but that's the last I've got to say on the subject -- I got what I needed from this thead a long time ago; although, I'm keeping an open mind to the fact that someday I may wake up and say, "You know NOW I understand what Evil-Giraffe was trying to tell me!"
-
Re: what's so great about classes?
Quote:
Originally Posted by
Jefals
No you wouldn't; remember, my qualifier -- "other than for educational purposes" -- what other purpose could you possibly have for this scenario!
"
You'd be surprised. I thought that some of those examples were contrived back when I was first reading about OO design in the 90s. In fact, there were magazine articles that made the point you have made a couple of times here about how some of these examples have no real world application. So then I made one.
The design was aquatic organisms in a lake. So I had a class for Fish, with child classes called things like Bass, Pike, and Sunfish. They had methods such as Swim. It was nearly a stereotypical OO example, yet it had practical application.
So, as trite as the example may appear, it isn't true that they won't have real world application.
-
Re: what's so great about classes?
I'll minimize the stack stuff, but you do have to know this since it can be to your benefit, or not. Classes are referenced; when you set a class type it copies the pointer. Therefore, this is possible:
Code:
Public Class test
Public member As Integer
End Class
Private _myclass As New test
Public ReadOnly Property MyClass() As test
Get
Return Me._myclass
End Get
End Property
The property does not return a new instance of test, like a structure would, but it returns (a pointer to) _myclass. Therefore, _myclass.member is now 2.
The only thing I like about classes is this. This way you can hold your information without anyone able to break it, for example, if the class needs a special initialization. For other things I usually use structures, since it does the opposite. For example, if you change the a member of a parameter of a function it would change it for real if you'd use a class, with a structure you won't have this:
Code:
Public Sub changetest(ByVal value As test)
value.member = 2
End Sub
Code:
Dim value As New test
value.member = 1
changetest(value)
'member is now two
If test was a structure this would not happen.
Plus a class requires initialization (new <>), structure members can be set without this requirement.
You can neglect this difference, but one time in the future you will encounter it. :bigyello:
-
Re: what's so great about classes?
Quote:
Originally Posted by
bergerkiller
I'll minimize the stack stuff, but you do have to know this since it can be to your benefit, or not. Classes are referenced; when you set a class type it copies the pointer.
...
You can neglect this difference, but one time in the future you will encounter it. :bigyello:
Yes, the difference between reference semantics and value semantics is the more important difference between classes and structs (although it is perfectly possible to have immutable classes that then behave like value types).
That's why I suggested avoiding structures until the OP was a bit further into OO. One of the major problems with structures is that if they're not immutable then you can really get yourself in a pickle, in situations just like the one you posted :)
-
Re: what's so great about classes?
Quote:
Originally Posted by
Jefals
No you wouldn't; remember, my qualifier -- "other than for educational purposes" -- what other purpose could you possibly have for this scenario!
How about a dog simulation? I am hugely confident that if you looked in the source of Nintendogs, you would find a class called Dog and a class called Bark.
Leg? Maybe not.
A vetinary system would probably have a class called Dog deriving from the more general Animal class that held data and behaviour specific to Dogs rather than other animals.
