World Library  
Flag as Inappropriate
Email this Article

Encapsulation (computer programming)

Article Id: WHEBN0000220919
Reproduction Date:

Title: Encapsulation (computer programming)  
Author: World Heritage Encyclopedia
Language: English
Subject: Encapsulation, Data Modelling & Design, The lexer hack, Object-oriented programming, Structure
Collection: Object-Oriented Programming
Publisher: World Heritage Encyclopedia

Encapsulation (computer programming)

Encapsulation is the packing of data and functions into a single component. The features of encapsulation are supported using classes in most object-oriented programming languages, although other alternatives also exist. It allows selective hiding of properties and methods in an object by building an impenetrable wall to protect the code from accidental corruption.

In programming languages, encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination[1][2] thereof:

  • A language mechanism for restricting access to some of the object's components.[3][4]
  • A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.[5][6]

Some programming language researchers and academics use the first meaning alone or in combination with the second as a distinguishing feature of object-oriented programming, while other programming languages which provide lexical closures view encapsulation as a feature of the language orthogonal to object orientation.

The second definition is motivated by the fact that in many OOP languages hiding of components is not automatic or can be overridden; thus, information hiding is defined as a separate notion by those who prefer the second definition.


  • As information hiding mechanism 1
  • Historical importance 2
  • General definition 3
  • References 4
  • External links 5

As information hiding mechanism

