Class (computer programming)

Last updated

In object-oriented programming, a class defines the shared aspects of objects created from the class. The capabilities of a class differ between programming languages, but generally the shared aspects consist of state (variables) and behavior (methods) that are each either associated with an particular object or with all objects of that class. [1] [2]

Contents

Object state can differ between each instance of the class whereas the class state is shared by all of them. The object methods include access to the object state (via an implicit or explicit parameter that references the object) whereas class methods do not.

If the language supports inheritance, a class can be defined based on another class with all of its state and behavior plus additional state and behavior that further specializes the class. The specialized class is a sub-class, and the class it is based on is its superclass.

Attributes

Object lifecycle

As an instance of a class, an object is constructed from a class via instantiation. Memory is allocated and initialized for the object state and a reference to the object is provided to consuming code. The object is usable until it is destroyed its state memory is de-allocated.

Most languages allow for custom logic at lifecycle events via a constructor and a destructor.

Type

An object expresses data type as an interface the type of each member variable and the signature of each member function (method). A class defines an implementation of an interface, and instantiating the class results in an object that exposes the implementation via the interface. [3] In the terms of type theory, a class is an implementationa concrete data structure and collection of subroutineswhile a type is an interface. Different (concrete) classes can produce objects of the same (abstract) type (depending on type system). For example, the type (interface) Stack might be implemented by SmallStack that is fast for small stacks but scales poorly and ScalableStack that scales well but has high overhead for small stacks.

Structure

UML notation for classes Oop-uml-class-example.png
UML notation for classes

A class contains data field descriptions (or properties , fields , data members , or attributes ). These are usually field types and names that will be associated with state variables at program run time; these state variables either belong to the class or specific instances of the class. In most languages, the structure defined by the class determines the layout of the memory used by its instances. Other implementations are possible: for example, objects in Python use associative key-value containers. [4]

Some programming languages such as Eiffel support specification of invariants as part of the definition of the class, and enforce them through the type system. Encapsulation of state is necessary for being able to enforce the invariants of the class.

Behavior

The behavior of a class or its instances is defined using methods. Methods are subroutines with the ability to operate on objects or classes. These operations may alter the state of an object or simply provide ways of accessing it. [5] Many kinds of methods exist, but support for them varies across languages. Some types of methods are created and called by programmer code, while other special methods—such as constructors, destructors, and conversion operators—are created and called by compiler-generated code. A language may also allow the programmer to define and call these special methods. [6] [7]

Class interface

Every class implements (or realizes) an interface by providing structure and behavior. Structure consists of data and state, and behavior consists of code that specifies how methods are implemented. [8] There is a distinction between the definition of an interface and the implementation of that interface; however, this line is blurred in many programming languages because class declarations both define and implement an interface. Some languages, however, provide features that separate interface and implementation. For example, an abstract class can define an interface without providing an implementation.

Languages that support class inheritance also allow classes to inherit interfaces from the classes that they are derived from.

For example, if "class A" inherits from "class B" and if "class B" implements the interface "interface B" then "class A" also inherits the functionality(constants and methods declaration) provided by "interface B".

In languages that support access specifiers, the interface of a class is considered to be the set of public members of the class, including both methods and attributes (via implicit getter and setter methods); any private members or internal data structures are not intended to be depended on by external code and thus are not part of the interface.

Object-oriented programming methodology dictates that the operations of any interface of a class are to be independent of each other. It results in a layered design where clients of an interface use the methods declared in the interface. An interface places no requirements for clients to invoke the operations of one interface in any particular order. This approach has the benefit that client code can assume that the operations of an interface are available for use whenever the client has access to the object. [9] [ citation needed ]

Class interface example

The buttons on the front of your television set are the interface between you and the electrical wiring on the other side of its plastic casing. You press the "power" button to toggle the television on and off. In this example, your particular television is the instance, each method is represented by a button, and all the buttons together compose the interface (other television sets that are the same model as yours would have the same interface). In its most common form, an interface is a specification of a group of related methods without any associated implementation of the methods.

A television set also has a myriad of attributes, such as size and whether it supports color, which together comprise its structure. A class represents the full description of a television, including its attributes (structure) and buttons (interface).

Getting the total number of televisions manufactured could be a static method of the television class. This method is associated with the class, yet is outside the domain of each instance of the class. A static method that finds a particular instance out of the set of all television objects is another example.

Member accessibility

