Difference between revisions of "User:Shawndouglas/sandbox/sublevel2"

From LIMSWiki
Jump to navigationJump to search
(Clearing sandbox)
(Added content I'm working on. Saving for later.)
Line 7: Line 7:


==Sandbox begins below==
==Sandbox begins below==
'''Encapsulation''' is one of the four fundamentals of object-oriented programming (OOP), involving the concept of "bundling data with the methods that operate on that data."<ref name="RogersEnc">{{cite web |url=http://www.javaworld.com/article/2075271/core-java/encapsulation-is-not-information-hiding.html |title=Encapsulation is not information hiding |author=Rogers, William Paul |work=JavaWorld |date=18 May 2001 |accessdate=28 August 2014}}</ref> Encapsulation places the values or state of a structured data object within a class, preventing unauthorized access to them. Publicly accessible methods are generally provided in the class (so-called "getters" and "setters") to access the values or state, and other client classes call these methods to retrieve and modify the values within the object. In some programming languages, this concept should not be interpreted as hiding; for example, in Java data can be encapsulated but not hidden.<ref name="RogersEnc" /> Additionally, encapsulation is not unique to object-oriented programming. Implementations of abstract data types like modules offers a similar form of encapsulation.
==Definition==
In programming languages, "encapsulation" is used to refer to one of two related but distinct notions (and sometimes to both):
<ref>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."</ref>
<ref name=Dale>Nell B. Dale, Chip Weems, ''Programming and problem solving with Java'', Edition 2, Jones & Bartlett Publishers, 2007, ISBN 0-7637-3402-0, p. 396</ref>
* A language mechanism for restricting access to some of the [[object (computer science)|object]]'s components.<ref>[[John C. Mitchell]], ''Concepts in programming languages'', Cambridge University Press, 2003, ISBN 0-521-78098-5, p.522</ref><ref name=Pierce>{{cite book|last=Pierce|first=Benjamin|authorlink=Benjamin C. Pierce|title=[[Types and Programming Languages]]|publisher=MIT Press|year=2002|isbn=0-262-16209-1}} p. 266</ref>
* A language construct that facilitates the bundling of data with the [[Method (computer programming)|method]]s <!-- I object to the word method being used here because in lisp languages programmers cannot distinguish methods from normal functions at the call site.  Behavior equivalent to methods may be implemented as normal functions. encapsulation is not dependent on implementation but on behavior--> (or other functions) operating on that data.<ref>Wm. Paul Rogers, [http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html?page=9 ''Encapsulation is not information hiding''], JavaWorld.com, 05/18/01</ref><ref>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</ref>
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 [[Closure (computer programming)|lexical closures]] view encapsulation as a feature of the language [[orthogonal#Computer science|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.<!-- this is based on all the refs given above, so no inline cite here-->
==As information hiding mechanism==
{{See also|Information hiding}}
Under this definition, encapsulation means that the internal representation of an [[object (computer science)|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 (programming language)|Ruby]] only allow access via object methods, but most others (e.g. [[C++]], [[C Sharp (programming language)|C#]] or [[Java (programming language)|Java]]) offer the programmer a degree of control over what is hidden, typically via keywords like <code>public</code> and <code>private</code>.<ref name=Pierce/> It should be noted that the ISO C++ standard refers to <code>protected</code>, <code>private</code> and <code>public</code> 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 (computer science)|robustness]], by allowing the developer to limit the inter-dependencies between software components{{Citation needed|date=April 2014}}.
Almost always, there is a way to override such protection &ndash; usually via reflection API (Ruby, Java, C#, etc.), sometimes by mechanism like [[name mangling]] ([[Python (programming language)|Python]]), or special keyword usage like <code>friend</code> in C++.
Below is an example in [[C Sharp (programming language)|C#]] that shows how access to a data field can be restricted through the use of a <code>private</code> keyword:
<source lang="csharp">
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" */
}
}
</source>
Below is an example in Java:
<source lang="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();
    }
}
</source>
PHP offers the advantage of plain and simple. The purpose of these 3 categories is SCOPE.
* Public - The method is publicly available and can be accessed by all subclasses.
* Protected - the method/function/property is available to the parent class and all inheriting classes or we call them subclasses or child classes.
* Private - the method is private and only available to the parent class/base class.
Below is an example in PHP:
<source lang="php">
class person {
var $name;
public $height;
protected $social_insurance;
private $pinn_number;
function __construct($persons_name) {
$this->name = $persons_name;
}
function set_name($new_name) { 
$this->name = $new_name;
}
function get_name() {
return $this->name;
}
}
</source>
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:
<source lang="csharp">
// 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);
</source>
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:
<source lang="csharp">
// 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)
{ ... }
</source>
==Historical Importance==
&nbsp; The purpose of encapsulation (to classify) can be summarized to the following - to reduce collisions of same 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.
==In combination==
With regard to combination (or bundling) data, this is prevalent in any object that is created. An object's state will depend on its methods that do work on or with the object's internal data.
An analogy can be made here with the notion of a [[Information hiding|capsule]], which not only encloses its contents, but also protects it from the exterior environment.<ref name=Dale/>
==References==
<references />

Revision as of 23:50, 28 August 2014

Sandbox begins below

Encapsulation is one of the four fundamentals of object-oriented programming (OOP), involving the concept of "bundling data with the methods that operate on that data."[1] Encapsulation places the values or state of a structured data object within a class, preventing unauthorized access to them. Publicly accessible methods are generally provided in the class (so-called "getters" and "setters") to access the values or state, and other client classes call these methods to retrieve and modify the values within the object. In some programming languages, this concept should not be interpreted as hiding; for example, in Java data can be encapsulated but not hidden.[1] Additionally, encapsulation is not unique to object-oriented programming. Implementations of abstract data types like modules offers a similar form of encapsulation.

Definition

In programming languages, "encapsulation" is used to refer to one of two related but distinct notions (and sometimes to both):

[2]

[3]

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

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

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.[5] 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[citation needed].

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();
    }
}

PHP offers the advantage of plain and simple. The purpose of these 3 categories is SCOPE.

  • Public - The method is publicly available and can be accessed by all subclasses.
  • Protected - the method/function/property is available to the parent class and all inheriting classes or we call them subclasses or child classes.
  • Private - the method is private and only available to the parent class/base class.

Below is an example in PHP:

	class person {		
	var $name;		
		public $height;		
		protected $social_insurance;
		private $pinn_number;
		
		function __construct($persons_name) {		
			$this->name = $persons_name;		
		}		
		
		function set_name($new_name) {   	
			$this->name = $new_name;
		}	

		function get_name() {
			return $this->name;
		}		
			
	}

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 same 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.

In combination

With regard to combination (or bundling) data, this is prevalent in any object that is created. An object's state will depend on its methods that do work on or with the object's internal data.

An analogy can be made here with the notion of a capsule, which not only encloses its contents, but also protects it from the exterior environment.[3]

References

  1. 1.0 1.1 Rogers, William Paul (18 May 2001). "Encapsulation is not information hiding". JavaWorld. http://www.javaworld.com/article/2075271/core-java/encapsulation-is-not-information-hiding.html. Retrieved 28 August 2014. 
  2. 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."
  3. 3.0 3.1 Nell B. Dale, Chip Weems, Programming and problem solving with Java, Edition 2, Jones & Bartlett Publishers, 2007, ISBN 0-7637-3402-0, p. 396
  4. John C. Mitchell, Concepts in programming languages, Cambridge University Press, 2003, ISBN 0-521-78098-5, p.522
  5. 5.0 5.1 Pierce, Benjamin (2002). Types and Programming Languages. MIT Press. ISBN 0-262-16209-1.  p. 266
  6. Wm. Paul Rogers, Encapsulation is not information hiding, JavaWorld.com, 05/18/01
  7. 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