Software Engineering: Object-Oriented Programming (Just the Quotes)

"Object-oriented programming languages support encapsulation, thereby improving the ability of software to be reused, refined, tested, maintained, and extended. The full benefit of this support can only be realized if encapsulation is maximized during the design process. […] design practices which take a data-driven approach fail to maximize encapsulation because they focus too quickly on the implementation of objects." (Rebecca Wirfs-Brock, "Object-oriented Design: A. responsibility-driven approach", 1989)

"Perhaps the greatest strength of an object-oriented approach to development is that it offers a mechanism that captures a model of the real world." (Grady Booch, "Software Engineering with Ada", 1986)

"Object-oriented programming increases the value of these metrics by managing this complexity. The most effective tool available for dealing with complexity is abstraction. Many types of abstraction can be used, but encapsulation is the main form of abstraction by which complexity is managed in object-oriented programming. Programming in an object-oriented language, however, does not ensure that the complexity of an application will be well encapsulated. Applying good programming techniques can improve encapsulation, but the full benefit of object-oriented programming can be realized only if encapsulation is a recognized goal of the design process." (Rebecca Wirfs-Brock," Object-Oriented Design: A responsibility-driven approach", 1989)

"Programming in an object-oriented language, however, does not ensure that the complexity of an application will be well encapsulated. Applying good programming techniques can improve encapsulation, but the full benefit of object-oriented programming can be realized only if encapsulation is a recognized goal of the design process." (Rebecca Wirfs-Brock, "Object-oriented Design: A responsibility-driven approach", 1989)

"In object-oriented analysis, we seek to model the world by identifying the classes and objects that form the vocabulary of the problem domain, and in object-oriented design, we invent the abstractions and mechanisms that provide the behavior that this model requires." (Grady Booch, "Object-Oriented Design: With Applications", 1991) 

"Object-oriented analysis is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain."(Grady Booch, "Object-oriented design: With Applications", 1991)

"[Object-oriented analysis is] the challenge of understanding the problem domain and then the system's responsibilities in that light." (Edward Yourdon, "Object-Oriented Design", 1991) 

"Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships." (Grady Booch, "Object-oriented design: With Applications", 1991)

"Structured design does not scale up well for extremely complex systems, and this method is largely inappropriate for use with object-based and object-oriented programming languages." (Grady Booch, "Object-oriented design: With Applications", 1991) 

"The object-oriented paradigm is useful when building software systems where there is a hierarchy defined as a ranking or ordering of abstractions. (Grady Booch, "Object-Oriented Design: With Applications", 1991)

"Whereas object-oriented analysis typically focuses upon one specific problem at a time, domain analysis seeks to identify the classes and objects that are common to all applications within a given domain, such as missile avionics systems, compilers, or accounting software." (Grady Booch, "Object-oriented design: With Applications", 1991)

"Object-oriented methods tend to focus on the lowest-level building block: the class and its objects." (Peter Coad, "Object-oriented patterns", 1992)

"Object-oriented domain analysis seeks to identify reusable items localized around objects e. g., classes, instances, systems of interacting objects, and kits." (Edward V Berard, "Essays on object-oriented software engineering", 1993)

"All OO languages show some tendency to suck programmers into the trap of excessive layering. Object frameworks and object browsers are not a substitute for good design or documentation, but they often get treated as one. Too many layers destroy transparency: It becomes too difficult to see down through them and mentally model what the code is actually doing. The Rules of Simplicity, Clarity, and Transparency get violated wholesale, and the result is code full of obscure bugs and continuing maintenance problems." (Eric S. Raymond, "The Art of Unix Programming", 2003)

"Objects are the real and conceptual things we find in the world around us. An object may be hardware, software, a concept (e. g., velocity), or even 'flesh and blood'. Objects are complete entities, i. e., they are not 'simply information' or 'simply information and actions'. Software objects strive to capture as completely as possible the characteristics of the 'real world' objects which they represent. Finally, objects are 'black boxes', i. e., their internal implementations are hidden from the outside world, and all interactions with an object take place via a well-defined interface." (Edward V Berard, "Essays onObject-Oriented Software Engineering", 1993) 

"The combination of threads, remote-procedure-call interfaces, and heavyweight object-oriented design is especially dangerous [...] if you are ever invited onto a project that is supposed to feature all three, fleeing in terror might well be an appropriate reaction." (Eric S Raymond, "The Art of UNIX Programming", 2003)

"Abstraction is the ability to engage with a concept while safely ignoring some of its details - handling different details at different levels. Any time you work with an aggregate, you're working with an abstraction. […] From a complexity point of view, the principal benefit of abstraction is that it allows you to ignore irrelevant details. Most real-world objects are already abstractions of some kind." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"Coupling describes how tightly a class or routine is related to other classes or routines. The goal is to create classes and routines with small, direct, visible, and flexible relations to other classes and routines, which is known as "loose coupling." The concept of coupling applies equally to classes and routines […] Good coupling between modules is loose enough that one module can easily be used by other modules." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"Encapsulation picks up where abstraction leaves off. Abstraction says, ‘You're allowed to look at an object at a high level of detail’. Encapsulation says, ‘Furthermore, you aren't allowed to look at an object at any other level of detail’." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"Object-oriented design is the roman numerals of computing." (Rob Pike, 2004)

"On a related topic, let me say that I'm not much of a fan of object-oriented design. I've seen some beautiful stuff done with OO, and I've even done some OO stuff myself, but it's just one way to approach a problem. For some problems, it's an ideal way; for others, it's not such a good fit. […] OO is great for problems where an interface applies naturally to a wide range of types, not so good for managing polymorphism (the machinations to get collections into OO languages are astounding to watch and can be hellish to work with), and remarkably ill-suited for network computing. That's why I reserve the right to match the language to the problem, and even - often - to coordinate software written in several languages towards solving a single problem. It's that last point - different languages for different subproblems - that sometimes seems lost to the OO crowd." (Rob Pike, [interview] 2004) 

"The steps in designing with objects are

- Identify the objects and their attributes (methods and data).

- Determine what can be done to each object.

- Determine what each object is allowed to do to other objects.

- Determine the parts of each object that will be visible to other objects—which parts will be public and which will be private.

- Define each object's public interface. 

These steps aren't necessarily performed in order, and they're often repeated. Iteration is important." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"Every system is built from a domain-specific language designed by the programmers to describe that system. Functions are the verbs of that language, and classes are the nouns."  (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work." (Alexander Stepanov, [Interview with A. Stepanov] 2008)

"We do not want to expose the details of our data. Rather we want to express our data in abstract terms. This is not merely accomplished by using interfaces and/or getters and setters. Serious thought needs to be put into the best way to represent the data that an object contains. The worst option is to blithely add getters and setters." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"[Object-oriented analysis is] the challenge of understanding the problem domain and then the system's responsibilities in that light." (Ed Yourdon)

