Content deleted Content added
Jake0Miller (talk | contribs) mNo edit summary |
→Data abstraction and encapsulation: Add about using the most restrictive visibility |
||
Line 182:
In object oriented programming, objects provide a layer which can be used to separate internal from external code and implement abstraction and encapsulation. External code can only use an object by calling a specific instance method with a certain set of input parameters, reading an instance variable, or writing to an instance variable. A program may create many instances of objects as it runs, which operate independently. This technique, it is claimed, allows easy re-use of the same procedures and data definitions for different sets of data, in addition to potentially mirroring real-world relationships intuitively. Rather than utilizing database tables and programming subroutines, the developer utilizes objects the user may be more familiar with: objects from their application ___domain.<ref>{{cite book|last=Jacobsen|first=Ivar|title=Object Oriented Software Engineering|year=1992|publisher=Addison-Wesley ACM Press|isbn=978-0-201-54435-0|pages=[https://archive.org/details/objectorientedso00jaco/page/43 43–69]|author2=Magnus Christerson|author3=Patrik Jonsson|author4=Gunnar Overgaard|url=https://archive.org/details/objectorientedso00jaco/page/43}}</ref> These claims that the OOP paradigm enhances reusability and modularity have been criticized.<ref name="badprop"/><ref name="armstrongjoe"/>
The initial design is encouraged to use the most restrictive visibility possible, in order of local (or method) variables, private variables (in object oriented programming), and global (or public) variables, and only be expanded when and as much as necessary. This prevents changes to visibility from invalidating existing code.<ref>{{Cite book |last=McDonough |first=James E. |title=Object-Oriented Design with ABAP: A Practical Approach |date=2017 |publisher=[[Apress]] |year=2017 |isbn=978-1-4842-2837-1 |___location= |chapter=Encapsulation |doi=10.1007/978-1-4842-2838-8 |via=[[O'Reilly Media|O'Reilly]]}}</ref>
If a class does not allow calling code to access internal object data and permits access through methods only, this is also a form of information hiding. Some languages (Java, for example) let classes enforce access restrictions explicitly, for example, denoting internal data with the <code>private</code> keyword and designating methods intended for use by code outside the class with the <code>public</code> keyword.{{sfn|Bloch|2018|loc=Chapter §4 Item15 Minimize the accessibility of classes and members|pp=73-77}} Methods may also be designed public, private, or intermediate levels such as <code>protected</code> (which allows access from the same class and its subclasses, but not objects of a different class).{{sfn|Bloch|2018|loc=Chapter §4 Item15 Minimize the accessibility of classes and members|pp=73-77}} In other languages (like Python) this is enforced only by convention (for example, <code>private</code> methods may have names that start with an [[underscore]]). In C#, Swift & Kotlin languages, <code>internal</code> keyword permits access only to files present in the same assembly, package, or module as that of the class.<ref>{{Cite web |date=2023-01-05 |title=What is Object Oriented Programming (OOP) In Simple Words? – Software Geek Bytes |url=https://softwaregeekbytes.com/object-oriented-programming-simple-words/ |access-date=2023-01-17 |language=en-US}}</ref>
| |||