Object-Oriented (객체 지향)

A programming paradigm based on objects instead of procedures. It is recognized as a method to effectively dissasemble and construct large and complicated systems and easily and efficiently handle them.

Object-oriented software fulfill the following standards:

• Three principles of OOP: Supports encapsulation (캡슐화), polymorphism (다형성), and class inheritance (클래스 상속)
• Allows data hiding (데이터 접근 제한)
  If the software does not fulfill the above, it is a procedural (절차지향) software.

1. Encapsulation (캡슐화)

Hides the internal details of an object.

Its purpose to is to hide data and create an object that can be easily changed. This allows to easily change the program design.

Javascript pretends to hide a member variable in a class with _. However, TypeScript can set private member variables that cannot be directly called.

2. Inheritance (상속)

Inheritance refers to a class inheriting the characteristics (functions, variables and data) of another class. A child class can inherit the characteristics of a parent class to avoid writing the same code and allow reusability.

This allows to easily understand the systematic structure through inheritance relationships and maintain consistency.

3. Polymorphism (다형성)

This refers to when a object (class) performs calculations, each class can be restructured into another form due to its instrinsic properties. As such, polymorphism is using the same method name but being materializes differently by class.

A service's functions can be flexibly changed and expanded by separating the role (역할, interface) and and implementation using polymorphism to override.
Java's overloading (오버로딩) and overriding (오버라이딩) are examples of this.

Abstraction (추상화)

Refers to newly declaring common parts of objects. This removes unnecessary details and modelizes?(모델화) common and important characteristics of objects.

This allows the user to avoid bothering about the complicated internal structure and use the external interface to write code.

When a class is designed, is is modeled by 1) abstracting common procedures, 2) creating an abstract class, then 3) creating an interface to later allow the class to polymorphize. The interface refers to only defining methods and properties

Dependency (의존성)

Refers to the degree of depencency when a object (module or class) depends on another object while collaborating. This also means that when a object is changed, the object it depends on will also change.

Coupling (결합도)

Refers to the degree of dependency of how much the object depends on another module.

A high dependency between objects is high in coupling. A high coupling of objects are more likely to change together, making it difficult to make changes.
An acceptable dependency between objects is low/loose in coupling.

Cohesion (응집도)

Refers to the degree of relationship of internal elements in a module.

An object that only performs a related operation and delegate unrelated operations to another object has high cohesion.
If one method uses more vairables, that method and class has high cohesion.

Coupling can be lowered and cohesion can be increased by creating an autonomous object that processes its own data.

The object must be responsible for its own data to increase its cohesion.

Object Oriented Programming (OOP, 객체 지향 프로그래밍)

Programing Paradigm (프로그래밍 패러다임)

The progrmaming paradigm refers what not to do instead of what to do.

The 3 most popular paradigms are:
1. Structured Programming (구조적 프로그래밍)
Directly proposes rules on the control flow (제어 흐름)

• Developed based around functionality
• The first paradigm used when programming technology was born
• Examples: Fortran, ALGOL, BASIC

2. Object-Oriented Programming (OOP, 객체 지향 프로그래밍)
Indirectly proposes rules on the control flow

• Programming paradigm where the processing unit is an object
• OOP is the top programming paradigm that "models the real world"
• Examples: Java, JavaScript, C++, Python, MATLAB

Pros of OOP:

• OOP provides various ways to effectively control dependencies to flexibly respond to requirements
• Programming based on data instead of functions can help maintain consistency
• Easier to understand as we expect that an object's problem will be processed by itself and can control the object's internal elements to not be affected externally, allowing us to easily make changes
• Data and processes are usually combined into one

OOP designing:

• A good design is where the required function is performed in its entirety and can accomodate future changes
• A code that can be changed is a code that is easily understood
• A design that can be easily changed is where only one class need be changed
• An excellent OOP design is to use encapsulation to adequately manage dependencies to lower the coupling

3. Functional Programming (함수형 프로그래밍)
Proposes rules on assignments

• Developed based around functions
• Was the first paradigm made among these top 3 paradigms but is now recently starting to be used
• Examples: C++, Python, Ruby, JavaScript

5 Principles of OOP (SOLID)

https://devopedia.org/solid-design-principles

1. Single Responsibility Principle (SRP, 단일 책임의 원칙)

One object must have one responsibility. Therefore there should only be one rason to change a class or module. This defines the adequate size of a class.

2. Open-Closed Principle (OCP, 개방-폐쇄 원칙)

A sofware entity or an object (class, module, function, etc.) are open to expansion but must be closed to changes.

If you are required to make a small expansion but will have to make great edits to do so, it will result in high development costs.

3. Liskov Substitution Principle (LSP, 리스코프 치환 원칙)

An object in a program must maintain the program's accurately and can be changed to a lower (child) type instance.

4. Interface Segregation Principle (ISP, 인터페이스 분리 원칙)

Several interfaces for a certain client is better than one general interface.

The functions unnecessary for the client should not rely on the interface and the interface must be maintained as small as possible, e.g. maintain the interface as small as possible and don't let it depend on unnecessary functions.

5. Dependency Inversion Principle (DIP, 의존성 역정 원칙)

The programmer should depend on abstraction, not actualization. The modules on the highest level (domain) should not rely on the lower level modules (substructures)