"Strive for class interfaces that are complete and minimal." (Scott Meyers) 

Software Engineering: Design Patterns (Just the Quotes)

"A pattern is a fully realized form original, or model accepted or proposed for imitation. With patterns, small piecework is standardized into a larger chunk or unit. Patterns become the building blocks for design and construction. Finding and applying patterns indicates progress in a field of human endeavor." (Peter Coad, "Object-oriented patterns", 1992) 

"A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context." (Erich Gamma et al, "Design Patterns: Elements of Reusable Object-Oriented Software", 1994)

"The purpose of a conceptual model is to provide a vocabulary of terms and concepts that can be used to describe problems and/or solutions of design. It is not the purpose of a model to address specific problems, and even less to propose solutions for them. Drawing an analogy with linguistics, a conceptual model is analogous to a language, while design patterns are analogous to rhetorical figures, which are predefined templates of language usages, suited particularly to specific problems." (Peter P Chen [Ed.], "Advances in Conceptual Modeling", 1999)

"In addition to their complexity-management benefit, design patterns can accelerate design discussions by allowing designers to think and discuss at a larger level of granularity." (Steve McConnell, "Code Complete" 2nd Ed., 2004)

"On small, informal projects, a lot of design is done while the programmer sits at the keyboard. 'Design' might be just writing a class interface in pseudocode before writing the details. It might be drawing diagrams of a few class relationships before coding them. It might be asking another programmer which design pattern seems like a better choice. Regardless of how it’s done, small projects benefit from careful design just as larger projects do, and recognizing design as an explicit activity maximizes the benefit you will receive from it." (Steve McConnell, "Code Complete" 2nd Ed., 2004)

"Software design patterns are what allow us to describe design fragments, and reuse design ideas, helping developers leverage the expertise of others. Patterns give a name and form to abstract heuristics, rules and best practices of object-oriented techniques." (Philippe Kruchten, [foreword] 2004)

"Design patterns give names to practical knowledge; they define a high-level vocabulary for understanding and solving business statements graphically. Design patterns are presented in a standard format; they're like recipes in a cookbook or dress patterns in a catalog. Above all, they are practical, first as instructional materials and then as development tools." (Alan Chmura & J Mark Heumann, "Logical Data Modeling: What it is and How to do it", 2005)

"Structural patterns describe how classes and objects can be combined to form larger structures. Patterns for classes describe how inheritance can be used to provide more useful program interfaces. Patterns for objects describe how objects can be composed into larger structures using object composition." (Junji Nakano et al, "Programming Statistical Data Visualization in the Java Language" [in "Handbook of Data Visualization"], 2008)

"Design patterns are high-level abstractions that document successful design solutions. They are fundamental to design reuse in object-oriented development." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"Most designers think of design patterns as a way of supporting object-oriented design. Patterns often rely on object characteristics such as inheritance and polymorphism to provide generality. However, the general principle of encapsulating experience in a pattern is one that is equally applicable to all software design approaches." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"A design pattern usually suggests a scheme for structuring the classes in a design solution and defines the required interactions among those classes. In other words, a design pattern describes some commonly recurring structure of communicating classes that can be used to solve some general design problems. Design pattern solutions are typically described in terms of classes, their instances, their roles and collaborations." (Rajib Mall, "Fundamentals of Software Engineering" 4th Ed., 2014)

"If a pattern represents a best practice, then an antipattern represents lessons learned from a bad design. [...] Antipatterns are valuable because they help us to recognise why a particular design alternative might seem at first like an attractive solution, but later on lead to complicacies and finally turn out to be a poor solution." (Rajib Mall, "Fundamentals of Software Engineering" 4th Ed., 2014)

"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.''  (Christopher Alexander)

Software Engineering: Object-Oriented Design (Definitions)

"The process of designing a computer application that utilizes OOP concepts in the design to show active objects that are to be developed." (Greg Perry, "Sams Teach Yourself Beginning Programming in 24 Hours" 2nd Ed., 2001)

"The specification of a logical software solution in terms of software objects, such as their classes, attributes, methods, and collaborations." (Craig Larman, "Applying UML and Patterns", 2004)

"The craft of partitioning the system into objects, organizing the objects into class hierarchies, and devising messages that communicate between the objects. See the Bibliography for references on this subject." (James Robertson et al, "Complete Systems Analysis: The Workbook, the Textbook, the Answers", 2013)

"A modular approach to system design in which functions are logically grouped together along with their data structures into objects. These objects generally correspond to logical real-world entities and interact with other objects through well-defined interfaces and hide their internal data structures to protect them from error by objects that have no need to know the internal workings of the object." (O Sami Saydjari, "Engineering Trustworthy Systems: Get Cybersecurity Design Right the First Time", 2018)

"A software engineering approach that models a system as a group of interacting objects. Each object represents some entity of interest in the system being modeled, and is characterized by its class, its state (data elements), and its behavior. OOAD encompasses Object-oriented analysis (OOA) and Object-oriented design (OOD)." (IQBBA) 

Peter Coad - Collected Quotes

"More effective analysis requires the use of problem domain constructs, both for present reuse and for future reuse." (Peter Coad & Edward Yourdon, "Object-Oriented Analysis" 2nd Ed., 1991)

"One of the biggest problems faced by analysts is studying the problem domain and making discoveries about it. [...] OOA is the challenge of understanding the problem domain, and then the system's responsibilities in that light." (Peter Coad & Edward Yourdon, "Object-Oriented Analysis" 2nd Ed., 1991)

"One of the critical success factors for any method and its application is its ability to facilitate communication, avoiding information  overload. So for larger models, the question is how to guide the reader into different parts of the model." (Peter Coad & Edward Yourdon, "Object-Oriented Analysis" 2nd Ed., 1991)

"The transition from analysis to design has been a constant source of frustration. [...] no matter how many cute cartoons are drawn to depict the transition, the radical change in underlying representation causes a major chasm between analysis and design models." (Peter Coad & Edward Yourdon, "Object-Oriented Analysis" 2nd Ed., 1991)

"A pattern is a fully realized form original, or model accepted or proposed for imitation. With patterns, small piecework is standardized into a larger chunk or unit. Patterns become the building blocks for design and construction. Finding and applying patterns indicates progress in a field of human endeavor." (Peter Coad, "Object-oriented patterns", 1992)

"Object-oriented methods tend to focus on the lowest-level building block: the class and its objects." (Peter Coad, "Object-oriented patterns", 1992)

