none
Trying to Understand OOP Programming Concepts RRS feed

  • Question

  •  Like most new developers I often use public static variables as globals throughout a project because I don't really understand true OOP concepts. Thus I'm spending time today to educate myself on the subject. Here is a simple class I'm going to be using and my question is about the set;get; statements and the constructor. I realize the answer to this question is simple, anyway here is the class:

    class myClass
        {
            public double myVar1 { get; set; }
            public double myVar2 { get; set; }
            public FloorPlate()
            {
                myVar1 = 23 * 2 + .0625;
                myVar2 = 33 * 2;
            }
        }

    The member variables are set to public and without this I can't access them from other classes. The constructor is also public and I cannot access it from other classes unless it's public.

    Okay, cool, I got that part, but a lot of the tutorials I read and a certain hot-headed developer who just joined our team, tell me this is all wrong. Nothing, as in nothing, should be public...according to this hot head. He's a very talented, true OOP developer so I give his advice credence but I'm not sure how one can access anything unless they are public.


    Sunday, September 13, 2015 1:12 PM

Answers

  • Hi Bill,

    The "public FloorPlate()" is not your constructor, in this case it is just a method. Your class is called MyClass, so the constructor would be public MyClass(). Perhaps you meant to change the class name from MyClass to FloorPlate?

    Some things have to be public, you are correct about that. I can't believe that this guy says *nothing* should be public!! Perhaps you misunderstood?

    That said, I wouldn't make *everything* public, only the properties that need to be exposed externally to the class. If you have a "base" class, from which you create sub-classes, those sub-classes don't need the fields/properties to be public. If they are set to protected, sub-classes can access them.


    ~~Bonnie DeWitt [C# MVP]

    http://geek-goddess-bonnie.blogspot.com

    • Marked as answer by Bill Tillman Tuesday, September 15, 2015 7:50 PM
    Sunday, September 13, 2015 2:40 PM
  • class myClass
        {
            public double myVar1 { get; set; }
            public double myVar2 { get; set; }
            public FloorPlate()
            {
                myVar1 = 23 * 2 + .0625;
                myVar2 = 33 * 2;
            }
        }

    The member variables are set to public and without this I can't access them from other classes. The constructor is also public and I cannot access it from other classes unless it's public.

    Okay, cool, I got that part, but a lot of the tutorials I read and a certain hot-headed developer who just joined our team, tell me this is all wrong. Nothing, as in nothing, should be public...according to this hot head. He's a very talented, true OOP developer so I give his advice credence but I'm not sure how one can access anything unless they are public.

    First of all, you don't have public Fields in that class. You have two public Properties.
    Properties are 95% syntax sugar for get/set function so you can use them like a field (in most cases). Since you used short syntax, there is a nameless, private backing variable for them. That is pretty ideal, because you can't accidently end up using the backing Field rather then the property in class code (worst cases scenario of using Properties is accidently doing just that).

    I could agree there should be no public fields in a class - it is indeed better in many cases to use only public properties in the current day and age. If you don't actually do anything in them, the JIT can optimise them down to a simple variable access.
    But properties offer a lot of future options (everything avalible to functions) and you can not retrofit Properties later without having deprecated fields or breaking existing code. Change Notification, Validation - all work best with Properties. Properties are mostly better then Fields.

    As BonnieB pointed out, FloorPlate() is NOT a constructor. It is just another public instance function. Constructor must have the same name as class. If you define none, you get a prameterless public one for free - otherwise you could not instantiate the class.
    If there truly was nothing public at this class, it would be mostly useless. Except for maybe friend and other internal code. So I highly doubt you understood him right.

    • Proposed as answer by Kristin Xie Tuesday, September 15, 2015 3:07 AM
    • Marked as answer by Bill Tillman Tuesday, September 15, 2015 7:50 PM
    Sunday, September 13, 2015 3:36 PM
  •  Like most new developers I often use public static variables as globals throughout a project because I don't really understand true OOP concepts. Thus I'm spending time today to educate myself on the subject. Here is a simple class I'm going to be using and my question is about the set;get; statements and the constructor. I realize the answer to this question is simple, anyway here is the class:

    If you don't know how to use design patterns, then how can you understand and use OOP effectively?

    http://www.dofactory.com/net/design-patterns

    <copied>

    Design patterns are solutions to software design problems you find again and again in real-world application development. Patterns are about reusable designs and interactions of objects.

    <end>

    • Marked as answer by Bill Tillman Tuesday, September 15, 2015 7:50 PM
    Sunday, September 13, 2015 7:52 PM
  • Greetings Bill.

    What your hot-head probably meant is that none of an object's data (that is, it's member variables or fields) should be public. The idea is that every object is responsible for its own data, and no other object can come along and change it or read it without the first object's knowledge.

    The problem with this concept in practice is that there are obviously times when it needs to be broken, when objects need to exchange data between themselves. The way around the gulf between concept and practice has always been to write simple public methods that get and set an object's data while keeping the data itself private, thus maintaining the fiction that each object can't change or read another object's data but can only 'ask' for it to be changed or read.

    Originally in c#, it looked something like this.

    float myVar1; // Private data.
    public float MyVar1 // Public property used to access the private data.
    {
       get
       {
          return myVar1;
       }
    
       set
       {
          myVar1 = value;
       }
    }

    As you can see, this is ridiculously verbose, and leads to what is sometimes referred to as "line noise" where you have to sift through a gajillion lines of code to find the two or three lines that actually do anything.

    In order to reduce line noise, another option was added (I think in VS2010, but I'm not certain) to compact all of the above code into a single get/set line as per your own post. When you use this option, the compiler creates underlying data for you that you never see, so technically it maintains the OOP concept, but it looks for all the world like you are simply making variables public.

    At this point, you are probably asking "Why bother? If it looks and acts like public data, then why not just use public data and be done with it?". To which I reply, "Take it up with an OOP Nazi like your hot-headed colleague, because I haven't got a clue".

    • Proposed as answer by Kristin Xie Tuesday, September 15, 2015 3:07 AM
    • Marked as answer by Bill Tillman Tuesday, September 15, 2015 7:50 PM
    Sunday, September 13, 2015 11:59 PM
  • You should use encapsulation in order to access your public properties. Here you can find explanation in details of encapsulation:

    http://www.tutorialspoint.com/csharp/csharp_encapsulation.htm

    Let me explain why using public methods and properties is a bad practice. 

    The most important thing when you are writing code is not writing less code but writing clean, understandable and manageable code. It is easy to write code that is understandable by compilers but it is hard to write code that can be read easily by human. 

    When you encapsulate data, you will have: 

    • Less error prone code
    • Decoupled modular code
    • Code that can be altered without affecting other parts of your project

    Basically, you do not need to know how data in a class implemented but you need the result of that class. Let me clarify this with a real life example. Think about a Wendy's Drink Machine. You insert coins and you get a drink but you do not know what happens in the backstage. 

    If you make your properties public, you can touch the drinks in the machine's storage and you can intervene the process of your machine. Would that be a good thing?

    When you write a class, you should let other classes to access only the necessary elements of your class but nothing else. 

    Finally, let me give you an example about how you can encapsulate your class: 

    class myClass { private double myVar1 { get; set; } private double myVar2 { get; set; }

    public double GetValue1()

    {

    return myVar1;

    }

     public double GetValue2()

           {

               return myVar1;

          }

    }

    The above example is not giving a good example but basically, this is how you can do encapsulating.

    • Proposed as answer by Kristin Xie Tuesday, September 15, 2015 3:07 AM
    • Marked as answer by Bill Tillman Tuesday, September 15, 2015 7:50 PM
    Monday, September 14, 2015 7:50 AM

All replies

  • Hi Bill,

    The "public FloorPlate()" is not your constructor, in this case it is just a method. Your class is called MyClass, so the constructor would be public MyClass(). Perhaps you meant to change the class name from MyClass to FloorPlate?

    Some things have to be public, you are correct about that. I can't believe that this guy says *nothing* should be public!! Perhaps you misunderstood?

    That said, I wouldn't make *everything* public, only the properties that need to be exposed externally to the class. If you have a "base" class, from which you create sub-classes, those sub-classes don't need the fields/properties to be public. If they are set to protected, sub-classes can access them.


    ~~Bonnie DeWitt [C# MVP]

    http://geek-goddess-bonnie.blogspot.com

    • Marked as answer by Bill Tillman Tuesday, September 15, 2015 7:50 PM
    Sunday, September 13, 2015 2:40 PM
  • class myClass
        {
            public double myVar1 { get; set; }
            public double myVar2 { get; set; }
            public FloorPlate()
            {
                myVar1 = 23 * 2 + .0625;
                myVar2 = 33 * 2;
            }
        }

    The member variables are set to public and without this I can't access them from other classes. The constructor is also public and I cannot access it from other classes unless it's public.

    Okay, cool, I got that part, but a lot of the tutorials I read and a certain hot-headed developer who just joined our team, tell me this is all wrong. Nothing, as in nothing, should be public...according to this hot head. He's a very talented, true OOP developer so I give his advice credence but I'm not sure how one can access anything unless they are public.

    First of all, you don't have public Fields in that class. You have two public Properties.
    Properties are 95% syntax sugar for get/set function so you can use them like a field (in most cases). Since you used short syntax, there is a nameless, private backing variable for them. That is pretty ideal, because you can't accidently end up using the backing Field rather then the property in class code (worst cases scenario of using Properties is accidently doing just that).

    I could agree there should be no public fields in a class - it is indeed better in many cases to use only public properties in the current day and age. If you don't actually do anything in them, the JIT can optimise them down to a simple variable access.
    But properties offer a lot of future options (everything avalible to functions) and you can not retrofit Properties later without having deprecated fields or breaking existing code. Change Notification, Validation - all work best with Properties. Properties are mostly better then Fields.

    As BonnieB pointed out, FloorPlate() is NOT a constructor. It is just another public instance function. Constructor must have the same name as class. If you define none, you get a prameterless public one for free - otherwise you could not instantiate the class.
    If there truly was nothing public at this class, it would be mostly useless. Except for maybe friend and other internal code. So I highly doubt you understood him right.

    • Proposed as answer by Kristin Xie Tuesday, September 15, 2015 3:07 AM
    • Marked as answer by Bill Tillman Tuesday, September 15, 2015 7:50 PM
    Sunday, September 13, 2015 3:36 PM
  •  Like most new developers I often use public static variables as globals throughout a project because I don't really understand true OOP concepts. Thus I'm spending time today to educate myself on the subject. Here is a simple class I'm going to be using and my question is about the set;get; statements and the constructor. I realize the answer to this question is simple, anyway here is the class:

    If you don't know how to use design patterns, then how can you understand and use OOP effectively?

    http://www.dofactory.com/net/design-patterns

    <copied>

    Design patterns are solutions to software design problems you find again and again in real-world application development. Patterns are about reusable designs and interactions of objects.

    <end>

    • Marked as answer by Bill Tillman Tuesday, September 15, 2015 7:50 PM
    Sunday, September 13, 2015 7:52 PM
  • Greetings Bill.

    What your hot-head probably meant is that none of an object's data (that is, it's member variables or fields) should be public. The idea is that every object is responsible for its own data, and no other object can come along and change it or read it without the first object's knowledge.

    The problem with this concept in practice is that there are obviously times when it needs to be broken, when objects need to exchange data between themselves. The way around the gulf between concept and practice has always been to write simple public methods that get and set an object's data while keeping the data itself private, thus maintaining the fiction that each object can't change or read another object's data but can only 'ask' for it to be changed or read.

    Originally in c#, it looked something like this.

    float myVar1; // Private data.
    public float MyVar1 // Public property used to access the private data.
    {
       get
       {
          return myVar1;
       }
    
       set
       {
          myVar1 = value;
       }
    }

    As you can see, this is ridiculously verbose, and leads to what is sometimes referred to as "line noise" where you have to sift through a gajillion lines of code to find the two or three lines that actually do anything.

    In order to reduce line noise, another option was added (I think in VS2010, but I'm not certain) to compact all of the above code into a single get/set line as per your own post. When you use this option, the compiler creates underlying data for you that you never see, so technically it maintains the OOP concept, but it looks for all the world like you are simply making variables public.

    At this point, you are probably asking "Why bother? If it looks and acts like public data, then why not just use public data and be done with it?". To which I reply, "Take it up with an OOP Nazi like your hot-headed colleague, because I haven't got a clue".

    • Proposed as answer by Kristin Xie Tuesday, September 15, 2015 3:07 AM
    • Marked as answer by Bill Tillman Tuesday, September 15, 2015 7:50 PM
    Sunday, September 13, 2015 11:59 PM
  • You should use encapsulation in order to access your public properties. Here you can find explanation in details of encapsulation:

    http://www.tutorialspoint.com/csharp/csharp_encapsulation.htm

    Let me explain why using public methods and properties is a bad practice. 

    The most important thing when you are writing code is not writing less code but writing clean, understandable and manageable code. It is easy to write code that is understandable by compilers but it is hard to write code that can be read easily by human. 

    When you encapsulate data, you will have: 

    • Less error prone code
    • Decoupled modular code
    • Code that can be altered without affecting other parts of your project

    Basically, you do not need to know how data in a class implemented but you need the result of that class. Let me clarify this with a real life example. Think about a Wendy's Drink Machine. You insert coins and you get a drink but you do not know what happens in the backstage. 

    If you make your properties public, you can touch the drinks in the machine's storage and you can intervene the process of your machine. Would that be a good thing?

    When you write a class, you should let other classes to access only the necessary elements of your class but nothing else. 

    Finally, let me give you an example about how you can encapsulate your class: 

    class myClass { private double myVar1 { get; set; } private double myVar2 { get; set; }

    public double GetValue1()

    {

    return myVar1;

    }

     public double GetValue2()

           {

               return myVar1;

          }

    }

    The above example is not giving a good example but basically, this is how you can do encapsulating.

    • Proposed as answer by Kristin Xie Tuesday, September 15, 2015 3:07 AM
    • Marked as answer by Bill Tillman Tuesday, September 15, 2015 7:50 PM
    Monday, September 14, 2015 7:50 AM