-
Jan 26th, 2018, 03:49 PM
#1
Thread Starter
Addicted Member
[RESOLVED] Properties, Enumeration, & Constructors
Im doing step by step..My instructions are:
The GroceryItem class should contain the following public properties:
1. ScanNumber - Represents the unique serial code for the item on the shelf. This property should be read-only.
2. BrandName - The name as described on the item’s packaging
3. Description - A short description of the item
4. Price - The amount of money it costs to buy the item. Make sure that only positive values can be assigned to this property.
5. Aisle - This should indicate one of the following aisles: Bakery, CannedGoods, Drinks, Deli, DryGoods, FrozenFoods, and Produce.
This is my Grocery Item code:
Code:
Public Class GroceryItem
Public ReadOnly Property ScanNumber As Integer
Get
Return ScanNumber
End Get
End Property
Public Property BrandName As String
Get
Return BrandName
End Get
Set (value As String)
BrandName = value
End Set
End Property
Public Property Description As String
Get
Return Description
End Get
Set (value As String)
Description = value
End Set
End Property
Public Property Price As Integer
Get
Return Price
End Get
Set (value As Integer)
Price = value
End Set
End Property
Public Property Aisle As String
Get
Return Aisle As String
End Get
Set (value As String)
Aisle = value
End Set
End Property
End Class
It says you can use enumeration.
The GroceryItem class should contain the following public constructors:
1. A constructor that accepts and sets only the ScanNumber property. Remember: If a property is read-only, then you’ll need to set the variable, not use the property name.
2. A constructor that accepts and sets the ScanNumber, BrandName and Price properties.
Add a new public class named GroceryBasket to the project.
1. Derive from the generic List class.
2. Ensure that only GroceryItem objects are stored as items.
Add the following variable declaration to the Main module: Friend basket As New GroceryBasket
My Main Code:
Code:
Module Main
Friend blnLoggedIn As Boolean
Dim arrUsernames() As String = {"Admin", "Clerk", "Manager"}
Dim arrPasswords() As String = {"P@ssword", "pa$$word", "passw0rd"}
Dim userIndex As Integer
Friend basket As New GroceryBasket
Test your work.
Note: You can add code to the btnLogin_Click event handler procedure to instantiate the GroceryItem class and add multiple objects to the GroceryBasket variable. Make sure you either remove or comment out this code after testing.
Last edited by EmilyM1105; Jan 27th, 2018 at 04:36 AM.
-
Jan 26th, 2018, 04:24 PM
#2
Re: Properties, Enumeration, & Constructors
You've got a spurious End Class in the middle of your GroceryItem class. That will certainly mess things up.
Also, while you may be able to get away with assuming the default for a property is Public, it isn't a sound practice, so I agree with Sitten in the other thread that you should explicitly state Public, even if it is the default.
Most likely, the point was not to have you use the default implementation of the properties, anyways, but to spell them out. Therefore, you need variables for each of the properties. Sitten showed that using underscores, but I personally hate underscores because of where they are located on the keyboard (two rows up on the weakest finger). Therefore, I would write one of the properties like this:
Code:
Private mBrandName as String
Public Property BrandName As String
Get
Return mBrandName
End Get
Set (value As String)
mBrandName = value
End Set
End Property
Much of that gets filled out as soon as you type the Get.
As for constructors, that's just Public Sub New(), with whatever arguments you need. Looks like you need two of them: One that takes one argument and one that takes three.
My usual boring signature: Nothing
-
Jan 26th, 2018, 04:46 PM
#3
Thread Starter
Addicted Member
Re: Properties, Enumeration, & Constructors
Originally Posted by Shaggy Hiker
You've got a spurious End Class in the middle of your GroceryItem class. That will certainly mess things up.
Also, while you may be able to get away with assuming the default for a property is Public, it isn't a sound practice, so I agree with Sitten in the other thread that you should explicitly state Public, even if it is the default.
Most likely, the point was not to have you use the default implementation of the properties, anyways, but to spell them out. Therefore, you need variables for each of the properties. Sitten showed that using underscores, but I personally hate underscores because of where they are located on the keyboard (two rows up on the weakest finger). Therefore, I would write one of the properties like this:
Code:
Private mBrandName as String
Public Property BrandName As String
Get
Return mBrandName
End Get
Set (value As String)
mBrandName = value
End Set
End Property
Much of that gets filled out as soon as you type the Get.
As for constructors, that's just Public Sub New(), with whatever arguments you need. Looks like you need two of them: One that takes one argument and one that takes three.
Where did mBrandName come from??
-
Jan 26th, 2018, 05:02 PM
#4
Re: Properties, Enumeration, & Constructors
My own head.
Prior to 2010, that was the only way you could write a property. You had to first declare a variable, then expose that variable via the property, so you had to write it like that. You wrote the variable, then wrote the getter and setter. There were no shortcuts.
Starting with 2010, you could make a shortcut if you wanted a full property (as opposed to ReadOnly or WriteOnly). What you wrote was essentially the shortcut, except that you HAD to have Public/Private/Protected, or Friend as an access qualifier. You STILL had to write out ReadOnly properties, though.
Starting sometime later, perhaps 2013 or 2015, VS was changed such that you didn't have to write out ReadOnly properties, either, which is what you are showing with your properties. There is still a variable hidden behind those properties, you just don't see it anymore because there isn't an explicit Get or Set block. You can't always use that simpler version of properties, though, so you can still write it out the old way, as I showed, because you HAVE to do that if you are doing more with either the Get or Set block.
For example, I might have a class with a Count property. There isn't some variable back there holding the count, the Get block might look like this:
Code:
Get
Return someCollection.Count
End Get
The property isn't just returning some value it is holding, it will check how many items are in someCollection, and return that number whenever the property is accessed. Also, there wouldn't be any point to a Set block in such a property, because what would that even mean?
Another example is a class I have where you can set the current time. In the setter, I check to see whether the time being set is the current time, or some other time, and raise various events in either case. In other words, when the user sets the time, the class sends out alerts to other parts of the program to let them know that they need to do something. The default property wouldn't know to do that, so I had to go old-school and write my own Set method.
My usual boring signature: Nothing
-
Jan 26th, 2018, 05:16 PM
#5
Thread Starter
Addicted Member
Re: Properties, Enumeration, & Constructors
Originally Posted by Shaggy Hiker
My own head.
Prior to 2010, that was the only way you could write a property. You had to first declare a variable, then expose that variable via the property, so you had to write it like that. You wrote the variable, then wrote the getter and setter. There were no shortcuts.
Starting with 2010, you could make a shortcut if you wanted a full property (as opposed to ReadOnly or WriteOnly). What you wrote was essentially the shortcut, except that you HAD to have Public/Private/Protected, or Friend as an access qualifier. You STILL had to write out ReadOnly properties, though.
Starting sometime later, perhaps 2013 or 2015, VS was changed such that you didn't have to write out ReadOnly properties, either, which is what you are showing with your properties. There is still a variable hidden behind those properties, you just don't see it anymore because there isn't an explicit Get or Set block. You can't always use that simpler version of properties, though, so you can still write it out the old way, as I showed, because you HAVE to do that if you are doing more with either the Get or Set block.
For example, I might have a class with a Count property. There isn't some variable back there holding the count, the Get block might look like this:
Code:
Get
Return someCollection.Count
End Get
The property isn't just returning some value it is holding, it will check how many items are in someCollection, and return that number whenever the property is accessed. Also, there wouldn't be any point to a Set block in such a property, because what would that even mean?
Another example is a class I have where you can set the current time. In the setter, I check to see whether the time being set is the current time, or some other time, and raise various events in either case. In other words, when the user sets the time, the class sends out alerts to other parts of the program to let them know that they need to do something. The default property wouldn't know to do that, so I had to go old-school and write my own Set method.
Ok I changed it up top..Is that right so far?
-
Jan 26th, 2018, 05:33 PM
#6
Re: Properties, Enumeration, & Constructors
Yes, that'll do. It isn't clear whether you HAVE to write out the properties in the old-school style, but it does seem like the professor is likely looking for that....or not, I'm not sure. This may just be my bias. I almost always write out properties, and have only started using the shorthand way that you had initially in some newer stuff. I always write out ReadOnly properties in all cases. It doesn't hurt anything...unless you are getting graded on it. You'd have to decide whether the professor wants to see the long version of the properties, or doesn't care which you use.
My usual boring signature: Nothing
-
Jan 26th, 2018, 05:36 PM
#7
Thread Starter
Addicted Member
Re: Properties, Enumeration, & Constructors
Originally Posted by Shaggy Hiker
Yes, that'll do. It isn't clear whether you HAVE to write out the properties in the old-school style, but it does seem like the professor is likely looking for that....or not, I'm not sure. This may just be my bias. I almost always write out properties, and have only started using the shorthand way that you had initially in some newer stuff. I always write out ReadOnly properties in all cases. It doesn't hurt anything...unless you are getting graded on it. You'd have to decide whether the professor wants to see the long version of the properties, or doesn't care which you use.
Thats why I asked where that came from because the instructions I posted up there are the EXACT instructions from my instructor..It doesnt say anything about doing that..Also Im using VB2017..So maybe I should stick to what hes asking...If I do how should I write it then?
-
Jan 26th, 2018, 06:07 PM
#8
Re: Properties, Enumeration, & Constructors
The way you had it originally, except that I do think that adding the Public access qualifier at the beginning is a good idea. I still use VS2010 for lots of stuff, so I often forget that you don't have to write out ReadOnly properties anymore, but in 2017 you do not.
My usual boring signature: Nothing
-
Jan 27th, 2018, 04:13 AM
#9
Thread Starter
Addicted Member
Re: Properties, Enumeration, & Constructors
Originally Posted by Shaggy Hiker
The way you had it originally, except that I do think that adding the Public access qualifier at the beginning is a good idea. I still use VS2010 for lots of stuff, so I often forget that you don't have to write out ReadOnly properties anymore, but in 2017 you do not.
Ok so I updated my code up top..Is it right? According to the directions? Thanks!
-
Jan 27th, 2018, 02:14 PM
#10
Re: Properties, Enumeration, & Constructors
I thought you were not going to write out the properties?
My usual boring signature: Nothing
-
Jan 27th, 2018, 08:55 PM
#11
Re: Properties, Enumeration, & Constructors
Originally Posted by EmilyM1105
Ok so I updated my code up top
I would suggest that you don't do that. It will confuse people who come in part way through the thread and it means that noone can see what you've actually changed along the way.
-
Jan 29th, 2018, 02:14 PM
#12
Thread Starter
Addicted Member
Re: Properties, Enumeration, & Constructors
Originally Posted by Shaggy Hiker
I thought you were not going to write out the properties?
So I dont have to write Get and Set statements?
-
Jan 29th, 2018, 02:25 PM
#13
Re: Properties, Enumeration, & Constructors
It's entirely up to you, I just thought you felt that the professor would not want you to. There's no advantage to one over the other as far as performance goes. As long as you know that you can do either, that's probably all that matters.
My usual boring signature: Nothing
-
Jan 29th, 2018, 03:46 PM
#14
Thread Starter
Addicted Member
Re: Properties, Enumeration, & Constructors
Nevermind im sorry you were right about:
Code:
Private mBrandName as String
Public Property BrandName As String
Get
Return mBrandName
End Get
Set (value As String)
mBrandName = value
End Set
End Property
-
Jan 31st, 2018, 09:50 AM
#15
Re: Properties, Enumeration, & Constructors
Originally Posted by EmilyM1105
Nevermind im sorry you were right about :
Code:
Private mBrandName as String
Public Property BrandName As String
Get
Return mBrandName
End Get
Set (value As String)
mBrandName = value
End Set
End Property
Does your post above mean that the long way of defining a Property is what your instructor is expecting? If so, then your code at the very top in your first post looks somewhat ok, you just need to create a variable for the rest of the Properties, like you show above with mBrandName. Probably a good idea to just name these variables with the same format "mPropertyName", like mScanNumber, mDescription, etc, making sure the variable is of the same type as the Property (Integer variable for Integer Property, for example). And don't forget that in the other Properties, your Set statement need to be setting this "mPropertyName" variable = value.
So lets look at your Price property. I would suggest changing the type from Integer to Double, since prices can be in dollars and cents, not just whole dollars.
Code:
Private mPrice As Double
Public Property Price As Double
Get
Return mPrice
End Get
Set (value As Double)
mPrice = value
End Set
End Property
The instructions say to ensure that only positive values can be assigned to the price. When your Property has limitations on what values can be used, the way to test for this is with appropriate logic inside of the Properties Set statement. I'll show you a similar example. Imagine that we had created a Class that stores information about people. And one of the Properties of this Class is the person's Age. You would agree that a person's age can't be negative, and there is also some upper limit to where above that number a person's age doesn't make sense.
Example: Replace an invalid age with the closest valid value:
Code:
Private mAge As Integer
Private minAge As Integer = 0
Private maxAge As Integer = 140
Public Property Age As Integer
Get
Return mAge
End Get
Set (value As Integer)
If value < minAge Then
mAge = minAge
ElseIf value > maxAge Then
mAge = maxAge
Else
mAge = value
End If
End Set
End Property
There are other ways of handling an invalid property value being passed, like displaying a Messagebox to the user:
Code:
Set (value As Integer)
If value < minAge OrElse value > maxAge Then
MessageBox.Show("Invalid Age", "Error")
Else
mAge = value
End If
End Set
or Throwing a custom exception:
Code:
Set (value As Integer)
If value < minAge OrElse value > maxAge Then
Throw New AgeException("Invalid Age")
Else
mAge = value
End If
End Set
Notice that in those last two examples, in the case of an invalid age we're not setting mAge to anything. That should demonstrate to you how to add logic to a Set statement to ensure that the value passed to the property is valid, and some different ways of handling it if it isn't valid.
-
Jan 31st, 2018, 03:43 PM
#16
Thread Starter
Addicted Member
Re: Properties, Enumeration, & Constructors
Originally Posted by OptionBase1
Does your post above mean that the long way of defining a Property is what your instructor is expecting? If so, then your code at the very top in your first post looks somewhat ok, you just need to create a variable for the rest of the Properties, like you show above with mBrandName. Probably a good idea to just name these variables with the same format "mPropertyName", like mScanNumber, mDescription, etc, making sure the variable is of the same type as the Property (Integer variable for Integer Property, for example). And don't forget that in the other Properties, your Set statement need to be setting this "mPropertyName" variable = value.
So lets look at your Price property. I would suggest changing the type from Integer to Double, since prices can be in dollars and cents, not just whole dollars.
Code:
Private mPrice As Double
Public Property Price As Double
Get
Return mPrice
End Get
Set (value As Double)
mPrice = value
End Set
End Property
The instructions say to ensure that only positive values can be assigned to the price. When your Property has limitations on what values can be used, the way to test for this is with appropriate logic inside of the Properties Set statement. I'll show you a similar example. Imagine that we had created a Class that stores information about people. And one of the Properties of this Class is the person's Age. You would agree that a person's age can't be negative, and there is also some upper limit to where above that number a person's age doesn't make sense.
Example: Replace an invalid age with the closest valid value:
Code:
Private mAge As Integer
Private minAge As Integer = 0
Private maxAge As Integer = 140
Public Property Age As Integer
Get
Return mAge
End Get
Set (value As Integer)
If value < minAge Then
mAge = minAge
ElseIf value > maxAge Then
mAge = maxAge
Else
mAge = value
End If
End Set
End Property
There are other ways of handling an invalid property value being passed, like displaying a Messagebox to the user:
Code:
Set (value As Integer)
If value < minAge OrElse value > maxAge Then
MessageBox.Show("Invalid Age", "Error")
Else
mAge = value
End If
End Set
or Throwing a custom exception:
Code:
Set (value As Integer)
If value < minAge OrElse value > maxAge Then
Throw New AgeException("Invalid Age")
Else
mAge = value
End If
End Set
Notice that in those last two examples, in the case of an invalid age we're not setting mAge to anything. That should demonstrate to you how to add logic to a Set statement to ensure that the value passed to the property is valid, and some different ways of handling it if it isn't valid.
ok so I have made some changes.. How does this look so far?
This is my Grocery Item code:
Code:
Public Class GroceryItem
Public ReadOnly Property ScanNumber As Integer
Get
Return ScanNumber
End Get
End Property
Private mBrandName As String
Public Property BrandName As String
Get
Return mBrandName
End Get
Set(value As String)
mBrandName = value
End Set
End Property
Private mDescription As String
Public Property Description As String
Get
Return mDescription
End Get
Set(value As String)
mDescription = value
End Set
End Property
Private mPrice As Double
Public Property Price As Double
Get
Return mPrice
End Get
Set(value As Double)
If value > 0 Then
mPrice = value
End If
End Set
End Property
Private mAisle As String
Public Property Aisle As String
Get
Return mAisle
End Get
Set(value As String)
mAisle = value
End Set
End Property
End Class
So for price It doesnt tell me anything about a price limit in the instructions?? so how would I know what to use on the part where I say what happens if the price reaches a limit??
Last edited by EmilyM1105; Jan 31st, 2018 at 04:03 PM.
-
Jan 31st, 2018, 04:03 PM
#17
Re: Properties, Enumeration, & Constructors
The only issue I see is in the ScanNumber property. Although it is read-only, you still want a Private variable to hold what that value is, and then return the contents of that variable.
Code:
Private mScanNumber As Integer
Public ReadOnly Property ScanNumber As Integer
Get
Return mScanNumber
End Get
End Property
The rest looks good!
-
Jan 31st, 2018, 04:16 PM
#18
Thread Starter
Addicted Member
Re: Properties, Enumeration, & Constructors
Originally Posted by OptionBase1
The only issue I see is in the ScanNumber property. Although it is read-only, you still want a Private variable to hold what that value is, and then return the contents of that variable.
Code:
Private mScanNumber As Integer
Public ReadOnly Property ScanNumber As Integer
Get
Return mScanNumber
End Get
End Property
The rest looks good!
ok So heres the update lol:
Code:
Public Class GroceryItem
Private mScanNumber As Integer
Public ReadOnly Property ScanNumber As Integer
Get
Return mScanNumber
End Get
End Property
Private mBrandName As String
Public Property BrandName As String
Get
Return mBrandName
End Get
Set(value As String)
mBrandName = value
End Set
End Property
Private mDescription As String
Public Property Description As String
Get
Return mDescription
End Get
Set(value As String)
mDescription = value
End Set
End Property
Private mPrice As Double
Public Property Price As Double
Get
Return mPrice
End Get
Set(value As Double)
If value > 0 Then
mPrice = value
End If
End Set
End Property
Private mAisle As String
Public Property Aisle As String
Get
Return mAisle
End Get
Set(value As String)
mAisle = value
End Set
End Property
End Class
So what number on the instructions up top do you think im on now??...I was confused on this part??
Aisle - This should indicate one of the following aisles: Bakery, CannedGoods, Drinks, Deli, DryGoods, FrozenFoods, and Produce.
It says you can use enumeration?
Last edited by EmilyM1105; Jan 31st, 2018 at 04:35 PM.
-
Jan 31st, 2018, 04:36 PM
#19
Re: Properties, Enumeration, & Constructors
There are several ways that you could set up the Aisle property. There are pros and cons to all of them, some involve more lines of code, like using an enumeration, and more complex code. The way you've done it by defining Aisle as a String is probably the easiest way to do it. You would then assign an aisle to it like this:
Code:
myGroceryItem.Aisle = "Bakery"
Note, however, that the way the Aisle property is configured, there's nothing stopping you from assigning a product to an Aisle not in the list, like this:
Code:
myGroceryItem.Aisle = "AisleThatDoesNotExist"
but the instructions you posted didn't specify that you need to worry about that.
So I would say you are up to the point where you need to set up the 2 Constructors.
-
Feb 1st, 2018, 12:41 AM
#20
Thread Starter
Addicted Member
Re: Properties, Enumeration, & Constructors
Originally Posted by OptionBase1
There are several ways that you could set up the Aisle property. There are pros and cons to all of them, some involve more lines of code, like using an enumeration, and more complex code. The way you've done it by defining Aisle as a String is probably the easiest way to do it. You would then assign an aisle to it like this:
Code:
myGroceryItem.Aisle = "Bakery"
Note, however, that the way the Aisle property is configured, there's nothing stopping you from assigning a product to an Aisle not in the list, like this:
Code:
myGroceryItem.Aisle = "AisleThatDoesNotExist"
but the instructions you posted didn't specify that you need to worry about that.
So I would say you are up to the point where you need to set up the 2 Constructors.
So would I have to do this for each Aisle?
Code:
myGroceryItem.Aisle = "Bakery"
Also, I thought that the constructors is what was in my GroceryItem code with Get & Set statements?? So constructors are something different?
-
Feb 1st, 2018, 01:11 AM
#21
Re: Properties, Enumeration, & Constructors
Originally Posted by EmilyM1105
Also, I thought that the constructors is what was in my GroceryItem code with Get & Set statements?? So constructors are something different?
The code with the Get an Set are properties.
A constructor in VB is a method named New. When you use the New keyword in code to create an instance of a type, you are invoking a constructor. Every type has a parameterless constructor by default, which would be the equivalent of this:
If you add a constructor yourself then that default constructor is removed, so if you add a constructor with parameters and you want a parameterless constructor too then you must add both.
-
Feb 1st, 2018, 03:27 PM
#22
Thread Starter
Addicted Member
Re: Properties, Enumeration, & Constructors
Originally Posted by OptionBase1
There are several ways that you could set up the Aisle property. There are pros and cons to all of them, some involve more lines of code, like using an enumeration, and more complex code. The way you've done it by defining Aisle as a String is probably the easiest way to do it. You would then assign an aisle to it like this:
Code:
myGroceryItem.Aisle = "Bakery"
Note, however, that the way the Aisle property is configured, there's nothing stopping you from assigning a product to an Aisle not in the list, like this:
Code:
myGroceryItem.Aisle = "AisleThatDoesNotExist"
but the instructions you posted didn't specify that you need to worry about that.
So I would say you are up to the point where you need to set up the 2 Constructors.
Do I write those constructors under my properties??
Like this?
Code:
Public Sub New(mScanNumber As Integer, Brandname As String, Price As Double)
Me.mScanNumber = Number
Me.Brandname = Brandname
Me.Price = Number
End Sub
Did I do that right?
-
Feb 1st, 2018, 06:34 PM
#23
Re: Properties, Enumeration, & Constructors
That's the general idea but your implementation isn't really correct there. For one thing, you're assigning Number twice but you have no Number parameter. If you have properties named 'ScanNumber', 'BrandName' and 'Price' then your constructor parameters should be 'scanNumber', 'brandName' and 'price':
vb.net Code:
Public Sub New(scanNumber As Integer, brandName As String, price As Double) Me.ScanNumber = scanNumber Me.BrandName = brandName Me.Price = price End Sub
-
Feb 2nd, 2018, 12:08 AM
#24
Thread Starter
Addicted Member
Re: Properties, Enumeration, & Constructors
Originally Posted by jmcilhinney
That's the general idea but your implementation isn't really correct there. For one thing, you're assigning Number twice but you have no Number parameter. If you have properties named 'ScanNumber', 'BrandName' and 'Price' then your constructor parameters should be 'scanNumber', 'brandName' and 'price':
vb.net Code:
Public Sub New(scanNumber As Integer, brandName As String, price As Double) Me.ScanNumber = scanNumber Me.BrandName = brandName Me.Price = price End Sub
ScanNumber is set as read only. So It keeps giving me an error message on the ScanNumber Part saying "it is ReadOnly"
Code:
Public Sub New(scanNumber As Integer, brandName As String, price As Double)
Me.ScanNumber = scanNumber
Me.BrandName = brandName
Me.Price = price
End Sub
Thats why I put Me.MScanNumber.. when I do that the error goes away.
Next is the instructions....
Add a new public class named GroceryBasket to the project.
1. Derive from the generic List class.
2. Ensure that only GroceryItem objects are stored as items.
Heres my GroceryBasket Code:
Code:
Public Class GroceryBasket
Inherits List(Of GroceryItem)
End Class
Is that right?? Sorry I had a hard time understanding this part
Last edited by EmilyM1105; Feb 2nd, 2018 at 12:23 AM.
-
Feb 2nd, 2018, 12:13 AM
#25
Re: Properties, Enumeration, & Constructors
Originally Posted by EmilyM1105
Oh ok I thought it had to be different because ScanNumber is read only??
If the property is ReadOnly then yes, you would have to set the backing field instead. I hadn't examined all previous posts so I didn't realise that that was the case.
Originally Posted by EmilyM1105
Is that all I have to do for the constructor instructions?
The constructor needs to contain all the code that needs to be executed when an object is created. Do you need to do anything other than set the property values when you create an object? If so, add code to do that. If not, don't.
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|