Could you just define the properties as byte ( Unsigned 8-bit integer ) ?
The best way to do this is by creating a 'ColorValue' class.
something like thisCode - C#: [Select]
class ColorValue{..}
It's deemed good practice wrap a primitive type like this when you would use it as a 'type' in your program and only use primitive types like int, string etc within methods for calculations (within a small scope and not public throughout your app).
You may also need to write ToString() and other interface methods etc as needed.
Could you just define the properties as byte ( Unsigned 8-bit integer ) ?
Could you just define the properties as byte ( Unsigned 8-bit integer ) ?
good point, would that truncate the value on both sides or throw an exception at runtime? For example, if a user enters a larger value at a prompt?
12. A company dealing with marketing wants to keep a data record of its employees.So I guess that would mean wrapping the Employee struct within a Employess class, along with a List<Employee> to iterate through due the ID validation ?
Each record should have the following characteristic – first name, last name, age, gender (‘m’ or ‘f’) and unique employee number (27560000 to 27569999).
Declare appropriate variables needed to maintain the information for an employee by using the appropriate data types and attribute names.
I see no reason to use a struct in this case, especially given the amount of different data types and validation required.
You can then wrap the Employee in a 'Employees' class that would hold the list of Employee and would create the ID when adding a new Employee.
Something like this perhaps?Code - C#: [Select]
class Employee{ ... } class Employees { ... }
I think structs are handy and lightweight when you need something like a coordinate or similar where there is a small group of similar data. If you need to do work on coordinates then it would be easier to create a class so you can do vector calculations etc.
You very rarely see structs in the wild :)
You shouldn't need overloaded constructors, one would do (that asks for all values as you have).
The exercise requirement of creating an Employee is a bit out of context to the lesson (not that I really read it :) ) in that it's trying to teach using the right types, not business logic. In the real world you would probably have a user form or web site form to fill in this data and that's where I would do the parsing and validation (behind each text box) before I even create an Employee.
The ID wouldn't be part of this form and would most likely be created when storing the Employee data to the database by creating an auto-incremented Primary Key.
When you add the Employee to the db you would get back the ID from the db and you can assign it then via property setter if you still need to use the Employee class for a bit.
In light of all that you could probably just use a struct as all your logic is handled elsewhere and there's no calculations or other real methods required within the class :)