"With each pattern, small piecework is standardized into a larger chunk or unit. Patterns become the building blocks for design and construction. Finding and applying patterns indicates progress in a field of human endeavor." (Peter Coad, "Object-oriented patterns", 1992)

"We think most process initiatives are silly. Well-intentioned managers and teams get so wrapped up in executing processes that they forget that they are being paid for results, not process execution. (Peter Coad et al, "Java Modeling in Color with UML", 1999)

Stephen J Mellor - Collected Quotes

"When partitioning a domain, we divide the information model so that the clusters remain intact. [...] Each section of the information model then becomes a separate subsystem. Note that when the information model is partitioned into subsystems, each object is assigned to exactly one subsystem." (Stephen J Mellor, "Object-Oriented Systems Analysis: Modeling the World In Data", 1988) 

"While a small domain (consisting of fifty or fewer objects) can generally be analyzed as a unit, large domains must be partitioned to make the analysis a manageable task. To make such a partitioning, we take advantage of the fact that objects on an information model tend to fall into clusters: groups of objects that are interconnected with one another by many relationships. By contrast, relatively few relationships connect objects in different clusters." (Stephen J Mellor, "Object-Oriented Systems Analysis: Modeling the World In Data", 1988)

"Executable UML is at the next higher layer of abstraction, abstracting away both specific programming languages and decisions about the organization of the software so that a specification built in Executable UML can be deployed in various software environments without change." (Stephen J Mellor, "Executable UML: A Foundation for Model-Driven Architecture", 2002)

"Executable UML is designed to produce a comprehensive and comprehensible model of a solution without making decisions about the organization of the software implementation. It is a highly abstract thinking tool to aid in the formalization of knowledge, a way of thinking about and describing the concepts that make up an abstract solution to a client problem." (Stephen J Mellor, "Executable UML: A Foundation for Model-Driven Architecture", 2002)

"In the bad old days before MDA, (conceptual) models served only to facilitate communication between customers and developers and act as blueprints for construction. Nowadays, MDA establishes the infrastructure for defining and executing transformations between models of various kinds." (Stephen J Mellor, "Executable UML: A Foundation for Model-Driven Architecture", 2002)

"We build models to increase productivity, under the justified assumption that it's cheaper to manipulate the model than the real thing. Models then enable cheaper exploration and reasoning about some universe of discourse. One important application of models is to understand a real, abstract, or hypothetical problem domain that a computer system will reflect. This is done by abstraction, classification, and generalization of subject-matter entities into an appropriate set of classes and their behavior." (Stephen J Mellor, "Executable UML: A Foundation for Model-Driven Architecture", 2002)

"What's the point of having metamodels, and why should you care? Because models must be stated in a way that yields a common understanding among all involved parties, we need a way to specify exactly what a model means. Metamodels allow you to do just that: They specify the concepts of the language you're using to specify a model." (Stephen J Mellor, "MDA Distilled. Principles of Model-Driven Architecture", 2003)

Rebecca Wirfs-Brock - Collected Quotes

"A subsystem is a set of classes (and possibly other subsystems) collaborating to fulfill a set of responsibilities. Although subsystems do not exist as the software executes, they are useful conceptual entities." (Rebecca Wirfs-Brock, "Object-oriented Design: A. responsibility-driven approach", 1989)

"Encapsulation is the key to increasing the value of such software metrics as reusability, refinability, testability, maintainability, and extensibility. Object-oriented languages provide a number of mechanisms for improving encapsulation, but it is during the design phase that the greatest leverage can be realized." (Rebecca Wirfs-Brock, "Object-oriented design: a responsibility-driven approach", 1989)

"Frameworks are white boxes to those that make use of them. Application developers must be able to quickly understand the structure of a framework, and how to write code that will fit into the framework. Frameworks are reusable designs as well as reusable code." (Rebecca Wirfs-Brock, "Object-oriented Design: A. responsibility-driven approach", 1989)

"Object-oriented programming languages support encapsulation, thereby improving the ability of software to be reused, refined, tested, maintained, and extended. The full benefit of this support can only be realized if encapsulation is maximized during the design process. […] design practices which take a data-driven approach fail to maximize encapsulation because they focus too quickly on the implementation of objects." (Rebecca Wirfs-Brock, "Object-oriented Design: A. responsibility-driven approach", 1989)

"Object-oriented programming increases the value of these metrics by managing this complexity. The most effective tool available for dealing with complexity is abstraction. Many types of abstraction can be used, but encapsulation is the main form of abstraction by which complexity is managed in object-oriented programming. Programming in an object-oriented language, however, does not ensure that the complexity of an application will be well encapsulated. Applying good programming techniques can improve encapsulation, but the full benefit of object-oriented programming can be realized only if encapsulation is a recognized goal of the design process." (Rebecca Wirfs-Brock," Object-Oriented Design: A responsibility-driven approach", 1989)

"Programming in an object-oriented language, however, does not ensure that the complexity of an application will be well encapsulated. Applying good programming techniques can improve encapsulation, but the full benefit of object-oriented programming can be realized only if encapsulation is a recognized goal of the design process." (Rebecca Wirfs-Brock, "Object-oriented Design: A responsibility-driven approach", 1989)

"The data-driven approach to object-oriented design focuses on the structure of the data in a system. This results in the incorporation of structural information in the definitions of classes. Doing so violates encapsulation. The responsibility-driven approach emphasizes the encapsulation of both the structure and behavior of objects. By focusing on the contractual responsibilities of a class, the designer is able to postpone implementation considerations until the implementation phase. While responsibility-driven design is not the only technique addressing this problem, most other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits." (Rebecca Wirfs-Brock, "Object-oriented design: a responsibility-driven approach", 1989)

"Responsibility-driven design specifies object behavior before object structure and other implementation considerations are determined. We have found that it minimizes the rework required for major design changes." (Rebecca Wirfs-Brock, "Object-oriented design: a responsibility-driven approach", 1989)

"Users can work with analysts and object designers to formulate and tune system requirements. People from business, analytical and object design disciplines can come together, learn from each other and generate meaningful descriptions of systems that are to be built. Each participant and each project has slightly different concerns and needs. Practical application of use cases can go a long way to improve our ability to deliver just what the customer ordered. (Rebecca Wirfs-Brock, "Designing scenarios: Making the case for a use case framework", 1993)

"An object-oriented application is a set of interacting objects. Each object is an implementation of one or more roles. A role supports a set of related (cohesive) responsibilities. A responsibility is an obligation to perform a task or know certain information. And objects don't work in isolation, they collaborate with others in a community to perform the overall responsibilities of the application. So a conceptual view, at least to start, is a distillation of the key object roles and their responsibilities (stated at a fairly high level). More than likely (unless you form classification hierarchies and use inheritance and composition techniques) many candidates you initially model will map directly to a single class in some inheritance hierarchy. But I like to open up possibilities by think first of roles and responsibilities, and then as a second step towards a specification-level view, mapping these candidates to classes and interfaces." (Rebecca Wirfs-Brock, [interview] 2003)

