JS는 OOP 언어입니까?

JS는 OOP와 함수형 프로그래밍 스타일을 모두 지원합니다.

Summary

_{This article does not extoll OOP to be better than Functional programming styles. It does; however, show how quickly OOP can go wrong if a single simple rule isn't followed when talking about inheritance. It also shows how OOP and Functional Styles can co-exist.}

_{It then discusses Composition; which, allows for polymorphic traits using properties.}

_{Finally, it discusses the Single Responsibility Principle, where OOP and Functional styles meet. At this layer there's no difference in the two styles because good OOP winds up at Functional styles anyway.}

JS OOP 구문은 C#, C++ 및 Java와 정확히 동일합니다.

ES6부터 Javascript OOP 구문은 C++, Java 및 C#과 완전히 동일한 구문입니다. 나는 이것이 일부 JavaScript 사용자, 특히 4년 이상의 경험을 가진 사람들을 놀라게 할 수 있다는 것을 알고 있습니다.

_{¹Javascript has no types, so the OOP syntax is the exact same pattern (minus types). For Typescript, it is the same syntax.}

_{The JavaScript pattern for inheritance is}

  class Parent extends BaseClass

The C# pattern is

  class Parent:BaseClass

자바스크립트 클래스

class Person{
  lastName;
  firstName;
}
// typescript equivalent with type checking
class Person{
  lastName:string;
  firstName:string;
}

_{Note: The exact same Behavior as above, is possible using only functions in JavaScript. In fact, after compilation of the class, it winds up as a function. The 2nd article in this series will cover that.}

Person의 두 클래스 예제에는 lastName 및 firstName 속성이 있습니다. 우리는 다음과 같이 사용합니다.

let thom = new Person();
thom.firstName = 'Thomas';
thom.lastName = 'Edison';

새로운 요구 사항
직원 클래스가 필요하며 직원에게는 ID만 있습니다. 직원은 Person이므로 상속을 사용할 수 있습니다.

기본 클래스를 상속하는 JavaScript 클래스

// works only because employee
// strictly (is-a) a person
class Employee extends Person{
 empId;
}
...

let emp = new Employee();
emp.empId = 1;
emp.firstName = 'Joseph';
emp.lastName = 'Edison';

잠깐만 emp는 이름과 성 속성을 어디서 얻었나요? 답변: Person 확장에서.

이 개념을 하위 분류라고 합니다. 서브클래싱 또는 우리가 '고전적 상속'이라고 부르는 성공의 거대한 비밀이 있습니다.

Do not ever sub-class or try to sub-class something that does not have a strict 'is-a' relationship. For example; a car has tires but a car 'is-not' a tire, or is a tire a car! The Tire class should never be a sub-class of Car.

이것은 깨질 수 없는 기본 규칙이며 아마도 많은 OOP 구현이 실패하는 원인일 것입니다.

하위 분류

적절한 하위 분류는 하위 클래스가 상위 클래스의 무엇인가 'is-a'라는 것을 의미합니다. 직원 'is-a' 사람입니다. 따라서 Employee 클래스가 Person 클래스를 확장하는 것은 괜찮습니다. 하위 분류는 객체 그래프에서 볼 때 본질적으로 항상 수직입니다.

구성
하위 분류와 달리 고유한 고유한 자바스크립트 유형과 우리 고유의 복잡한 유형에 대한 또 다른 방법이 있습니다. 구성은 '가지고-있는' 관계입니다. 자동차에는 타이어가 있고 자동차에는 엔진이 있습니다. 속성 또는 매개변수는 구성을 수행합니다.

// with no constructor, 
// this is a model
class Car{
 // properties are compositional
 // they are has-a relationships
 tires;
 engine;
}
// with a constructor taking parms.
class Car{
 constructor(tires,engine){

   // this.engine and this.tires
   // are implicitly defined in ES6

   this.engine = engine;
   this.tires = tires;

   // in traditional OOP 
   // this is the same syntax
   // to implement data-hiding
 }
}

// compose the car like this
let ford = new Car("GoodYear MX100", "EcoBoost 8");
// or compose like this:
let ford = new Car();
ford.tires = "GoodYear MX100";
ford.engine = "EcoBoost 8";

// It's safe to say that class or function
// properties are compositional

자동차에는 타이어가 있고 자동차에는 엔진이 있습니다. 자동차는 속성으로 구성됩니다. 클래스나 함수의 모든 속성은 합성입니다. 그것은 그 속성을 가지고 있습니다.

우리는 이제 '고전적 상속'이 본질적으로 수직적이라는 것을 이해합니다. 여기서 하위 클래스는 부모의 속성과 기능을 확장합니다.

구성은 '가로' 관계의 객체 그래프를 보여줍니다. 이것을 '수평 상속'이라고 부를 수 있습니다. 객체는 (속성에서와 같이) 포함하거나 사용할 매개변수를 허용하거나 포함할 수 있습니다.

다음에 "상속보다 구성 선호"라는 말을 들을 때는 단순히 'has-a' 구현을 선호한다는 의미입니다. 단순 또는 복합 유형의 속성 및 매개변수가 이를 달성합니다.

그것이 의미하는 바는 하위 분류가 어떤 식으로든 피해야 한다는 것입니다. 하위 클래스가 진정으로 상위 클래스의 일부일 때 제대로 작동합니다.

단일 책임

구성 및 상속 모두 단일 책임 원칙을 엄격히 준수해야 합니다. 우리가 작성하는 모든 클래스나 함수는 한 가지만 수행해야 합니다. 예를 들어, 타이어 클래스 또는 타이어 함수는 fillTire 작업을 구현하지 않아야 합니다. 타이어는 타이어를 채우지 않지만 fillTire 함수는 채워집니다. fillTire는 타이어를 구성 요소(속성)로 사용하여 작동합니다.

_{This is slightly different than C#, Java or C++ where a fillTire interface may be in the tire class. This is due to the fact that functions (methods) must exist within the class.}

_{The reason we don't do this in JS is because functions are first class citizens. They are equal to a class in the javascript hierarchy. Functions do not need to be contained in a class.}

_{In Javascript, the fillTire function would be contained in the Tire.js module.}

OOP와 기능적 스타일의 만남

여기에서 함수형 프로그래밍과 OOP가 만나는 단일 책임 원칙(SRP)입니다.

하지만, 하지만, 하지만
클래스는 생성된 런타임 함수에 대한 구문 설탕일 뿐입니다. 사실이지만 런타임 컴파일러가 어떻게 작동하는지 누가 신경 쓰겠습니까? "우리는 기능적인 프로그래머일 뿐이고 OOP는 전혀 필요하지 않았기 때문에"OOP 개념을 무시하는 것은 다소 순진하고 구식입니다.

Don't get me wrong, the function is larger in life than the C#, Java or C++ method syntax, due to it's true first-class citizenship. If done right the function is the most powerful construct in JavaScript.

클래스 구성을 사용하는 것은 제대로 수행될 때 실행 가능한 솔루션입니다. 하위 분류는 괜찮지만 진정한 'is-a' 관계에서만 가능합니다. 구성은 'has-a' 관계를 위한 것이고 기능은 주요 초점으로서 단일 책임 작업을 위한 것입니다. 함수는 여러 함수를 포함할 수 있지만 SRP 함수를 먼저 만든 후에만 가능합니다.

C++의 OOP 아키텍처는 JavaScript의 발명보다 11년 더 오래되었습니다. 25년 동안 많은 것을 배웠습니다. 위의 개념을 완전히 이해한 경우에만 JavaScript에 적용할 수 있습니다.