안녕! 오늘 수업에서는 객체 지향 프로그래밍의 원리에 대해 이야기하겠습니다. 왜 Java가 있는 그대로 설계되었는지 궁금한 적이 있습니까? 내 말은, 클래스를 선언하고 클래스를 기반으로 객체를 생성하고, 클래스에는 메서드가 있다는 것입니다. 그런데 프로그램이 다른 것이 아닌 클래스와 객체로 구성되도록 언어가 구조화된 이유는 무엇입니까? "객체"의 개념이 발명되고 최전선에 놓인 이유는 무엇입니까? 모든 언어가 이런 방식으로 설계되었습니까? 그렇지 않다면 Java에 어떤 이점이 있습니까? 보시다시피 많은 질문이 있습니다 :) 오늘 수업에서 각각에 답해 봅시다.
객체 지향 프로그래밍(OOP)이란 무엇입니까?
물론 Java는 단지 재미를 위해 개체와 클래스로 구성되어 있지 않습니다. 그것들은 Java 제작자의 변덕이 아니며 그들의 발명품도 아닙니다. 객체를 기반으로 하는 다른 많은 언어가 있습니다. 최초의 그러한 언어는 "Simula"라고 불렸습니다. 그것은 노르웨이에서 1960년대에 다시 발명되었습니다. 또한 "클래스"와 "메서드"의 개념이 Simula에 등장했습니다. 소프트웨어 개발의 기준에 따르면 "Simula"는 고대 언어처럼 보이지만 누구나 Java와 "패밀리 유사성"을 볼 수 있습니다. 아마도 이 언어로 작성된 코드를 쉽게 읽고 그것이 무엇을 하는지 대략적으로 설명할 수 있을 것입니다 :)
Begin
Class Rectangle (Width, Height); Real Width, Height;
Begin
Real Area, Perimeter;
Procedure Update;
Begin
Area := Width * Height;
OutText("Rectangle is updating, Area = "); OutFix(Area,2,8); OutImage;
Perimeter := 2*(Width + Height);
OutText("Rectangle is updating, Perimeter = "); OutFix(Perimeter,2,8); OutImage;
End of Update;
Update;
OutText("Rectangle created: "); OutFix(Width,2,6);
OutFix(Height,2,6); OutImage;
End of Rectangle;
Rectangle Class ColouredRectangle (Color); Text Color;
Begin
OutText("ColouredRectangle created, color = "); OutText(Color);
OutImage;
End of ColouredRectangle;
Ref(Rectangle) Cr;
Cr :- New ColouredRectangle(10, 20, "Green");
End;
이 코드 샘플 코드는 Weekly-geekly의 "Simula - 50 years of OOP"에서 가져왔습니다. 보시다시피 Java는 조상과 크게 다르지 않습니다. :) 이것은 Simula의 등장으로 객체 지향 프로그래밍이라는 새로운 개념의 탄생을 알렸기 때문입니다. Wikipedia는 OOP를 다음과 같이 정의합니다. "객체 지향 프로그래밍(OOP)은 필드(종종 속성이라고도 함) 형식의 데이터와 절차(종종 방법으로 알려짐)." 제 생각에는 이것은 정말 좋은 정의입니다. Java를 배우기 시작한 지 오래되지 않았지만 이 정의에는 모르는 단어가 포함되어 있지 않을 것입니다. :) 오늘날 OOP는 가장 일반적인 프로그래밍 방법론입니다. 자바 외에도, OOP 원칙은 여러분이 들어봤을 수 있는 많은 대중적인 언어에서 사용됩니다. 예를 들어, C++(게임 개발에 적극적으로 사용됨), Objective-C 및 Swift(Apple 장치용 프로그램 작성에 사용됨), Python(기계 학습에서 가장 인기 있음), PHP(가장 인기 있는 웹 개발 언어 중 하나), JavaScript( 그것이 사용되지 않는 것을 말하는 것이 더 쉽습니다) 및 기타 많은 것들. 그렇다면 OOP의 원칙은 무엇입니까? 자세히 알려드리겠습니다. 어쨌든 OOP의 원칙은 무엇입니까? 자세히 알려드리겠습니다. 어쨌든 OOP의 원칙은 무엇입니까? 자세히 알려드리겠습니다.
OOP 원칙
이들은 재단의 기초입니다. 객체 지향 프로그래밍 패러다임을 함께 형성하는 4가지 주요 기능. 그것들을 이해하는 것은 성공적인 프로그래머가 되기 위해 필수적입니다.
원칙 1. 상속
희소식: 당신은 이미 OOP의 몇 가지 원칙을 알고 있습니다! :) 우리는 이미 수업에서 상속을 몇 번 만났고 그것을 사용할 수 있었습니다. 상속은 기존(상위) 클래스를 기반으로 새 클래스를 설명할 수 있는 메커니즘입니다. 그렇게 함으로써 새 클래스는 부모 클래스의 속성과 기능을 차용합니다. 상속이란 무엇이며 어떤 이점이 있습니까? 무엇보다 코드 재사용. 부모 클래스에서 선언된 필드와 메서드는 자손 클래스에서 사용할 수 있습니다. 모든 유형의 자동차에 10개의 공통 필드와 5개의 동일한 메서드가 있는 경우 Auto 로 이동하기만 하면 됩니다.부모 클래스. 아무 문제 없이 자손 클래스에서 사용할 수 있습니다. 견고한 장점: 양적(코드 감소) 및 결과적으로 질적(클래스가 훨씬 단순해짐). 또한 상속은 매우 유연합니다. 자손에 없는 별도의 쓰기 기능(특정 클래스에 특정한 일부 필드 또는 동작)을 추가할 수 있습니다. 일반적으로 실생활에서와 마찬가지로 우리 모두는 부모와 다소 비슷하지만 어떻게 든 다릅니다 :)
원칙 2. 추상화
이것은 매우 간단한 원리입니다. 추상화란 어떤 것의 주요하고 가장 중요한 특성을 식별하는 동시에 사소하고 중요하지 않은 것은 모두 버리는 것을 의미합니다. 바퀴를 재발명할 필요가 없습니다. 수업에 대한 오래된 수업의 예를 생각해 봅시다. 회사 직원을 위한 파일링 시스템을 만든다고 가정합니다. "직원" 개체를 만들기 위해 직원 클래스 를 작성했습니다 . 회사 파일 시스템에서 설명하는 데 중요한 특성은 무엇입니까? 이름, 생년월일, SSN 및 직원 ID. 그러나 이러한 유형의 레코드에 직원의 키, 눈 색깔 또는 머리 색깔이 필요할 가능성은 거의 없습니다. 회사는 직원에 대한 그러한 정보를 필요로 하지 않습니다. 따라서 Employee 클래스에서 다음 변수를 선언합니다., int age , int socialSecurityNumber 및 int employeeId . 그리고 우리는 눈 색깔과 같은 불필요한 정보를 추상화합니다. 그러나 모델링 에이전시를 위한 파일링 시스템을 만들고 있다면 상황이 극적으로 바뀝니다. 모델의 키, 눈 색깔, 머리 색깔은 중요한 특성이지만 그녀의 SSN은 우리와 전혀 관련이 없습니다. 따라서 Model 클래스에서 String height , String hair , String eyes 변수를 생성합니다 .
원칙 3. 캡슐화
우리는 이미 이것에 부딪쳤습니다. Java에서 캡슐화는 데이터를 읽고 변경하는 기능을 제한하는 것을 의미합니다. 보시다시피 이 용어는 "캡슐"이라는 단어를 기반으로 합니다. 우리는 "캡슐"을 사용하여 다른 사람이 변경하지 않았으면 하는 중요한 데이터를 숨길 것입니다. 다음은 실생활의 간단한 예입니다. 이름과 성이 있습니다. 모든 친구들이 그들을 알고 있습니다. 그러나 귀하의 성과 이름을 변경할 수 있는 권한은 없습니다. 이를 수행하는 프로세스는 법원 시스템에 의해 "캡슐화"되었다고 말할 수 있습니다. 귀하는 법원 서기를 통해서만 성을 변경할 수 있으며 귀하만이 이를 수행할 수 있습니다. 다른 "사용자"는 귀하의 성과 이름에 대한 "읽기 전용" 액세스 권한을 가집니다. :) 또 다른 예시는 집에 보관된 현금입니다. 방 한가운데 눈에 잘 띄는 곳에 두는 것은 좋은 생각이 아닙니다. 모든 "사용자"(귀하의 집에 오는 사람)는 귀하의 금액을 변경할 수 있습니다. 즉, 귀하의 돈을 가져갈 수 있습니다. 금고에 넣어두는 것이 좋습니다. 그러면 귀하만 액세스할 수 있으며 특수 코드를 사용해야 합니다. 이미 작업한 캡슐화의 명백한 예는 액세스 수정자(개인, 공개 등)와 세터 및 게터입니다. 캡슐화하지 않으면Cat 클래스의 나이 필드는 누구나 다음과 같이 작성할 수 있습니다.
Cat.age = -1000;
캡슐화 메커니즘을 사용하면 나이가 음수로 설정되지 않도록 할 수 있는 setter 메서드로 나이 필드를 보호할 수 있습니다.
원칙 4. 다형성
다형성은 여러 유형이 동일한 유형인 것처럼 작업할 수 있는 기능입니다. 또한 개체의 동작은 해당 유형에 따라 달라집니다. 복잡하게 들리나요? 지금 당장 이해합시다. 가장 간단한 예를 들어보자: 동물. 단일 speak() 메서드와 두 개의 하위 클래스인 Cat 및 Dog 로 Animal 클래스를 만듭니다 .
public class Animal {
public void speak() {
System.out.println("Hello!");
}
}
public class Dog extends Animal {
@Override
public void speak() {
System.out.println ("Woof-woof!");
}
}
public class Cat extends Animal {
@Override
public void speak() {
System.out.println("Meow!");
}
}
이제 우리는 Animal 참조 변수를 선언하고 여기에 Dog 개체를 할당하려고 합니다.
public class Main {
public static void main(String[] args) {
Animal dog = new Dog();
dog.speak();
}
}
어떤 메서드가 호출될 것 같나요? Animal.speak() 또는 Dog.speak() ? Dog 클래스 의 메소드 이름은 다음과 같습니다. Woof-woof! 우리는 Animal 참조 를 만들었지 만 개체는 Dog 처럼 동작합니다 . 필요한 경우 고양이, 말 또는 다른 동물처럼 행동할 수 있습니다. 중요한 것은 일반 Animal 참조 변수에 특정 하위 클래스를 할당하는 것입니다. 모든 개는 동물이기 때문에 이것은 의미가 있습니다. "객체의 동작은 유형에 따라 달라집니다."라고 말했을 때 우리가 염두에 두었던 것입니다. Cat 객체를 생성했다면 ...
public static void main(String[] args) {
Animal cat = new Cat();
cat.speak();
}
speak () 메서드는 "야옹!"을 표시합니다. 그러나 '여러 유형이 동일한 유형인 것처럼 작업할 수 있는 능력'이란 무엇을 의미합니까? 이것은 또한 매우 간단합니다. 우리가 동물을 위한 이발소를 만든다고 상상해 봅시다. 이발소는 모든 동물에게 손질을 제공할 수 있어야 하므로 Animal 매개변수(동물이 머리를 자르는 것)를 사용하여 trim() 메서드를 만듭니다.
public class AnimalBarbershop {
public void trim(Animal animal) {
System.out.println("The haircut is done!");
}
}
이제 Cat 및 Dog 개체를 trim() 메서드 에 전달할 수 있습니다 !
public static void main(String[] args) {
Cat cat = new Cat();
Dog dog = new Dog();
AnimalBarbershop barbershop = new AnimalBarbershop();
barbershop.trim(cat);
barbershop.trim(dog);
}
명확한 예는 다음과 같습니다. AnimalBarbershop 클래스는 Cat 및 Dog 유형이 동일한 유형인 것처럼 작동합니다 . 동시에 고양이 와 개는 서로 다른 행동을 합니다. 그들은 각각 다르게 말합니다.
OOP가 필요한 이유는 무엇입니까?
OOP가 새로운 프로그래밍 개념으로 등장한 이유는 무엇입니까? 프로그래머는 절차적 언어와 같은 기능 도구를 가지고 있었습니다. 근본적으로 새로운 것을 발명하게 된 동기는 무엇입니까? 무엇보다도 그들이 직면한 작업의 복잡성. 60년 전에 프로그래머의 작업이 "일부 수학적 표현 평가"와 같은 것이라면 이제는 "STALKER 게임에 대한 7개의 다른 엔딩 구현, A, B, C, DE 지점에서 내린 플레이어의 결정의 조합에 따라"와 같은 것이 될 수 있습니다. , 게임에서 F." 보시다시피 지난 수십 년 동안 작업이 분명히 더 복잡해졌습니다. 그 결과 데이터 유형이 더욱 복잡해졌습니다. 이것이 OOP가 등장한 또 다른 이유입니다. 일반 프리미티브를 사용하여 수학적 표현을 쉽게 평가할 수 있습니다. 여기에는 개체가 필요하지 않습니다. 하지만 게임 엔딩 작업은 커스텀 클래스를 사용하지 않고는 설명하기조차 어려울 것입니다. 즉, 클래스와 개체를 사용하여 설명하는 것은 매우 쉽습니다. 당연히 Game, Stalker, Ending, PlayerDecision, GameEvent 등 여러 클래스가 필요합니다. 즉, 문제 해결을 시작하지 않아도 머릿속에서 쉽게 해결책을 "스케치"할 수 있습니다. 작업의 복잡성이 증가함에 따라 프로그래머는 작업을 여러 부분으로 나누었습니다. 그러나 이것은 절차적 프로그래밍에서 그렇게 쉬운 일이 아니었습니다. 그리고 꽤 자주 프로그램은 가능한 모든 실행 경로를 나타내는 많은 가지가 있는 트리와 같았습니다. 특정 조건에 따라 프로그램의 한 분기 또는 다른 분기가 실행되었습니다. 소규모 프로그램의 경우 편리하지만 큰 문제를 여러 부분으로 나누기가 매우 어렵습니다. 이것이 OOP의 출현에 대한 또 다른 이유였습니다. 이 패러다임은 프로그래머에게 프로그램을 "모듈"(클래스)의 묶음으로 나눌 수 있는 기능을 제공했으며 각 클래스는 작업의 자체 부분을 수행합니다. 서로 상호 작용함으로써 모든 개체는 우리 프로그램의 작업을 수행합니다. 또한 프로그램의 다른 곳에서 코드를 재사용할 수 있어 많은 시간을 절약할 수 있습니다.
아마도 이 언어로 작성된 코드를 쉽게 읽고 그것이 무엇을 하는지 대략적으로 설명할 수 있을 것입니다 :)
GO TO FULL VERSION