Grady Booch (Collected Quotes)

"An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of object and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer." (Grady Booch, "Object-Oriented Design with Applications", 1991)

"[...] encapsulation - also known as information hiding - prevents clients from seeing its inside view, were the behavior of the abstraction is implemented." (Grady Booch, "Object-Oriented Design With Applications", 1991)

"Every software system needs to have a simple yet powerful organizational philosophy (think of it as the software equivalent of a sound bite that describes the system's architecture). [A] step in [the] development process is to articulate this architectural framework, so that we might have a stable foundation upon which to evolve the system's function points." (Grady Booch, "Object-Oriented Design: with Applications", 1991)

"In object-oriented analysis, we seek to model the world by identifying the classes and objects that form the vocabulary of the problem domain, and in object-oriented design, we invent the abstractions and mechanisms that provide the behavior that this model requires." (Grady Booch, "Object-Oriented Design: With Applications", 1991) 

"Object-oriented analysis is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain."(Grady Booch, "Object-oriented design: With Applications", 1991)

"Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships." (Grady Booch, "Object-oriented design: With Applications", 1991)

"Structured design does not scale up well for extremely complex systems, and this method is largely inappropriate for use with object-based and object-oriented programming languages." (Grady Booch, "Object-oriented design: With Applications", 1991) 

"The object-oriented paradigm is useful when building software systems where there is a hierarchy defined as a ranking or ordering of abstractions. (Grady Booch, "Object-Oriented Design: With Applications", 1991)

"Whereas object-oriented analysis typically focuses upon one specific problem at a time, domain analysis seeks to identify the classes and objects that are common to all applications within a given domain, such as missile avionics systems, compilers, or accounting software." (Grady Booch, "Object-oriented design: With Applications", 1991)

"As a noun, design is the named (although sometimes unnamable) structure or behavior of a system whose presence resolves or contributes to the resolution of a force or forces on that system. A design thus represents one point in a potential decision space. A design may be singular (representing a leaf decision) or it may be collective (representing a set of other decisions). As a verb, design is the activity of making such decisions. Given a large set of forces, a relatively malleable set of materials, and a large landscape upon which to play, the resulting decision space may be large and complex. As such, there is a science associated with design (empirical analysis can point us to optimal regions or exact points in this design space) as well as an art (within the degrees of freedom that range beyond an empirical decision; there are opportunities for elegance, beauty, simplicity, novelty, and cleverness). All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change." (Grady Booch, "On design", 2006)

OOP: Attribute (Definitions)

"Additional characteristics or information defined for an entity." (Owen Williams, "MCSE TestPrep: SQL Server 6.5 Design and Implementation", 1998)

"A named characteristic or property of a class." (Craig Larman, "Applying UML and Patterns", 2004)

"A characteristic, quality, or property of an entity class. For example, the properties 'First Name' and 'Last Name' are attributes of entity class 'Person'." (Danette McGilvray, "Executing Data Quality Projects", 2008)

"Another name for a field, used by convention in many object-oriented programming languages. Scala follows Java’s convention of preferring the term field over attribute." (Dean Wampler & Alex Payne, "Programming Scala", 2009)

"1. (UML diagram) A descriptor of a kind of information captured about an object class. 2. (Relational theory) The definition of a descriptor of a relation." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

"A fact type element (specifically a characteristic assignment) that is a descriptor of an entity class." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

"A characteristic of an object." (Requirements Engineering Qualifications Board, "Standard glossary of terms used in Requirements Engineering", 2011)

"An inherent characteristic, an accidental quality, an object closely associated with or belonging to a specific person, place, or office; a word ascribing a quality." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

OOP: Contract (Definitions)

"A guarantee between a definer and a user. An example of a contract is the methods in an interface type. In adding the interface type to its definition, a type agrees to the contract specified by the interface type. Contracts vary from strictly enforceable, such as verifying that a function's signature conforms to a contract (syntax correctness), to assuming consistent behavior among classes implementing a common contract (semantic correctness). Semantic contracts are more difficult to specify and verify." (Damien Watkins et al, "Programming in the .NET Environment", 2002) 

[design by contract] "A paradigm stating that each software element (e.g., a method) specifies in a contract the pre-conditions it requires to run, the post-conditions it will ensure upon completion, and which invariants will remain." (Johannes Link & Peter Fröhlich, "Unit Testing in Java", 2003)

"Defines the responsibilities and postconditions that apply to the use of an operation or method. Also used to refer to the set of all conditions related to an interface." (Craig Larman, "Applying UML and Patterns", 2004)

"A service is usually described by an interface. The complete description of a service from a consumer’s point of view (signature and semantics) is called a 'well-defined interface' or contract." (Nicolai M Josuttis, "SOA in Practice", 2007)

"The complete description of a service interface between one consumer and one provider. It includes the technical interface (signature), the semantics, and nonfunctional aspects such as service-level agreements." (Nicolai M Josuttis, "SOA in Practice", 2007)

"A statement by the developer of a component about what the component does; users of the component rely on this statement to design systems using the component." (W Roy Schulte & K Chandy, "Event Processing: Designing IT Systems for Agile Companies", 2009)

"The protocol and requirements that exist between a module (e.g., class, trait, object, or even function or method) and clients of the module. More specifically, see Design by Contract." (Dean Wampler & Alex Payne, "Programming Scala", 2009)

[data contract:] "In WCF, a data contract is one that permits the definition of messages with multiple parameters." (Bruce Bukovics, "Pro WF: Windows Workflow in .NET 4", 2010)

[design by contract] "An approach to class and module design invented by Bertrand Meyer for the Eiffel language. For each entry point, valid inputs are specified in a programmatic way, so they can be validated during testing. These specifications are called preconditions. Similarly, assuming the preconditions are specified, specifications on the guaranteed results are called postconditions and are also specified in an executable way. Invariants can also be specified that should be true on entry and on exit." (Dean Wampler & Alex Payne, "Programming Scala", 2009)

OOP: Polymorphism (Definitions)

"Literally, from the Greek for many forms, and refers to the ability of different objects to respond differently to the same commands." (Greg Perry, "Sams Teach Yourself Beginning Programming in 24 Hours" 2nd Ed., 2001)

"The ability to treat many sub-types as if they were of the same base type." (Jesse Liberty, "Sams Teach Yourself C++ in 24 Hours" 3rd Ed., 2001)

