Field encapsulation

In computer programming, field encapsulation involves providing methods that can be used to read from or write to the field rather than accessing the field directly. Sometimes these accessor methods are called getX and setX (where X is the field's name), which are also known as mutator methods. Usually the accessor methods have public visibility while the field being encapsulated is given private visibility - this allows a programmer to restrict what actions another user of the code can perform. Compare the following Java class in which the name field has not been encapsulated:

public class NormalFieldClass {
    public String name;
 
    public static void main(String[] args)
    {
        NormalFieldClass example1 = new NormalFieldClass();
        example1.name = "myName";
        System.out.println("My name is " + example1.name);
    }
}

with the same example using encapsulation:

public class EncapsulatedFieldClass {
    private String name;
 
    public String getName()
    {
        return name;
    }
 
    public void setName(String newName)
    {
        name = newName;
    }
 
    public static void main(String[] args)
    {
      EncapsulatedFieldClass example1 = new EncapsulatedFieldClass();
      example1.setName("myName");
      System.out.println("My name is " + example1.getName());
    }
}

In the first example a user is free to use the public name variable however they see fit - in the second however the writer of the class retains control over how the private name variable is read and written by only permitting access to the field via its getName and setName methods.

Advantages

  • The internal storage format of the data is hidden; in the example, an expectation of the use of restricted character sets could allow data compression through recoding (e.g., of eight bit characters to a six bit code). An attempt to encode characters out of the range of the expected data could then be handled by casting an error in the set routine.
  • In general, the get and set methods may be produced in two versions - an efficient method that assumes that the caller is delivering appropriate data and that the data has been stored properly, and a debugging version that while slower, performs validity checks on data received and delivered. Such detection is useful when routines (calling or called) or internal storage formats are newly created or modified.
  • The location of the stored data within larger structures may be hidden and so enabling changes to be made to this storage without the necessity of changing the code that references the data. This also reduces the likelihood of unexpected side effects from such changes. This is especially advantageous when the accessors are part of an operating system (OS), a case where the calling (application) code may not be available to the developers of the OS.

Disadvantages

Access to a subroutine involves additional overhead not present when data is accessed directly. While this is becoming of less concern with the wide availability of fast general-purpose processors it may remain important in coding some real-time computing systems and systems using relatively slow and simple embedded processors. In some languages, like C++, the getter / setter methods are usually inline functions, so that when inlining is performed, the code looks just like direct field accessing.

gollark: You're not actually in Turkey, perhaps?
gollark: So helpful.
gollark: ++search lazer
gollark: https://github.com/kprotty/lazer/
gollark: See <#445375649511768074>.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.