Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: C#
Why do some people write this:
 

 public class NotifyObject
    {
        public NotifyObject(string message, string title)
        {
            this.message = message;
            this.title = title;
        }
 
        private string title;
        public string Title
        {
            get { return this.title; }
            set { this.title = value; }
        }
 
        private string message;
        public string Message
        {
            get { return this.message; }
            set { this.message = value; }
        }
 
        private int forbedringsnr;
        public int forberingsNr
        {
            get { return this.forbedringsnr; }
            set { this.forbedringsnr = value; }
        }
    }
 
instead of this:
public class NotifyObject2
    {
        public NotifyObject2(string message, string title, int forbedringsnr)
        {
            this.message = message;
            this.title = title;
            this.forbedringsnr = forbedringsnr;
        }
        public string message;
        public string title;
        public int forbedringsnr;
    }
 
It just makes a score in the linecount, and clutters up the code i think
Posted 26-Nov-12 9:33am
MrDeej798
Edited 26-Nov-12 10:48am
CPallini296.6K
v2
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

Why not write your code like this:
 
public class NotifyObject3
    {
        public NotifyObject3(string message, string title)
        {
            this.Message = message;
            this.Title = title;
        }
 
        public string Title {get; set;}
 
        public string Message{get; set;}
 
    }
 
Its generally better to use properties instead of public fields so that if you need to add validation or any other code around the setter you won't break binary compatibility with the previous version by having to change from a field to a property.
  Permalink  
v2
Comments
Sergey Alexandrovich Kryukov at 26-Nov-12 17:51pm
   
Right, but you should not limit it with the code "around setter", it could be also "around getter". And also OP wanted to use "forbedringsnr" -- same thing. Additionally, either "get" or "set" could be excluded, to make read-only or write-only. In the constructor, only minimally required parameters should be added. This code is no more cluttered then OP's, but better, by those reasons. (I voted 4.) --SA
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 2

In .Net, both C# and VB, the two forms you give and the one offered by BC @ CV in Solution 1 all compile to exactly the same intermediate code: you end up with a private allocation for the value and wrappers implementing the get and set property calls.
 
Of those three techniques, I prefer the first you you gave. Since the Framework will create the private variable declarations anyway, explicitly declaring them allows me to have some control over them. Because I made the variable declarations, I can squeeze out a bit of performance by using the variable directly, internal to the class: using your second method, or the one BC @ CV noted, requires always going through the wrappers.
 
If I wanted to add validation or additional processing later, I can do that easily without having to rewrite the code. If a property is a List, for example, I can check to see if the object is instantiated in the get and created if not; that way, the property will never, ever return a null value. Or perhaps on the set needs to validate against a list of options and determine if the value is in range or not. With text properties, I will usually call Trim to get rid of extraneous white space before storing the value. That sort of thing.
 
Rather than have different ways of declaring properties, I stick with the one technique that offers the most benefit, which is the fully explicit one. That makes it easy for me to find stuff when I come back to the code months or years later.
  Permalink  

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Your Filters
Interested
Ignored
     
0 Shai Vashdi 1,518
1 Tadit Dash 350
2 Manas Bhardwaj 319
3 OriginalGriff 243
4 Sergey Alexandrovich Kryukov 240
0 Sergey Alexandrovich Kryukov 9,530
1 OriginalGriff 5,716
2 Peter Leow 4,320
3 Maciej Los 3,540
4 Abhinav S 3,373


Advertise | Privacy | Mobile
Web02 | 2.8.140415.2 | Last Updated 26 Nov 2012
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Use
Layout: fixed | fluid