The following is a common set of access specifiers: [10]

Although many object-oriented languages support the above access specifiers,their semantics may differ.

Object-oriented design uses the access specifiers in conjunction with careful design of public method implementations to enforce class invariants—constraints on the state of the objects. A common usage of access specifiers is to separate the internal data of a class from its interface: the internal structure is made private, while public accessor methods can be used to inspect or alter such private data.

Access specifiers do not necessarily control visibility, in that even private members may be visible to client external code. In some languages, an inaccessible but visible member may be referred to at runtime (for example, by a pointer returned from a member function), but an attempt to use it by referring to the name of the member from the client code will be prevented by the type checker. [11]

The various object-oriented programming languages enforce member accessibility and visibility to various degrees, and depending on the language's type system and compilation policies, enforced at either compile time or runtime. For example, the Java language does not allow client code that accesses the private data of a class to compile. [12] In the C++ language, private methods are visible, but not accessible in the interface; however, they may be made invisible by explicitly declaring fully abstract classes that represent the interfaces of the class. [13]

Some languages feature other accessibility schemes:

Inheritance

Conceptually, a superclass is a superset of its subclasses. For example, GraphicObject could be a superclass of Rectangle and Ellipse, while Square would be a subclass of Rectangle. These are all subset relations in set theory as well, i.e., all squares are rectangles but not all rectangles are squares.

A common conceptual error is to mistake a part of relation with a subclass. For example, a car and truck are both kinds of vehicles and it would be appropriate to model them as subclasses of a vehicle class. However, it would be an error to model the parts of the car as subclass relations. For example, a car is composed of an engine and body, but it would not be appropriate to model an engine or body as a subclass of a car.

In object-oriented modeling these kinds of relations are typically modeled as object properties. In this example, the Car class would have a property called parts. parts would be typed to hold a collection of objects, such as instances of Body, Engine, Tires, etc. Object modeling languages such as UML include capabilities to model various aspects of "part of" and other kinds of relations – data such as the cardinality of the objects, constraints on input and output values, etc. This information can be utilized by developer tools to generate additional code besides the basic data definitions for the objects, such as error checking on get and set methods. [16]

One important question when modeling and implementing a system of object classes is whether a class can have one or more superclasses. In the real world with actual sets, it would be rare to find sets that did not intersect with more than one other set. However, while some systems such as Flavors and CLOS provide a capability for more than one parent to do so at run time introduces complexity that many in the object-oriented community consider antithetical to the goals of using object classes in the first place. Understanding which class will be responsible for handling a message can get complex when dealing with more than one superclass. If used carelessly this feature can introduce some of the same system complexity and ambiguity classes were designed to avoid. [17]

Most modern object-oriented languages such as Smalltalk and Java require single inheritance at run time. For these languages, multiple inheritance may be useful for modeling but not for an implementation.

However, semantic web application objects do have multiple superclasses. The volatility of the Internet requires this level of flexibility and the technology standards such as the Web Ontology Language (OWL) are designed to support it.

A similar issue is whether or not the class hierarchy can be modified at run time. Languages such as Flavors, CLOS, and Smalltalk all support this feature as part of their meta-object protocols. Since classes are themselves first-class objects, it is possible to have them dynamically alter their structure by sending them the appropriate messages. Other languages that focus more on strong typing such as Java and C++ do not allow the class hierarchy to be modified at run time. Semantic web objects have the capability for run time changes to classes. The rationale is similar to the justification for allowing multiple superclasses, that the Internet is so dynamic and flexible that dynamic changes to the hierarchy are required to manage this volatility. [18]

Although many class-based languages support inheritance, inheritance is not an intrinsic aspect of classes. An object-based language (i.e. Classic Visual Basic) supports classes yet does not support inheritance.

Inter-class relationships

A programming language may support various class relationship features.

Compositional

Classes can be composed of other classes, thereby establishing a compositional relationship between the enclosing class and its embedded classes. Compositional relationship between classes is also commonly known as a has-a relationship. [19] For example, a class "Car" could be composed of and contain a class "Engine". Therefore, a Car has an Engine. One aspect of composition is containment, which is the enclosure of component instances by the instance that has them. If an enclosing object contains component instances by value, the components and their enclosing object have a similar lifetime. If the components are contained by reference, they may not have a similar lifetime. [20] For example, in Objective-C 2.0:

