Object Oriented Concepts

Front 1

Class

Back 1

A class is a master copy of the object that is consulted to determine which attributes and behavior an object should have. As an example, any Java program that uses strings is using objects created from the String class. This class contains attributes that determine what a String object is and behavior that controls what the String object can do.

Front 2

Interface

Back 2

The purpose of an interface is to define behavior while ignoring the specifics. The interface implementation is a particular means of the defined behavior with specific implementation details of its own. Interface documentation “should discuss the intended use of the interface and its implementation from a black-box point of view”. That way your implementations don't need to rehash that documentation, but can focus on describing the implementation specific details of how they accomplishing what the interface specified.
An interface should describe the "what", while the implementation should describe the "how".

Front 3

Object-oriented

Back 3

What is it to be object-oriented? (A Wikipedia excerpt) A programming paradigm that represents the concept of objects that have attributes (fields or data types), and associated behaviors (procedures or methods). These objects can be static (single unchanging) or have separate instances used to interact and design complex applications. The OO approach to designing software is in its modularity and flexibility, and thus enabling reusability. The OO ideology can be further extended by including the additions of other OO concepts like polymorphism and inheritance.

Front 4

Abstraction

Back 4

The process by which data and programs are defined with a representation similar in form to its meaning, while hiding away the implementation details…coding to an interface, in which case you abstract common properties of multiple classes.

Front 5

Aggregation

Back 5

Differs from ordinary composition in that it does not imply ownership. In composition, when the owning object is destroyed, so are the contained objects. In aggregation, this is not necessarily true. A university has various departments which have numerous professors. When a university closes the departments of that university cease to exist, but the professors continue to exist. Therefore, the objects together form one complex object as opposed to associations; the professors are part of the departments which are part of the university. If one is destroyed it does not destroy the other objects contained within it.

Front 6

Aspect-Oriented-Programming (AOP)

Back 6

Is the aims at increasing modularity through the concept of aspects and allowing cross-cutting concerns. An example of this is logging, caching, and exception, handling, where the aspects do not actually pertain to the given class and by doing so breaks the idea of encapsulation, but they do it in a controlled way. Aspects have access to the private members of a class, but it doesn’t compromise encapsulation by opening up those members between objects or different classes.

Front 7

Association

Back 7

Defines a relationship between classes of objects that allows one object instance to cause another to perform an action on its behalf. This relationship is structural, because it specifies that objects of one kind are connected to objects of another and does not represent behavior.
An example would be a TV and VCR. Neither requires the other to function, but if you want to play a tape, the VCR must be associated to the TV, however, destroying one does not affect the other. This can also be thought of as the objects being independent of each other but requiring the services of the other.

Front 8

Cohesion

Back 8

refers to the degree to which the elements of a module belong together; how strongly related or focused the responsibilities of a single module are. It is a measure of how strongly related each piece of functionality expressed by the module is. The functionalities embedded in a class, accessed through its methods, have much in common.
Do not mistake this for composition – they are not the same. High cohesion often correlates with loose coupling, and vice versa.
A cohesive class does one thing really well and does not try to do or be something else. Cohesion measures the degree of connectivity among elements of a single module, class, or object. The higher the cohesion of your software is, the more well-defined and related the responsibilities of each individual class in your application. Each class has a very specific set of closely related actions it performs.

Front 9

Composition

Back 9

Combining simple objects into more complex ones. An example would be an automobile. An automobile is a complex object consisting of many smaller objects which may in turn consists of even smaller objects. Composition is usually implemented such a that an object contains another object (this differs from inheritance, where by inheritance, the “is a” relationship exists.).
In OO design, this relationship is referred to by a “has a” relationship. i.e. a Object-A “has a” object of type Object-B. Types of composition are Aggregation and Association.

Front 10

Concurrency

Back 10

A property of systems in which several computations are executing simultaneously.

Front 11

Coupling (tight and loose)

Back 11

(see also Orthogonality) Coupling (or dependency) is considered to be the degree to which each program module relies on other modules (dependencies), and is also the term used to describe connecting two or more systems. Coupling is broken down into loose coupling, tight coupling, and decoupled. A module is said to be loosely coupled if it relies primarily on its self with few or no dependencies to complete its tasks. Loose Coupling is a sign of a well-structured design.

Front 12

Covariant and Invariant

Back 12

Arrays differ from generic types in two important ways. First, arrays are covariant. This scary-sounding word means simply that if Sub is a subtype of Super, then the array type Sub[] is a subtype of Super[]. Generics, by contrast, are invariant which means, for any two distinct types Type1 and Type2, List is neither a subtype nor a supertype of List.

Front 13

Cross-cutting concerns

Back 13