"The capability of objects from different classes to accept the same message." (Stephen G Kochan, "Programming in Objective-C", 2003)

"The concept that two or more classes of objects can respond to the same message in different ways, using polymorphic operations. Also, the ability to define polymorphic operations." (Craig Larman, "Applying UML and Patterns", 2004)

"In object-oriented design, the principle that the same definition can be used with different types of data (specifically, different class implementations), resulting in more general and abstract implementations." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

"The redefinition of the body of a superclass method inherited by a subclass. The polymorphic method retains the same signature." (Jan L Harrington, "SQL Clearly Explained" 3rd Ed., 2010)

"The ability of a piece of code to work with more than one type." (Mark C Lewis, "Introduction to the Art of Programming Using Scala", 2012)

"The notion that you can tell an object to do something generic, and the object will interpret the command in different ways depending on its type." (Jon Orwant et al, "Programming Perl, 4th Ed.", 2012)

"The ability of a language to determine at runtime which of several possible methods will be executed for a given invocation" (Nell Dale & John Lewis, "Computer Science Illuminated" 6th Ed., 2015)

"The ability to treat a child object as if it were actually from a parent class. For example, it lets you treat a Student object as if it were a Person object because a Student is a type of Person." (Rod Stephens, "Beginning Software Engineering", 2015)

"Two objects can receive the same input and have different outputs." (Adam Gordon, "Official (ISC)2 Guide to the CISSP CBK" 4th Ed., 2015)

"The ability of an object variable to reference objects of different classes at different times during the execution of a program" (Nell Dale et al, "Object-Oriented Data Structures Using Java" 4th Ed., 2016)

"One of the fundamental principles of an object-oriented language. Polymorphism states that a type that extends another type is a “kind of” the parent type and can be used interchangeably with the original type by augmenting or refining its capabilities." (Daniel Leuck et al, "Learning Java" 5th Ed., 2020)

OOP: Abstraction (Definitions)

"A view of a problem that extracts the essential information relevant to a particular purpose and ignores the remainder of the information." (IEEE, 1983)