@interfaceCar : NSObject@propertyNSString*name;@propertyEngine*engine@propertyNSArray*tires;@end

This Car class has an instance of NSString (a string object), Engine, and NSArray (an array object).

Hierarchical

Classes can be derived from one or more existing classes, thereby establishing a hierarchical relationship between the derived-from classes (base classes, parent classes or superclasses) and the derived class (child class or subclass) . The relationship of the derived class to the derived-from classes is commonly known as an is-a relationship. [21] For example, a class 'Button' could be derived from a class 'Control'. Therefore, a Button is a Control. Structural and behavioral members of the parent classes are inherited by the child class. Derived classes can define additional structural members (data fields) and behavioral members (methods) in addition to those that they inherit and are therefore specializations of their superclasses. Also, derived classes can override inherited methods if the language allows.

Not all languages support multiple inheritance. For example, Java allows a class to implement multiple interfaces, but only inherit from one class. [22] If multiple inheritance is allowed, the hierarchy is a directed acyclic graph (or DAG for short), otherwise it is a tree. The hierarchy has classes as nodes and inheritance relationships as links. Classes in the same level are more likely to be associated than classes in different levels. The levels of this hierarchy are called layers or levels of abstraction.

Example (Simplified Objective-C 2.0 code, from iPhone SDK):

@interfaceUIResponder : NSObject//...@interfaceUIView : UIResponder//...@interfaceUIScrollView : UIView//...@interfaceUITableView : UIScrollView//...

In this example, a UITableView is a UIScrollView is a UIView is a UIResponder is an NSObject.

Modeling

In object-oriented analysis and in Unified Modelling Language (UML), an association between two classes represents a collaboration between the classes or their corresponding instances. Associations have direction; for example, a bi-directional association between two classes indicates that both of the classes are aware of their relationship. [23] Associations may be labeled according to their name or purpose. [24]

An association role is given end of an association and describes the role of the corresponding class. For example, a "subscriber" role describes the way instances of the class "Person" participate in a "subscribes-to" association with the class "Magazine". Also, a "Magazine" has the "subscribed magazine" role in the same association. Association role multiplicity describes how many instances correspond to each instance of the other class of the association. Common multiplicities are "0..1", "1..1", "1..*" and "0..*", where the "*" specifies any number of instances. [23]

Taxonomy

There are many categories of classes, some of which overlap.

Abstract and concrete

In a language that supports inheritance, an abstract class, or abstract base class (ABC), is a class that cannot be directly instantiated. By contrast, a concrete class is a class that can be directly instantiated. Instantiation of an abstract class can occur only indirectly, via a concrete subclass.

An abstract class is either labeled as such explicitly or it may simply specify abstract methods (or virtual methods ). An abstract class may provide implementations of some methods, and may also specify virtual methods via signatures that are to be implemented by direct or indirect descendants of the abstract class. Before a class derived from an abstract class can be instantiated, all abstract methods of its parent classes must be implemented by some class in the derivation chain. [25]

Most object-oriented programming languages allow the programmer to specify which classes are considered abstract and will not allow these to be instantiated. For example, in Java, C# and PHP, the keyword abstract is used. [26] [27] In C++, an abstract class is a class having at least one abstract method given by the appropriate syntax in that language (a pure virtual function in C++ parlance). [25]

A class consisting of only pure virtual methods is called a pure abstract base class (or pure ABC) in C++ and is also known as an interface by users of the language. [13] Other languages, notably Java and C#, support a variant of abstract classes called an interface via a keyword in the language. In these languages, multiple inheritance is not allowed, but a class can implement multiple interfaces. Such a class can only contain abstract publicly accessible methods. [22] [28] [29]

Local and inner

In some languages, classes can be declared in scopes other than the global scope. There are various types of such classes.

An inner class is a class defined within another class. The relationship between an inner class and its containing class can also be treated as another type of class association. An inner class is typically neither associated with instances of the enclosing class nor instantiated along with its enclosing class. Depending on the language, it may or may not be possible to refer to the class from outside the enclosing class. A related concept is inner types, also known as inner data type or nested type, which is a generalization of the concept of inner classes. C++ is an example of a language that supports both inner classes and inner types (via typedef declarations). [30] [31]

A local class is a class defined within a procedure or function. Such structure limits references to the class name to within the scope where the class is declared. Depending on the semantic rules of the language, there may be additional restrictions on local classes compared to non-local ones. One common restriction is to disallow local class methods to access local variables of the enclosing function. For example, in C++, a local class may refer to static variables declared within its enclosing function, but may not access the function's automatic variables. [32]

