Question

have a php code like this,(part of the php function here)going to convert it in to C#.

function jaktDate2()
{
    Global $nameofselectbox,$startYear,$endYear,$year,
    $startDate,$endDate,$startMounth,$endMounth,$startDay,$endDay;
    $today = getdate();
    $year=$today['year'];
    $mounth=$today['mon'];
    $day=$today['mday'];

my C# code try is this,

  public class HuntingDate
    {
        public string StartYear;
        public string EndYear;
        public string Year;
        public DateTime StartDate;
        public DateTime EndDate;
        public string StartMonth;
        public string EndMonth;
        public DateTime StartDay;
        public DateTime EndDay;


    }

I’m starting this way.. is this way correct? What should i do next ?

Answer 1

The class you’re defining seems more like a random grab-bag of values and less like a well-defined class. What do all of these values actually represent?

public string StartYear;
public string EndYear;
public string Year;
public DateTime StartDate;
public DateTime EndDate;
public string StartMonth;
public string EndMonth;
public DateTime StartDay;
public DateTime EndDay;

For example, what is the difference between StartDate and StartDay? What are StartYear and StartMonth? What is this class actually defining? It looks like you’re trying to break up the DateTime values into components. You don’t need to do that. A simple DateTime value will sufficiently store the necessary information, and you can get the components directly from that value:

public DateTime StartDate;
public DateTime EndDate;

If you need to know the month, for example, you can get it from that value:

myObject.StartDate.Month;

To continue to improve the class, you’ll want to use properties instead of public members. In C#, those would look like this:

public DateTime StartDate { get; set; }
public DateTime EndDate { get; set; }

These are specifically called auto-implemented properties. They’re compiler short-hand for full properties:

private DateTime _startDate;
public DateTime StartDate
{
    get { return _startDate; }
    set { _startDate = value; }
}
// repeat for EndDate

The benefit of properties is that the class is exposing a little less about its internal structure. And if you need to add any logic to the class (such as checking specific bounds of the date, like making sure no StartDate is in the past) then you can add it to the properties without breaking the binary compatibility of the class. So consuming code never needs to know the difference. For example:

private DateTime _startDate;
public DateTime StartDate
{
    get { return _startDate; }
    set
    {
        if (value < DateTime.Now)
            throw new ArgumentException(string.Format("Start Date must not be in the past: {0}", value.ToString()));
        _startDate = value;
    }
}

You can continue to take this even further by continuing to define the behavior of this class. Even having these properties exposed still makes the class more of a “data structure” than an “object.” (For further reading on data/object anti-symmetry, I recommend Clean Code by Robert Martin.) The goal for a proper object-oriented design would be for the object to hide its data and expose methods that internally perform stateful actions on that data.

For example, if you needed to extend EndDate by a day, you could do this:

myObject.EndDate += new TimeSpan(1, 0, 0, 0);

But a more object-oriented approach (sticking with the “tell, don’t ask” principal) would be to tell the object itself to extend the time, not directly tell its data to extend the time (thereby “asking” the object for its data in the process, which arguably also violates the Law Of Demeter):

myObject.ExtendEndDate(new TimeSpan(1, 0, 0, 0));

or even:

myObject.ExtendEndDateInDays(1);

You would just need to implement such a method on the object, and that method would internally extend the value of EndDate.

The class itself should encapsulate all of the functionality necessary for the concept it represents. It can provide public read access to its internal members if absolutely necessary, but from a design perspective it’s worth asking yourself what kind of queries really need to be made against the object’s data and to provide more targeted methods for those queries, rather than direct access to the class’ data members.