Are defined as aspects of a program that affect other concerns. In a sense, a ccc extends the boundaries of its concern in order to provide the same functionality to another piece of the program (another concern), thus the terminology cross-cutting.

Front 14

Defensive Copy

Back 14

The concern of protecting mutable objects whose state can be modified by the user. Defensive copying protects the objects state by always returning a new object copy of the original in order to defend against multiple references of the single object within an application.

Front 15

Delegation

Back 15

means that one object "delegates" the task to another object. This makes your code more reusable. It also lets each object worry about its own functionality, rather than spreading the code that handles your objects behavior all over the system.

Front 16

Dependency Injection (DI)

Back 16

A pattern that allows the removal of hard-coded dependencies and makes it possible to change them, at run-time or compile-time. The benefit of DI is loose coupling. Also, the technology that Spring is most identified with is the Dependency Injection (DI) flavor of Inversion of Control.
Can also be defined as a process whereby objects define their dependencies, that is, the other objects they work with, only through constructor arguments, arguments to a factory method, or properties that are set on the object instance after it is constructed or returned from a factory method. The container then injects those dependencies when it creates the bean. This process is fundamentally the inverse, hence the name Inversion of Control (IoC), of the bean itself controlling the instantiation or location of its dependencies on its own by using direct construction of classes, or the Service Locator pattern.

Front 17

Inversion of Control (IoC)

Back 17

Inversion of Control is a general concept, and it can be expressed in many different flavors. Dependency Injection is merely one concrete example of Inversion of Control. When writing a complex Java application, application classes should be as independent as possible of other classes to increase the possibility to reuse these classes and to test them independently of other classes while doing unit testing. Dependency Injection helps in gluing these classes together and at the same time keeping them independent. What is dependency injection exactly? Let's look at these two words separately. Here the dependency part translates into an association between two classes. For example, class A is dependent on class B. Now, let's look at the second part, injection. All this means is that class B will get injected into class A by the IoC. Dependency injection can happen in the way of passing parameters to the constructor or by post-construction using setter methods.

Front 18

Eager Initialization

Back 18

(see also lazy initialization) Differs from lazy instantiation in that the object is instantiated upon application startup.

Front 19

Encapsulation

Back 19

(Simple description) Is a form of information hiding. Means the internal representation of an object is hidden from the view outside the objects definition. It is also a way to break up objects into their logical parts and keeping those parts separate; avoiding duplication of code. Such as keeping generic behaviors separate from specific behaviors of an object.
(The power of encapsulation) By breaking up the different parts of your application, you can change one part without having to change all the other parts. Encapsulation helps protect your classes form unnecessary changes. Always try to encapsulate what varies. Ex. Think of the painter, his cleanBrush() and setEasel() never change, but his paint() style does. You instead could change paint() to paintStyle() and move paint() to a paintStyle() class.

Front 20

Encapsulation

Back 20

(Complex Description) Encapsulation is used to hide the values or state of a structured data object inside a class, preventing unauthorized parties direct access to them (also known as information hiding). Publicly accessible methods are generally provided in the class (so-called getters and setters) to access the values, and other client classes call these methods to retrieve and modify the values within the object.
Encapsulation means that the internal representation of an object is generally hidden from view outside of the object's definition. Typically, only the object's own methods can directly inspect or manipulate its fields. Hiding the internals of the object protects its integrity by preventing users from setting the internal data of the component into an invalid or inconsistent state. A benefit of encapsulation is that it can reduce system complexity, and thus increases robustness, by allowing the developer to limit the interdependencies between software components.
Encapsulation lets you create code that is easier to read and maintain by allowing to group related variables and methods together in classes. By use of access modifiers, they allow implementation details to be hidden within a class.

Front 21

Idempotent

Back 21

In short, an idempotent operation is one that will return the same results no matter the number of times the operation is called. This considers the state of the object does not change by some side function.

Front 22

Inheritance

Back 22

is the way one object can inherit behavior and attributes from other objects that are similar to it; is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.
The inheritance relationship can be thought as, Object Sun “is a” type of object Star.

Front 23

Interface

Back 23

The purpose of an interface is to define behavior while ignoring the specifics. The interface implementation is a particular means of the defined behavior with specific implementation details of its own. Interface documentation should discuss the intended use of the interface and its implementation from a black-box point of view. That way your implementations don't need to rehash that documentation, but can focus on the describing the implementation specific details of how they accomplishing what the interface specified.
The interface should describe the "what", while the implementation should describe the "how".

Front 24

Coding to an Interface

Back 24

At the basic level, coding to an interface means abstracting behaviors similar to multiple objects, to an interface. In this way, a class can implement that interface and attain all the necessary behaviors required for a specific action. This technique is employed for better encapsulation, polymorphism, unit testing and many other various reasons.