Encapsulation can be used to hide data member and member function. Under this definition, encapsulation means that the internal representation of an object is generally hidden from view outside of the object's definition. Typically, only the object's own methods can directly inspect or manipulate its fields. Some languages like Smalltalk and Ruby only allow access via object methods, but most others (e.g. C++, C# or Java) offer the programmer a degree of control over what is hidden, typically via keywords like public and private.[4] It should be noted that the ISO C++ standard refers to protected, private and public as "access specifiers" and that they do not "hide any information". Information hiding is accomplished by furnishing a compiled version of the source code that is interfaced via a header file.

Hiding the internals of the object protects its integrity by preventing users from setting the internal data of the component into an invalid or inconsistent state. A supposed benefit of encapsulation is that it can reduce system complexity, and thus increase robustness, by allowing the developer to limit the inter-dependencies between software components.

Almost always, there is a way to override such protection – usually via reflection API (Ruby, Java, C#, etc.), sometimes by mechanism like name mangling (Python), or special keyword usage like friend in C++.

Below is an example in C# that shows how access to a data field can be restricted through the use of a private keyword:

class Program {
        public class Account {
                private decimal accountBalance = 500.00m;

                public decimal CheckBalance() {
                        return accountBalance;

        static void Main() {
                Account myAccount = new Account();
                decimal myBalance = myAccount.CheckBalance();

                /* This Main method can check the balance via the public
                * "CheckBalance" method provided by the "Account" class 
                * but it cannot manipulate the value of "accountBalance" */

Below is an example in Java:

public class Employee {
    private BigDecimal salary = new BigDecimal(50000.00);
    public BigDecimal getSalary() {
        return salary;

    public static void main() {
        Employee e = new Employee();
        BigDecimal sal = e.getSalary();

Below is an example in PHP:

class Account
     * How much money is currently in the account
     * @var float
    private $accountBalance;

     * @param float $currentAccountBalance Initialize account to this dollar amount
    public function __construct($currentAccountBalance)
        $this->accountBalance = $currentAccountBalance;

     * Add money to account
     * @param float $money Dollars to add to balance
     * @return void
    public function add($money)
        $this->accountBalance += $money;

     * Remove money from account
     * @param float $money Dollars to subtract from balance
     * @throws Exception
     * @return void
    public function withdraw($money)
        if ($this->accountBalance < $money) {
            throw new Exception('Cannot withdraw $' . $money . ' from account as it contains $' . $this->accountBalance);
        $this->accountBalance -= $money;

     * Get current account balance, that takes all additions and subtractions into consideration.
     * @return float
    public function getAccountBalance()
        return $this->accountBalance;

// Create a new object from the Account class with a starting balance of $500.00
$myAccount = new Account(500.00);

// We have clearly defined methods for adding and subtracting money from the Account
// If we didn't have a method for withdraw(), nothing would prevent us from withdrawing more money than was available in the account

// Get the current balance
$accountBalance = $myAccount->getAccountBalance();
echo 'My Account Balance: $' . $accountBalance; // 505.79

// Our code forbids us from withdrawing more than we have
$myAccount->withdraw(600.00); // Exception Message: Cannot withdraw $600 from account as it contains $505.79

Encapsulation is also possible in older, non-object-oriented languages. In C, for example, a structure can be declared in the public API (i.e., the header file) for a set of functions that operate on an item of data containing data members that are not accessible to clients of the API:

// Header file "api.h"

struct Entity;          // Opaque structure with hidden members

// API functions that operate on 'Entity' objects
extern struct Entity *  open_entity(int id);
extern int              process_entity(struct Entity *info);
extern void             close_entity(struct Entity *info);

Clients call the API functions to allocate, operate on, and deallocate objects of an opaque type. The contents of this type are known and accessible only to the implementation of the API functions; clients cannot directly access its contents. The source code for these functions defines the actual contents of the structure:

// Implementation file "api.c"

#include "api.h"

// Complete definition of the 'Entity' object
struct Entity {
    int     ent_id;         // ID number
    char    ent_name[20];   // Name
    ... and other members ...

// API function implementations
struct Entity * open_entity(int id)
{ ... }

int process_entity(struct Entity *info)
{ ... }

void close_entity(struct Entity *info)
{ ... }

Historical importance

The purpose of encapsulation (to classify) can be summarized to the following: to reduce collisions of identically named variables and to group together related methods (functions) and properties (variables) to comprise an object of class (like a family). This pattern of practice helps make source code with hundreds or thousands of lines of code more understandable and workable.

General definition

In general, encapsulation is one of the four fundamentals of OOP (object-oriented programming). Encapsulation refers to the bundling of data with the methods that operate on that data.[7] Encapsulation is used to hide the values or state of a structured data object inside a class, preventing unauthorized parties' direct access to them. Publicly accessible methods are generally provided in the class (so-called getters and setters) to access the values, and other client classes call these methods to retrieve and modify the values within the object.

This mechanism is not unique to object-oriented programming. Implementations of abstract data types, e.g. modules, offer a similar form of encapsulation. This similarity stems from the fact that both notions rely on the same mathematical fundament of an existential type.[8]


  1. ^ Michael Lee Scott, Programming language pragmatics, Edition 2, Morgan Kaufmann, 2006, ISBN 0-12-633951-1, p. 481: "Encapsulation mechanisms enable the programmer to group data and the subroutines that operate on them together in one place, and to hide irrelevant details from the users of an abstraction."
  2. ^ Nell B. Dale, Chip Weems, Programming and problem solving with Java, Edition 2, Jones & Bartlett Publishers, 2007, ISBN 0-7637-3402-0, p. 396
  3. ^ John C. Mitchell, Concepts in programming languages, Cambridge University Press, 2003, ISBN 0-521-78098-5, p.522
  4. ^ a b   p. 266
  5. ^ Wm. Paul Rogers, Encapsulation is not information hiding,, 05/18/01
  6. ^ Thomas M. Connolly, Carolyn E. Begg, Database systems: a practical approach to design, implementation, and management, Edition 4, Pearson Education, 2005, ISBN 0-321-21025-5, Chapter 25, "Introduction to Object DMBS", section "Object-oriented concepts", p. 814
  7. ^ Rodgers, Wm. Paul. "Encapsulation is not information hiding". JavaWorld. Retrieved 2014-03-15. 
  8. ^ Pierce (2002), Section 24.2 "Data Abstraction with Existentials"

External links

  • SOA
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.

Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.