"[A] simplified description, or specification, of a system that emphasizes some of the system's details or properties while suppressing others. A good abstraction is one that emphasizes details that are significant to the reader or user and suppress details that are, at least for the moment, immaterial or diversionary." (M Shaw, Abstraction Techniques in Modern Programming Languages", IEEE Software Vol. 1 (4), 1984)

"[abstraction:] (1) A view of an object that focuses on the information relevant to a particular purpose and ignores the remainder of the information.(2) The process of formulating a view as in (1)."(IEEE," IEEE Standard Glossary of Software Engineering Terminology", 1990)  

"[data abstraction:] (1) The process of extracting the essential characteristics of data by defining data types and their associated functional characteristics and disregardng representation details. (2) The result of the process in (1)." (IEEE," IEEE Standard Glossary of Software Engineering Terminology", 1990) 

"Abstraction is a process whereby we identify the important aspects of a phenomenon and ignore its details." (Ghezzi et al, Fundamentals of Software Engineering, 1991)

"Abstraction is generally defined as 'the process of formulating generalised concepts by extracting common qualities from specific examples.'" (Blair et al, "Object-Oriented Languages, Systems and Applications", 1991)

"An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of object and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer." (Grady Booch, Object-Oriented Design With Applications, 1991)

"The act of concentrating the essential or general qualities of similar things. Also, the resulting essential characteristics of a thing." (Craig Larman, "Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process", 1997)

"Abstraction is the purposeful suppression, or hiding, of some details of a process or artifact, in order to bring out more clearly other aspects, details, or structure." (Timothy Budd, "An Introduction to Object-Oriented Programming" 3rd Ed., 2002)

"Abstraction can have several meanings depending on the context. In software, it often means combining a set of small operations or data items and giving them a name. For example, control abstraction takes a group of operations, combines them into a procedure, and gives the procedure a name. As another example, a class in object-oriented programming is an abstraction of both data and control. More generally, an abstraction is a representation that captures the essential character of an entity, but hides the specific details. Often we will talk about a named abstraction without concern for the actual details, which may not be determined." (Beverly A Sanders, "Patterns for Parallel Programming", 2004)

"Abstraction, as a process, denotes the extracting of the essential details about an item, or a group of items, while ignoring the inessential details. Abstraction, as an entity, denotes a model, a view, or some other focused representation for an actual item." (Edward V Berard, "Abstraction, Encapsulation, and Information Hiding", cca. 2006)

"The idea of minimizing the complexity of something by hiding the details and just providing the relevant information. It’s about providing a high-level specification rather than going into lots of detail about how something works. In the cloud, for instance, in an IaaS delivery model, the infrastructure is abstracted from the user." (Marcia Kaufman et al, "Big Data For Dummies", 2013)

"Minimizing the complexity of something by hiding the details and just providing the relevant information. It’s about providing a high-level specification rather than going into a lot of detail about how something works. In the cloud, for instance, in an IaaS delivery model, the infrastructure is abstracted from the user." (Judith S Hurwitz, "Cognitive Computing and Big Data Analytics", 2015)

"A model of a complex system that includes only the details essential to the viewer" (Nell Dale & John Lewis, "Computer Science Illuminated, 6th Ed.", 2015)

"The capability to suppress unnecessary details so the important, inherent properties can be examined and reviewed." (Adam Gordon, "Official (ISC)2 Guide to the CISSP CBK" 4th Ed., 2015)

"A model of a system that includes only the details essential to the perspective of the viewer of the system" (Nell Dale et al, "Object-Oriented Data Structures Using Java" 4th Ed., 2016)

"Way of expressing an idea in a specific context while at the same time suppressing details irrelevant in that context." (Karl Beecher, "Computational Thinking - A beginner's guide to problem-solving and programming", 2017)

"The act of representing essential features while hiding the details to reduce complexity." (O Sami Saydjari, "Engineering Trustworthy Systems: Get Cybersecurity Design Right the First Time", 2018)

"The deliberate reduction in dependency between a component and other components it works with is a way to make the component generally more useful." (Judith Hurwitz et al, "Service Oriented Architecture For Dummies" 2nd Ed., 2009)

OOP: Visibility (Definitions)

[COM Visibility:] "Indicates whether a .NET type or member is accessible from COM. Anything public in .NET is visible to COM unless it’s marked with the ComVisibleAttribute custom attribute with its argument set to false, or its containing assembly is marked with the attribute with its argument set to false." (Adam Nathan, ".NET and COM: The Complete Interoperability Guide", 2002)

"The level of access granted to other classes or variables. Indicates whether something can be 'seen' from a location in a program." (Marcus Green & Bill Brogden, "Java 2™ Programmer Exam Cram™ 2 (Exam CX-310-035)", 2003)

"The ability to see or have reference to an object." (Craig Larman, "Applying UML and Patterns", 2004)

"Ability to enforce fine-grained access to and operations on data at the record, attribute, and attribute-value levels based on user entitlements and data usage and access policies." (Alex Berson & Lawrence Dubov, "Master Data Management and Data Governance", 2010)

"An attribute of operation in object-oriented design that tells whether the operation can be 'seen' by any program, or whether it is 'private' - only accessible within the model involved." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

"The scope in which a declared type or type member is visible to other types and members." (Dean Wampler, "Functional Programming for Java Developers", 2011)

OOP: Encapsulation (Definitions)

"It is a simple, yet reasonable effective, system-building tool. It allows suppliers to present cleanly specified interfaces around the services they provide. A consumer has full visibility to the procedures offered by an object, and no visibility to its data. From a consumer's point of view, and object is a seamless capsule that offers a number of services, with no visibility as to how these services are implemented [...] technical term for this is encapsulation." (Brad J Cox, "Object Oriented Programming: An Evolutionary Approach", 1986)

A software development technique that consists of isolating a system function or a set of data and operations on those data within a module and providing precise specifications for the module. (IEEE," IEEE Standard Glossary of Software Engineering Terminology", 1990)

"The concept of encapsulation as used in an object-oriented context is not essentially different from its dictionary definition. It still refers to building a capsule, in the case a conceptual barrier, around some collection of things." (Rebecca Wirfs-Brock et al, "Designing Object-Oriented Software", 1990]

"Encapsulation or equivalently information hiding refers to the practice of including within an object everything it needs, and furthermore doing this in such a way that no other object need ever be aware of this internal structure." (Ian Graham, "Object-Oriented Methods", 1991]

"Data hiding is sometimes called encapsulation because the data and its code are put together in a package or 'capsule.'" (David N Smith, "Concepts of Object-Oriented Programming", 1991)

"Encapsulation is used as a generic term for techniques which realize data abstraction. Encapsulation therefore implies the provision of mechanisms to support both modularity and information hiding. There is therefore a one to one correspondence in this case between the technique of encapsulation and the principle of data abstraction." (Gordon Blair et al, "Object-Oriented Languages, Systems and Applications", 1991)

"Encapsulation (also information hiding) consists of separating the external aspects of an object which are accessible to other objects, from the internal implementation details of the object, which are hidden from other objects." (James Rumbaugh et al, "Object-Oriented Modeling and Design", 1991)

"[...] encapsulation - also known as information hiding - prevents clients from seeing its inside view, were the behavior of the abstraction is implemented." (Grady Booch, "Object-Oriented Design With Applications", 1991)

"We say that the changeable, hidden information becomes the secret of the module; also, according to a widely used jargon, we say that such information is encapsulated within the implementation." (Carlo Ghezzi et al, "Fundamentals of Software Engineering", 1991]

"As a process, encapsulation means the act of enclosing one or more items within a (physical or logical) container. Encapsulation, as an entity, refers to a package or an enclosure that holds (contains, encloses) one or more items. It is extremely important to note that nothing is said about 'the walls of the enclosure'. Specifically, they may be 'transparent', 'translucent', or even 'opaque'." Compare with information hiding, which implies invisibility." (Bill Pribyl & Steven Feuerstein, "Learning Oracle PL/SQL", 2001)

"Encasing information and behavior within an object so that its structure and implementation are hidden to other objects that interact with it." (Marcus Green & Bill Brogden, "Java 2 Programmer Exam Cram 2 (Exam CX-310-035)", 2003)

"A mechanism used to hide the data, internal structure, and implementation details of some element, such as an object or subsystem. All interaction with an object is through a public interface of operations." (Craig Larman, "Applying UML and Patterns", 2004)

"An object-oriented technique that may hide, or abstract, the inner workings of an object and expose only the relevant characteristics and operations on the object to other objects." (Bob Bryla, "Oracle Database Foundations", 2004)

"Restricting the visibility of members of a type so they are not visible to clients of the type when they shouldn’t be. This is a way of exposing only the abstraction supported by the type, while hiding implementation details, which prevents unwanted access to them from clients and keeps the abstraction exposed by the type consistent and minimal." (Dean Wampler & Alex Payne, "Programming Scala", 2009)

"In object-oriented design, the principle that it should be possible to refer to an object with behavior and not know anything about how that behavior is implemented." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

"Detail hiding. A class hides its internal details so the rest of the program doesn't need to understand how they work, just how to use them." (Rod Stephens, "Stephens' Visual Basic® Programming 24-Hour Trainer", 2011)

"(1) A language mechanism for restricting access to some of an object’s components. (2) A language construct that facilitates the bundling of data with methods (or other functions) operating on that data." (Craig S Mullins, "Database Administration: The Complete Guide to DBA Practices and Procedures", 2012)

"The veil of abstraction separating the interface from the implementation (whether enforced or not), which mandates that all access to an object’s state be through methods alone." (Jon Orwant et al, "Programming Perl" 4th Ed., 2012)

"A language feature that enforces information hiding; bundling data and actions so that the logical properties of data and actions are separated from the implementation details" (Nell Dale & John Lewis, "Computer Science Illuminated" 6th Ed., 2015)

"The bundling of data with the procedures that operate on that data, such that data may only be changed by those procedures - a technique for reducing program complexity." (O Sami Saydjari, "Engineering Trustworthy Systems", 2018)

"The object-oriented programming technique of limiting the exposure of variables and methods to simplify the API of a class or package. Using the private and protected keywords, a programmer can limit the exposure of internal ('black box') parts of a class. Encapsulation reduces bugs and promotes reusability and modularity of classes. This technique is also known as data hiding." (Daniel Leuck et al, "Learning Java" 5th Ed., 2020)

OOP: Inheritance (Definitions)

"Creating a new type that can extend the characteristics of an existing type." (Jesse Liberty, "Sams Teach Yourself C++ in 24 Hours" 3rd Ed., 2001)

"The ability of one data object to gain characteristics from another object." (Greg Perry, "Sams Teach Yourself Beginning Programming in 24 Hours" 2nd Ed., 2001)

"The process of passing methods and instance variables from a class, starting with the root object down to subclasses." (Stephen G Kochan, "Programming in Objective-C", 2003)

"A feature of object-oriented programming languages by which classes may be specialized from more general superclasses. Attributes and method definitions from superclasses are automatically acquired by the subclass." (Craig Larman, "Applying UML and Patterns", 2004)

"Acquiring the properties of the parent, or base object, in a new object." (Bob Bryla, "Oracle Database Foundations", 2004)

"The ability of a class to inherit features from another class via the < operator. See multiple inheritance, single inheritance." (Michael Fitzgerald, "Learning Ruby", 2007)

"A strong relationship between one class or trait and another class or trait. The inheriting (derived) class or trait incorporates the members of the parent class or trait, as if they were defined within the derivative. The derivative may override inherited members (in most cases). Instances of a derivative are substitutable for instances of the parent." (Dean Wampler & Alex Payne, "Programming Scala", 2009)

"A general to specific relationship between classes in an object-oriented environment." (Jan L Harrington, "SQL Clearly Explained 3rd Ed. ", 2010)

"A strong coupling between one class or interface and another. The inheriting (derived) class or interface incorporates the members of the parent class or interface, as if they were defined within the derivative. Hence, inheritance is a form of reuse. The derivative may override inherited members (unless declared final). For a properly defined derived type, instances of it are substitutable for instances of the parent, satisfying the Liskov Substitution Principle." (Dean Wampler, "Functional Programming for Java Developers", 2011)

"The process of passing methods and instance variables from a class, starting with the root object, down to subclasses." (Stephen G Kochan, "Programming in Objective-C" 4th Ed., 2011)

"What you get from your ancestors, genetically or otherwise. If you happen to be a class, your ancestors are called base classes and your descendants are called derived classes. See single inheritance and multiple inheritance." (Jon Orwant et al, "Programming Perl" 4th Ed., 2012)

"Building a class from the basic functionality of an existing class and then adding new functions." (Matt Telles, "Beginning Programming", 2014)

"A mechanism by which one class acquires the properties - data fields and methods - of another class" (Nell Dale & John Lewis, "Computer Science Illuminated" 6th Ed., 2015)

"An important feature of object-oriented programming that involves defining a new object by changing or refining the behavior of an existing object. Through inheritance, an object implicitly contains all of the non-private variables and methods of its superclass. Java supports single inheritance of classes and multiple inheritance of interfaces." (Daniel Leuck et al, "Learning Java" 5th Ed., 2020)

OOP: Function (Definitions)

"(1) A defined objective or characteristic action of a system or component. For example, a system may have inventory control as its primary function. (2) A software module that performs a specific action, is invoked by the appearance of its name in an expression, may receive input values, and returns a single value." (IEEE," IEEE Standard Glossary of Software Engineering Terminology", 1990) 

"A set of instructions that operates as a single logical unit, can be called by name, accepts input parameters, and returns information. In programming languages such as C, a function is a named subroutine of a program that encapsulates some logic. The function can be called by name, using parameters to pass data into the function and retrieve data produced by the function." (Microsoft Corporation, "SQL Server 7.0 System Administration Training Kit", 1999)

"A block of code that performs a service, such as adding two numbers or printing to the screen." (Jesse Liberty, "Sams Teach Yourself C++ in 24 Hours" 3rd Ed., 2001)

"A program that returns a value to the program or environment from which it is called." (Bill Pribyl & Steven Feuerstein, "Learning Oracle PL/SQL", 2001)

"A routine that processes data inside a program." (Greg Perry, "Sams Teach Yourself Beginning Programming in 24 Hours" 2nd Ed., 2001)

"A block of statements identified by a name that can accept one or more arguments passed to it by value and can optionally return a value. Functions can be local (static) to the file in which they're defined or global, in which case they can be called from functions or methods defined in other files." (Stephen G Kochan, "Programming in Objective-C", 2003)

"A named set of predefined programming language commands that performs a specific task given zero, one, or more arguments and returns a value." (Bob Bryla, "Oracle Database Foundations", 2004)

"A piece of code that operates as a single logical unit. A function is called by name, accepts optional input parameters, and returns a status and optional output parameters. Many programming languages support functions, including C, Visual Basic, and Transact-SQL. Transact-SQL supplies built-in functions, which cannot be modified, and supports user-defined functions, which can be created and modified by users." (Jim Joseph, "Microsoft SQL Server 2008 Reporting Services Unleashed", 2009)

"A block of statements identified by a name that can accept one or more arguments passed to it by value and can optionally return a value. Functions can be either local (static) to the file in which they’re defined or global, in which case they can be called from functions or methods defined in other files." (Stephen G Kochan, "Programming in Objective-C" 4th Ed., 2011)

"A packaged set of code that other pieces of code can invoke and that returns a result value." (Rod Stephens, "Stephens' Visual Basic Programming 24-Hour Trainer", 2011)

"A single block of code that accomplishes a single task and can be reused." (Matt Telles, "Beginning Programming", 2014)

OOP: Aggregation (Definitions)

"A form of Unified Modeling Language (UML) association that denotes the grouping of multiple instances of one class into a composite entity." (Sharon Allen & Evan Terry, "Beginning Relational Data Modeling" 2nd Ed., 2005)

"Aggregation is the process of compiling information on an object, thereby abstracting a higher-level object." (S. Sumathi & S. Esakkirajan, "Fundamentals of Relational Database Management Systems", 2007)

"A special type of abstraction relationship that defines a higher-level entity that is an aggregate of several lower-level entities; a 'part-of' type relationship. For example, a bicycle entity would be an aggregate of wheel, handlebar, and seat entities." (Toby J Teorey, ", Database Modeling and Design" 4th Ed., 2010)

"In an object-oriented environment, a class that manages objects created from another class." (Jan L Harrington, "SQL Clearly Explained" 3rd Ed., 2010)

OOP: Interface (Definitions)

"A contract that specifies the members a class or struct can implement to receive generic services for that type." (Jesse Liberty, "Programming C#" 2nd Ed., 2002)

"In Java, an interface is similar to a class definition, except that no detailed implementation of methods is provided. A class that implements an interface must provide the code to implement the methods. You can think of an interface as defining a contract between the calling method and the class that implements the interface." (Marcus Green & Bill Brogden, "Java 2™ Programmer Exam Cram™ 2 (Exam CX-310-035)", 2003)

"A set of signatures of public operations." (Craig Larman, "Applying UML and Patterns", 2004)

"A defined set of properties, methods, and collections that form a logical grouping of behaviors and data. Classes are defined by the interfaces that they implement. An interface can be implemented by many different classes." (Jim Joseph et al, "Microsoft SQL Server 2008 Reporting Services Unleashed", 2009)

"The specification of the means by which services can be invoked and data can be manipulated across an encapsulation boundary (e.g., class)." (Bruce P Douglass, "Real-Time Agility", 2009)

"The externally visible definition of the operations permitted on an application component." (David Lyle & John G Schmidt, "Lean Integration", 2010)

"Defines a set of members that a class can provide." (Rod Stephens, "Start Here! Fundamentals of Microsoft .NET Programming", 2011)

"Defines public properties, methods, and events that a class must provide to satisfy the interface." (Rod Stephens, "Stephens' Visual Basic Programming 24-Hour Trainer", 2011)

"A defined set of properties, methods, and collections that form a logical grouping of behaviors and data." (Microsoft, "SQL Server 2012 Glossary", 2012)

"The services a piece of code promises to provide forever, in contrast to its implementation, which it should feel free to change whenever it likes." (Jon Orwant et al, "Programming Perl" 4th Ed., 2012)

"A keyword used to declare an interface." (Daniel Leuck et al, "Learning Java" 5th Ed., 2020)

OOP: Object (Definitions)

"The type all other types derive from." (Jesse Liberty, "Programming C# 2nd Ed.", 2002)

"A set of variables and associated methods. An object can be sent messages to cause one of its methods to be executed." (Stephen G Kochan, "Programming in Objective-C", 2003)

"A specific instance of a class." (Marcus Green & Bill Brogden, "Java 2™ Programmer Exam Cram™ 2 (Exam CX-310-035)", 2003)

"In the UML, an instance of a class that encapsulates state and behavior. More informally, an example of a thing." (Craig Larman, "Applying UML and Patterns", 2004)

"An instance of a class, a thing, an entity, or a concept that is represented in contiguous memory in a computer. See instance, class." (Michael Fitzgerald, "Learning Ruby", 2007)

"A unique instance of a data structure defined according to the template provided by its class. Each object has its own values for the variables belonging to its class, and can respond to the methods defined by its class." (Craig F Smith & H Peter Alesso, "Thinking on the Web: Berners-Lee, Gödel and Turing", 2008)

"A cohesive unit with a particular state, possible state transitions, and behaviors. In Scala, the keyword object is used to declare a singleton explicitly, using the same syntax as class declarations, except for the lack of constructor parameters and auxiliary parameters (because objects are instantiated by the Scala runtime, not by user code). To avoid confusion with objects, we use the term instance to refer to instances of classes and objects generically." (Dean Wampler & Alex Payne, "Programming Scala", 2009)

"A cohesive unit with a particular state, possible state transitions, and behaviors. In Java, an object is an instance of a class." (Dean Wampler, "Functional Programming for Java Developers", 2011)

"A structure consisting of data and methods together with their interactions. An object is not just data, but the encapsulation of its state (data) and behavior (methods)." (Craig S Mullins, "Database Administration", 2012)

"An instance of a class. Something that 'knows' what user-defined type (class) it is, and what it can do because of what class it is. Your program can request an object to do things, but the object gets to decide whether it wants to do them or not. Some objects are more accommodating than others." (Jon Orwant et al, "Programming Perl" 4th Ed., 2012)

"A passive entity that contains or receives information. Access to an object potentially implies access to the information that it contains. Examples of objects include records, pages, memory segments, files, directories, directory trees, and programs." (Shon Harris & Fernando Maymi, "CISSP All-in-One Exam Guide, 8th Ed", 2018)

"In object-oriented design or programming, an abstraction that consists of data and operations associated with that data." (Sybase, "Open Server Server-Library/C Reference Manual", 2019)

"In an object-oriented programming context, an object is an instance of a class or type." (Alex Thomas, "Natural Language Processing with Spark NLP", 2020)

"The fundamental structural unit of an object-oriented programming language, encapsulating a set of data and behavior that operates on that data." (Daniel Leuck et al, "Learning Java, 5th Ed.", 2020)

"An instance of a class." (Rod Stephens, "Beginning Software Engineering", 2015)

"An entity or thing that is relevant in the context of a problem" (Nell Dale & John Lewis, "Computer Science Illuminated, 6th Ed.", 2015)

OOP: Class Diagram (Definitions)

"A Unified Modeling Language (UML) design artifact that shows the object classes and associations that exist between them. This is the rough UML equivalent of a data model." (Sharon Allen & Evan Terry, "Beginning Relational Data Modeling" 2nd Ed., 2005)

"A conceptual data model; a model of the static relationships between data elements of a system (similar to an ER diagram)." (Toby J Teorey, "Database Modeling and Design" 4th Ed., 2010)

"A type of diagram that shows a system's classes, contents, attributes, and relationships, including inheritance. UML is a common format for a class diagram." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"A type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations (or methods), and the relationships among the classes." (IQBBA, "Standard glossary of terms used in Software Engineering", 2011)

"Used to represent data and their relationships in UML object modeling system notation." (Carlos Coronel et al, "Database Systems: Design, Implementation, and Management" 9th Ed., 2011)

"In UML, a diagram that describes the classes that make up the system, their properties and methods, and their relationships." (Rod Stephens, "Beginning Software Engineering", 2015)

OOP: Instance (Definitions)

"A concrete representation of a class. Instances are objects that are typically created by sending an alloc or new message to a class object." (Stephen G Kochan, "Programming in Objective-C", 2003)

"An object of a particular class is called an instance of that class." (Marcus Green & Bill Brogden, "Java 2 Programmer Exam Cram 2 (Exam CX-310-035)", 2003)

"An individual member of a class. In the UML, called an object." (Craig Larman, "Applying UML and Patterns", 2004)

"A concrete representation of a class. Instances are objects that are typically created by sending an alloc or new message to a class object." (Stephen G Kochan, "Programming in Objective-C" 4th Ed., 2011)

"A specific object that is of a class type." (Rod Stephens, "Start Here! Fundamentals of Microsoft .NET Programming", 2011)

"An instance of a class is an object of the class's type. Different instances of the same class have the same properties, methods, and events but they may have different property values." (Rod Stephens, "Stephens' Visual Basic Programming 24-Hour Trainer", 2011)

"Another term for an object created by invoking a class constructor or a value of a primitive type." (Dean Wampler, "Functional Programming for Java Developers", 2011)

"(1) An occurrence of an entity. (2) The implementation of a database server (e.g., an Oracle instance)." (Craig S Mullins, "Database Administration: The Complete Guide to DBA Practices and Procedures 2nd Ed", 2012)

"In a map pattern one invocation of an elemental function on one element of the map." (Michael McCool et al, "Structured Parallel Programming", 2012)

"Short for 'an instance of a class', meaning an object of that class." (Jon Orwant et al, "Programming Perl" 4th Ed., 2012)

"One occurrence of something that has many occurrences, such as entities or objects." (James Robertson et al, "Complete Systems Analysis: The Workbook, the Textbook, the Answers", 2013)

"An entity to which a set of operations can be applied and that has a state that stores the effects of the operations." (Sybase, "Open Server Server-Library/C Reference Manual", 2019)

"An occurrence of something, usually an object. When a class is instantiated to produce an object, we say the object is an instance of the class." (Daniel Leuck et al, "Learning Java, 5th Ed.", 2020)