-1

In Program, i'm writing on console the breed of a Dog.

Which is the best approach and why?

I suppose that the first way does less operations, but to do it, i have to declare the variable as public.

Is maybe a better choice to declare it private and return the data from a method like i did in the second writeline?

I would like to understand which kind of approach is the best considering every important aspect of a software

class Program
{
    static void Main(string[] args)
    {
        Dog fuffy = new Dog("Fuffy", "Armant");
        Console.WriteLine(fuffy.breed);
        Console.WriteLine(fuffy.getBreed());
    }
}


class Dog
{
    public string name;
    public string breed;

    public Dog(string name, string breed)
    {
        this.name = name;
        this.breed = breed;
    }

    public string getBreed()
    {
        return this.breed;
    }
}

Edit:

Is there a real difference between using the getter and this method?

Isn't the getter just an "hidden" way to write and execute that method?

Is a getter giving a better prestation compared to the method?

class Dog
{
    public string name { get; }
    public string breed { get; }

    public Dog(string name, string breed)
    {
        this.name = name;
        this.breed = breed;
    }

    public string getBreed()
    {
        return this.breed;
    }
}
Marco Salerno
  • 5,131
  • 2
  • 12
  • 32

5 Answers5

4

The "best" way is to use C# language features, i.e. properties:

class Dog
{
    public string Name {get;} // read-only property (can be set in constructor)
    public string Breed {get;}

    public Dog(string name, string breed)
    {
        this.Name = name;
        this.Breed = breed;
    }   
}
adjan
  • 13,371
  • 2
  • 31
  • 48
  • Not sure why this was downvoted, but the `{get;}` syntax is correct after C# 4.6 (maaaaybe 4.5.1). That makes it a readonly property being set within the constructor. – krillgar Aug 10 '17 at 13:51
  • @krillgar There is no C# 4.6. This is valid syntax as of C# 6 (which can target different .NET framework versions such as .NET 4.6). Admittedly these version numbers can be confusing since new framework versions often are released simultaneously with new compilers. – Kyle Aug 10 '17 at 14:07
  • @Kyle Yeah, my bad. I'm in the middle of doing a couple things and misspoke. Thanks for the correction. – krillgar Aug 10 '17 at 14:07
2

In C#, we have a language construct called properties, and I think they would be most appropriate here. Typically, properties are used to expose object state, preferred over methods, and they can be made read-only or read-write.

class Dog
{
    public string Name { get; private set; }
    public string Breed { get; private set; }

    public Dog(string name, string breed)
    {
        Name = name;
        Breed = breed;
    }
}

Properties in C# come in a lot of flavors, so I suggest reading up on them in the documentation.

FishBasketGordo
  • 22,904
  • 4
  • 58
  • 91
1

In general, methods represent actions and properties represent data. In this case, I would go with Property since the value of the property is stored in the process memory and the property just provides access to the value.

Use a property, rather than a method,

  • if the value of the property is stored in the process memory and the property would just provide access to the value.

Use a method, rather than a property, in the following situations.

  • The operation is orders of magnitude slower than a field set would be. If you are even considering providing an asynchronous version of an operation to avoid blocking the thread, it is very likely that the operation is too expensive to be a property. In particular, operations that access the network or the file system (other than once for initialization) should most likely be methods, not properties.
  • The operation is a conversion, such as the Object.ToString method.
  • The operation returns a different result each time it is called, even if the parameters do not change. For example, the NewGuid method returns a different value each time it is called.
  • The operation has a significant and observable side effect. Note that populating an internal cache is not generally considered an observable side effect.
  • The operation returns a copy of an internal state (this does not include copies of value type objects returned on the stack). The operation returns an array.

Read this article to get more information with code samples.

Choosing Between Properties and Methods

Sampath
  • 1,173
  • 18
  • 29
  • Yes. That is a really good article explains reasons with examples. – Sampath Aug 10 '17 at 14:05
  • @ono2012 Someone did think so. I recommend including some relevant bits from the link, in addition to your summary. (Why settle for an answer that is only "good enough?" :-) – jpaugh Aug 10 '17 at 18:02
  • @ono2012 Same. Sorry to drag you back to it. 2nd part of my comment was actually for the OP. Sampath, this is a poor-quality answer, but it is technically an answer, as [explained here](https://meta.stackexchange.com/questions/225370/your-answer-is-in-another-castle-when-is-an-answer-not-an-answer). You could make it much better by including more detail from the link. – jpaugh Aug 10 '17 at 18:20
  • Thanks, @ono2012 and jpaugh your feedback. I added more information from the article to the answer. – Sampath Aug 10 '17 at 18:57
0

You can use properties to encapsulate the fields.

    class Program
    {
        static void Main(string[] args)
        {
            Dog fuffy = new Dog("Fuffy", "Amarant");
            Console.WriteLine(fuffy.Name);
            Console.WriteLine(fuffy.Breed);
    }
}

class Dog
{
    private string name;
    public string Name
    {
        get { return name; }
        set { name = value; }
    }
    private string breed;
    public string Breed
    {
        get { return breed; }
        set { breed = value; }
    }
    public Dog(string pName, string pBreed)
    {
        Breed = pBreed;
        Name = pName;
    }
}
0

I would say that neither of them is "best", but I would use C#'s built-in properties:

public string Breed {get;set;}

If you wanted to prevent Breed being set, you can remove the set:

public string Breed {get;}

In your example, getBreed is read-only, equivalent to my second example.

Modify your class to look like this:

class Program
{
    static void Main(string[] args)
    {
        Dog fuffy = new Dog("Fuffy", "Armant");
        Console.WriteLine(fuffy.breed); //Prints Fuffy
        Console.WriteLine(fuffy.breed = "Muffy"); //Prints Muffy
        Console.WriteLine(fuffy.breed_readonly = "Muffy"); //World ends in exception
    }
}


class Dog
{
    public string name {get;set;}
    public string breed {get;set;}

    public string name_readonly {get;}
    public string breed_readonly {get;}

    public Dog(string name, string breed)
    {
        this.name = name;
        this.breed = breed;

        this.name_readonly = name;
        this.breed_readonly = breed;
    }
}
pookie
  • 3,796
  • 6
  • 49
  • 105