Metaclass

A metaclass is a class where instances are classes. [33] A metaclass describes a common structure of a collection of classes and can implement a design pattern or describe particular kinds of classes. Metaclasses are often used to describe frameworks. [34]

In some languages, such as Python, Ruby or Smalltalk, a class is also an object; thus each class is an instance of a unique metaclass that is built into the language. [4] [35] [36] The Common Lisp Object System (CLOS) provides metaobject protocols (MOPs) to implement those classes and metaclasses. [37]

Sealed

A sealed class cannot be subclassed. It is basically the opposite of an abstract class, which must be derived to be used. A sealed class is implicitly concrete.

A class declared as sealed via the keyword sealed in C# or final in Java or PHP. [38] [39] [40]

For example, Java's String class is marked as final. [41]

Sealed classes may allow a compiler to perform optimizations that are not available for classes that can be subclassed. [42]

Open

An open class can be changed. Typically, an executable program cannot be changed by customers. Developers can often change some classes, but typically cannot change standard or built-in ones. In Ruby, all classes are open. In Python, classes can be created at runtime, and all can be modified afterward. [43] Objective-C categories permit the programmer to add methods to an existing class without the need to recompile that class or even have access to its source code.

Mixin

Some languages have special support for mixins, though, in any language with multiple inheritance, a mixin is simply a class that does not represent an is-a-type-of relationship. Mixins are typically used to add the same methods to multiple classes; for example, a class UnicodeConversionMixin might provide a method called unicode_to_ascii when included in classes FileReader and WebPageScraper that do not share a common parent.

Partial

In languages supporting the feature, a partial class is a class whose definition may be split into multiple pieces, within a single source-code file or across multiple files. [44] The pieces are merged at compile time, making compiler output the same as for a non-partial class.

The primary motivation for the introduction of partial classes is to facilitate the implementation of code generators, such as visual designers. [44] It is otherwise a challenge or compromise to develop code generators that can manage the generated code when it is interleaved within developer-written code. Using partial classes, a code generator can process a separate file or coarse-grained partial class within a file, and is thus alleviated from intricately interjecting generated code via extensive parsing, increasing compiler efficiency and eliminating the potential risk of corrupting developer code. In a simple implementation of partial classes, the compiler can perform a phase of precompilation where it "unifies" all the parts of a partial class. Then, compilation can proceed as usual.

Other benefits and effects of the partial class feature include:

Partial classes have existed in Smalltalk under the name of Class Extensions for considerable time. With the arrival of the .NET framework 2, Microsoft introduced partial classes, supported in both C# 2.0 and Visual Basic 2005. WinRT also supports partial classes.

Uninstantiable

Uninstantiable classes allow programmers to group together per-class fields and methods that are accessible at runtime without an instance of the class. Indeed, instantiation is prohibited for this kind of class.

For example, in C#, a class marked "static" can not be instantiated, can only have static members (fields, methods, other), may not have instance constructors, and is sealed. [45]

Unnamed

An unnamed class or anonymous class is not bound to a name or identifier upon definition. [46] [47] This is analogous to named versus unnamed functions.

Benefits

The benefits of organizing software into object classes fall into three categories: [48]

Object classes facilitate rapid development because they lessen the semantic gap between the code and the users. System analysts can talk to both developers and users using essentially the same vocabulary, talking about accounts, customers, bills, etc. Object classes often facilitate rapid development because most object-oriented environments come with powerful debugging and testing tools. Instances of classes can be inspected at run time to verify that the system is performing as expected. Also, rather than get dumps of core memory, most object-oriented environments have interpreted debugging capabilities so that the developer can analyze exactly where in the program the error occurred and can see which methods were called to which arguments and with what arguments. [49]

Object classes facilitate ease of maintenance via encapsulation. When developers need to change the behavior of an object they can localize the change to just that object and its component parts. This reduces the potential for unwanted side effects from maintenance enhancements.

Software reuse is also a major benefit of using Object classes. Classes facilitate re-use via inheritance and interfaces. When a new behavior is required it can often be achieved by creating a new class and having that class inherit the default behaviors and data of its superclass and then tailoring some aspect of the behavior or data accordingly. Re-use via interfaces (also known as methods) occurs when another object wants to invoke (rather than create a new kind of) some object class. This method for re-use removes many of the common errors that can make their way into software when one program re-uses code from another. [50]

