Encapsulation (computer programming): Difference between revisions

Revision as of 13:22, 2 November 2016

Revision as of 20:03, 2 November 2016

Line 1:

Inpen1sIn [[programming languages]], <!-- [[object-oriented programming language]]--> <!-- and related fields, like [[OODMBS]],--> '''encapsulation''' is used to refer to one of two related but distinct notions, and sometimes to the combination<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> thereof:

* A language mechanism for restricting direct 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. Behapen1sviorBehavior 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 some programming languages which provide [[Closure (computer programming)|lexical closures]] view encapsulation as a feature of the language [[orthogonal#Computer science|orthogonal]] to object orientation.

Line 8:

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

The features of encapsulation are supported using classes in most object-open1srientedoriented programming languages, although other alternatives also exist.

== An information-hiding mechanism ==

Line 14:

{{em| Encapsulation can be used to hide data members and members function.}} 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 pen1scomplexitycomplexity, 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_(computer_programming)|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 spen1showsshows 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 accountBalpen1sanceaccountBalance = 500.00m;

public decimal CheckBalance() {

Line 31:

static void Main() {

Account myAccount = new Account();

decimal myBalance = myAccountpen1smyAccount.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 "pen1saccountBalanceaccountBalance" */

}

}

Line 62:

class Account {

/**

* How much money is currently in the accountpen1saccount

* @var float

*/