Front 25

Immutability

Back 25

Objects whose state cannot change after construction. Examples from the JDK include the String and Integer objects. In “Effective Java”, Joshua Bloch makes a compelling recommendation, “Classes should be immutable unless there’s a very good reason to make them mutable... If a class cannot be made immutable, limit its mutability as much as possible.”.

Front 26

Latency

Back 26

The time required to locate the first bit or character in a repository. Generally this is used to discuss website performance where latency refers to the amount of time it takes the server to respond to a user request; page, data, resource etc.

Front 27

Lazy Initialization or lazy-loading

Back 27

is the tactic of delaying the creation of an object or process until the first time it is needed. This can greatly improve application performance by only loading those resources that are necessary upon application startup and lazy-load others as needed or accessed.

Front 28

Marshaling

Back 28

The process of gathering data and transforming it into a standard format before it is transmitted over a network so that the data can transcend network boundaries. In order for an object to be moved around a network, it must be converted into a data stream that corresponds with the packet structure of the network transfer protocol. This conversion is known as data marshalling. Data pieces are collected in a message buffer before they are marshaled. When the data is transmitted, the receiving computer converts the marshaled data back into an object.
Data marshalling is required when passing the output parameters of a program written in one language as input to a program written in another language. This term is almost exclusively used in the context of serializing and object to XML

Front 29

Orthogonality

Back 29

(also see coupling) is the relation of two lines meeting at a right angle. The idea in regards to computer programming is that changes to one line will not affect the other; the lines remain independent of one another. If a line on the x-axis continues to move along the x-axis, no matter the distance does not affect its relation to the line on the y-axis and vice versa.

Front 30

Persistence

Back 30

refers to the state of an object to outlive the process that created it. This is achieved by storing the state of the object as data in a non-volatile storage such as flash memory.

Front 31

Polymorphism

Back 31

the ability to use an object as if it were an object of its superclass, while still using its overriding methods. Polymorphism allows you to use an object of a subclass as if it were an object of its superclass, while still using the overriding method of the subclass.

Front 32

Reified and Non-reified

Back 32

Arrays are reified; they know and enforce their element types at runtime. Generics in contrast enforce their type constraints only at compile time and discard (or erase; Erasure) their element type information at runtime. Non-reifiable type is one whose runtime representation contains less information than its compile-time representation.

Front 33

Singleton

Back 33

A design pattern which restricts object instantiation of a class to one object. Useful when exactly one and only one object is needed to coordinate actions across an application.

Front 34

Stateful and Stateless

Back 34

Stateless comes from the mathematical notion of a function, which when called with the same arguments, always return the same results. Stateful refers to maintaining the state of, or the ability to change the given state of the Object, in which case, calling a function with an object may change the state of that object. This concept is often used in regards to maintaining a web session (http is inherently stateless), where an id must be passed along with the request so that the server continues to modify and return the state of the object for that session; this form of http protocol is also one-directional or one-way communication as opposed to an open connection with two-way or bi-directional communication.

Front 35

Synchronous vs Asynchronous

Back 35

By definition, synchronous means “occurring at the same time”, whereas asynchronous means, “having each operation occur only after the preceding operation has completed”. Java is a synchronous language whereas javascript is asynchronous.

Front 36

Utility & Helper

Back 36

A design pattern where no instantiation of the class is required but instead only static methods are used. This creates a stateless design which should host a group of related methods that could be attributable to many classes. However, caution should be taken when creating a utility or helper in that, generally, methods we believe are abstract enough to relate to many may actually be more specific to a convention or small group of related objects.

Front 37

Erasure, Type:

Back 37

Typeerasure refers to the compile-timeprocess by which explicit type annotations are removed from a program, beforeit is executed at run-time. This can be exemplified with generics, for example,
List newList = newArrayList(); // At compile-time.

List newList = new List(); // Atruntime.Generics type information is checked at compile time, but is removed atruntime, and thus the above code would be changed at runtime.

Front 38

Inference, Type

Back 38

isa Java compiler's ability to look at each method invocation and correspondingdeclaration to determine the type argument (or arguments) that make theinvocation applicable. The inference algorithm determines the types of thearguments and, if available, the type that the result is being assigned, orreturned. Finally, the inference algorithm tries to find the most specifictype that works with all the arguments. Exampleusing generics,

public classFoo {

T getFoo(T foo){}// unbounded

ObjectgetFoo(Object foo) {} // infers type Object during compilation

public classFoo {

T getFoo(T foo){}// unbounded

ComparablegetFoo(Comparable foo) {} // infers type Comparable during compilation