Runtime representation

As a data type, a class is usually considered as a compile time construct. [51] A language or library may also support prototype or factory metaobjects that represent runtime information about classes, or even represent metadata that provides access to reflective programming (reflection) facilities and ability to manipulate data structure formats at runtime. Many languages distinguish this kind of run-time type information about classes from a class on the basis that the information is not needed at runtime. Some dynamic languages do not make strict distinctions between runtime and compile time constructs, and therefore may not distinguish between metaobjects and classes.

For example, if Human is a metaobject representing the class Person, then instances of class Person can be created by using the facilities of the Human metaobject.

Prototype-based programming

In contrast to creating an object from a class, some programming contexts support object creation by copying (cloning) a prototype object. [52]

See also

Notes

    1. Gamma et al. 1995, p. 14.
    2. Bruce 2002, 2.1 Objects, classes, and object types, https://books.google.com/books?id=9NGWq3K1RwUC&pg=PA18.
    3. Gamma et al. 1995, p. 17.
    4. 1 2 "3. Data model". The Python Language Reference. Python Software Foundation. Retrieved 2012-04-26.
    5. Booch 1994, p. 86-88.
    6. "Classes (I)". C++ Language Tutorial. cplusplus.com. Retrieved 2012-04-29.
    7. "Classes (II)". C++ Language Tutorial. cplusplus.com. Retrieved 2012-04-29.
    8. Booch 1994, p. 105.
    9. Parsons, June Jamrich (2015-06-22). New Perspectives on Computer Concepts 2016, Comprehensive. Boston, MA: Cengage Learning. ISBN   9781305271616. OCLC   917155105.
    10. 1 2 "Controlling Access to Members of a Class". The Java Tutorials. Oracle. Retrieved 2012-04-19.
    11. "OOP08-CPP. Do not return references to private data". CERT C++ Secure Coding Standard. Carnegie Mellon University. 2010-05-10. Archived from the original on 2015-10-03. Retrieved 2012-05-07.
    12. Ben-Ari, Mordechai (2007-01-24). "2.2 Identifiers" (PDF). Compile and Runtime Errors in Java. Archived (PDF) from the original on 2011-10-18. Retrieved 2012-05-07.
    13. 1 2 Wild, Fred. "C++ Interfaces". Dr. Dobb's. UBM Techweb. Retrieved 2012-05-02.
    14. Thomas; Hunt. "Classes, Objects, and Variables". Programming Ruby: The Pragmatic Programmer's Guide. Ruby-Doc.org. Retrieved 2012-04-26.
    15. "Friendship and inheritance". C++ Language Tutorial. cplusplus.com. Retrieved 2012-04-26.
    16. Berfeld, Marya (2 December 2008). "UML-to-Java transformation in IBM Rational Software Architect editions and related software". IBM . Retrieved 20 December 2013.
    17. Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Object Oriented Software Engineering. Addison-Wesley ACM Press. pp.  43–69. ISBN   0-201-54435-0.
    18. Knublauch, Holger; Oberle, Daniel; Tetlow, Phil; Wallace, Evan (2006-03-09). "A Semantic Web Primer for Object-Oriented Software Developers". W3C . Retrieved 2008-07-30.
    19. Booch 1994, p. 180.
    20. Booch 1994, p. 128-129.
    21. Booch 1994, p. 112.
    22. 1 2 "Interfaces". The Java Tutorials. Oracle. Retrieved 2012-05-01.
    23. 1 2 Bell, Donald. "UML Basics: The class diagram". developer Works. IBM. Retrieved 2012-05-02.
    24. Booch 1994, p. 179.
    25. 1 2 "Polymorphism". C++ Language Tutorial. cplusplus.com. Retrieved 2012-05-02.
    26. "Abstract Methods and Classes". The Java Tutorials. Oracle. Retrieved 2012-05-02.
    27. "Class Abstraction". PHP Manual. The PHP Group. Retrieved 2012-05-02.
    28. "Interfaces (C# Programming Guide)". C# Programming Guide. Microsoft. Retrieved 2013-08-15.
    29. "Inheritance (C# Programming Guide)". C# Programming Guide. Microsoft. Retrieved 2012-05-02.
    30. "Nested classes (C++ only)". XL C/C++ V8.0 for AIX. IBM. Retrieved 2012-05-07.
    31. "Local type names (C++ only)". XL C/C++ V8.0 for AIX. IBM. Retrieved 2012-05-07.
    32. "Local classes (C++ only)". XL C/C++ V8.0 for AIX. IBM. Retrieved 2012-05-07.
    33. Booch 1994, p. 133-134.
    34. "13 Classes and metaclasses". pharo.gforge.inria.fr. Archived from the original on 2021-02-24. Retrieved 2016-10-31.
    35. Thomas; Hunt. "Classes and Objects". Programming Ruby: The Pragmatic Programmer's Guide. Ruby-Doc.org. Retrieved 2012-05-08.
    36. Booch 1994, p. 134.
    37. "MOP: Concepts". The Common Lisp Object System MetaObject Protocol. Association of Lisp Users. Archived from the original on 2010-11-15. Retrieved 2012-05-08.
    38. "sealed (C# Reference)". C# Reference. Microsoft. Retrieved 2012-05-08.
    39. "Writing Final Classes and Methods". The Java Tutorials. Oracle. Retrieved 2012-05-08.
    40. "PHP: Final Keyword". PHP Manual. The PHP Group. Retrieved 2014-08-21.
    41. "String (Java Platform SE 7)". Java Platform, Standard Edition 7: API Specification. Oracle. Retrieved 2012-05-08.
    42. Brand, Sy (2 March 2020). "The Performance Benefits of Final Classes". Microsoft C++ team blog. Microsoft. Retrieved 4 April 2020.
    43. "9. Classes". The Python Tutorial. Python.org. Retrieved 3 March 2018. As is true for modules, classes partake of the dynamic nature of Python: they are created at runtime, and can be modified further after creation.
    44. 1 2 mairaw; BillWagner; tompratt-AQ (2015-09-19), "Partial Classes and Methods", C# Programming Guide, Microsoft, retrieved 2018-08-08
    45. "Static Classes and Static Class Members (C# Programming Guide)". C# Programming Guide. Microsoft. Retrieved 2012-05-08.
    46. "Anonymous Classes (The Java Tutorials > Learning the Java Language > Classes and Objects)". docs.oracle.com. Retrieved 2021-05-13.
    47. "PHP: Anonymous classes - Manual". www.php.net. Retrieved 2021-08-11.
    48. "What is an Object?". oracle.com. Oracle Corporation. Retrieved 13 December 2013.
    49. Booch, Grady; Robert A. Maksimchuk; Michael W. Engle; Bobbi J. Young Ph.D.; Jim Conallen; Kelli A. Houston (April 30, 2007). Object-Oriented Analysis and Design with Applications. Addison-Wesley Professional. pp. 1–28. ISBN   978-0-201-89551-3 . Retrieved 20 December 2013. There are fundamental limiting factors of human cognition; we can address these constraints through the use of decomposition, abstraction, and hierarchy.
    50. Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Object Oriented Software Engineering. Addison-Wesley ACM Press. ISBN   0-201-54435-0.
    51. "C++ International standard" (PDF). Working Draft, Standard for Programming Language C++. ISO/IEC JTC1/SC22 WG21. Archived (PDF) from the original on 2017-12-09. Retrieved 5 January 2020.
    52. Amir, Masroor (25 March 2023). "OOP - Object Oriented Programming - Concepts | Languages | Benefits [2023]". The Geeks Bot | A Computer Science Site for geeks. Retrieved 2023-04-04.

    Related Research Articles

    Multiple inheritance is a feature of some object-oriented computer programming languages in which an object or class can inherit features from more than one parent object or parent class. It is distinct from single inheritance, where an object or class may only inherit from one particular object or class.

    <i>Design Patterns</i> 1994 software engineering book

    Design Patterns: Elements of Reusable Object-Oriented Software (1994) is a software engineering book describing software design patterns. The book was written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, with a foreword by Grady Booch. The book is divided into two parts, with the first two chapters exploring the capabilities and pitfalls of object-oriented programming, and the remaining chapters describing 23 classic software design patterns. The book includes examples in C++ and Smalltalk.

    In software engineering and computer science, abstraction is the process of generalizing concrete details, such as attributes, away from the study of objects and systems to focus attention on details of greater importance. Abstraction is a fundamental concept in computer science and software engineering, especially within the object-oriented programming paradigm. Examples of this include:

    A method in object-oriented programming (OOP) is a procedure associated with an object, and generally also a message. An object consists of state data and behavior; these compose an interface, which specifies how the object may be used. A method is a behavior of an object parametrized by a user.

    In programming language theory and type theory, polymorphism is the use of a single symbol to represent multiple different types.

    ABAP is a high-level programming language created by the German software company SAP SE. It is currently positioned, alongside Java, as the language for programming the SAP NetWeaver Application Server, which is part of the SAP NetWeaver platform for building business applications.

    In object-oriented programming languages, a mixin is a class that contains methods for use by other classes without having to be the parent class of those other classes. How those other classes gain access to the mixin's methods depends on the language. Mixins are sometimes described as being "included" rather than "inherited".

    In computer science, reflective programming or reflection is the ability of a process to examine, introspect, and modify its own structure and behavior.

    In object-oriented programming such as is often used in C++ and Object Pascal, a virtual function or virtual method is an inheritable and overridable function or method that is dispatched dynamically. Virtual functions are an important part of (runtime) polymorphism in object-oriented programming (OOP). They allow for the execution of target functions that were not precisely identified at compile time.

    In computing, an interface is a shared boundary across which two or more separate components of a computer system exchange information. The exchange can be between software, computer hardware, peripheral devices, humans, and combinations of these. Some computer hardware devices, such as a touchscreen, can both send and receive data through the interface, while others such as a mouse or microphone may only provide an interface to send data to a given system.

    This article compares two programming languages: C# with Java. While the focus of this article is mainly the languages and their features, such a comparison will necessarily also consider some features of platforms and libraries. For a more detailed comparison of the platforms, see Comparison of the Java and .NET platforms.

    <span class="mw-page-title-main">Java syntax</span> Set of rules defining correctly structured program

    The syntax of Java is the set of rules defining how a Java program is written and interpreted.

    <span class="mw-page-title-main">GObject</span> Free software library

    The GLib Object System, or GObject, is a free software library providing a portable object system and transparent cross-language interoperability. GObject is designed for use both directly in C programs to provide object-oriented C-based APIs and through bindings to other languages to provide transparent cross-language interoperability, e.g. PyGObject.

    In object-oriented programming, inheritance is the mechanism of basing an object or class upon another object or class, retaining similar implementation. Also defined as deriving new classes from existing ones such as super class or base class and then forming them into a hierarchy of classes. In most class-based object-oriented languages like C++, an object created through inheritance, a "child object", acquires all the properties and behaviors of the "parent object", with the exception of: constructors, destructors, overloaded operators and friend functions of the base class. Inheritance allows programmers to create classes that are built upon existing classes, to specify a new implementation while maintaining the same behaviors, to reuse code and to independently extend original software via public classes and interfaces. The relationships of objects or classes through inheritance give rise to a directed acyclic graph.

    Generics are a facility of generic programming that were added to the Java programming language in 2004 within version J2SE 5.0. They were designed to extend Java's type system to allow "a type or method to operate on objects of various types while providing compile-time type safety". The aspect compile-time type safety required that parametrically polymorphic functions are not implemented in the Java virtual machine, since type safety is impossible in this case.

    This comparison of programming languages compares how object-oriented programming languages such as C++, Java, Smalltalk, Object Pascal, Perl, Python, and others manipulate data structures.

    In computer programming, a constant is a value that is not altered by the program during normal execution. When associated with an identifier, a constant is said to be "named," although the terms "constant" and "named constant" are often used interchangeably. This is contrasted with a variable, which is an identifier with a value that can be changed during normal execution. To simplify, constants' values remains, while the values of variables varies, hence both their names.

    <span class="mw-page-title-main">Composition over inheritance</span> Software design pattern

    Composition over inheritance in object-oriented programming (OOP) is the principle that classes should favor polymorphic behavior and code reuse by their composition over inheritance from a base or parent class. Ideally all reuse can be achieved by assembling existing components, but in practice inheritance is often needed to make new ones. Therefore inheritance and object composition typically work hand-in-hand, as discussed in the book Design Patterns (1994).

    <span class="mw-page-title-main">Object-oriented programming</span> Programming paradigm based on the concept of objects

    Object-oriented programming (OOP) is a programming paradigm based on the concept of objects, which can contain data and code: data in the form of fields, and code in the form of procedures. In OOP, computer programs are designed by making them out of objects that interact with one another.

    References

    Further reading

    See also