OOP 원칙

안녕하세요! Java가 왜 그렇게 설계되었는지 궁금한 적이 있습니까? 클래스를 기반으로 클래스를 생성한다는 의미에서 객체, 클래스에는 메서드 등이 있습니다. 그런데 왜 프로그램이 다른 것이 아닌 클래스와 객체로 구성되도록 언어 구조가 형성되어 있습니까? 왜 '객체'라는 개념이 창안되어 전면에 등장하게 되었는가? 모든 언어가 이런 방식으로 작동합니까? 그렇지 않은 경우 Java에 어떤 이점을 제공합니까? 보시다시피, 질문이 많아요 :) 오늘 강의에서는 각각의 질문에 답해 보도록 하겠습니다.

OOP 원칙:

1. 계승
2. 추출
3. 캡슐화
4. 다형성

객체 지향 프로그래밍(OOP)이란 무엇입니까?

물론 Java가 객체와 클래스로 구성되는 데에는 이유가 있습니다. 이것은 제작자의 변덕도 아니고 심지어 그들의 발명품도 아닙니다. 객체를 기반으로 하는 다른 언어도 많이 있습니다. 이러한 최초의 언어는 Simula라고 불리며 1960년대 노르웨이에서 발명되었습니다. 무엇보다도 Simula는 " 클래스 "와 " 메서드 "라는 개념을 도입했습니다. Kristen Nygaard와 Ole Johan Dahl - 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;

코드 예제는 Simula - OOP 50년 기사에서 가져온 것입니다 . 보시다시피 Java와 그 조상은 서로 크게 다르지 않습니다. :) 이는 Simula의 등장으로 객체 지향 프로그래밍이라는 새로운 개념의 탄생을 알렸기 때문입니다. Wikipedia에서는 OOP에 대해 다음과 같이 정의합니다. 객체 지향 프로그래밍(OOP) 은 프로그램을 객체 모음으로 나타내는 프로그래밍 방법론입니다. 각 객체는 특정 클래스의 인스턴스이고 클래스는 상속 계층 구조를 형성합니다. 제 생각에는 매우 성공적이라고 생각합니다. 최근에 Java를 배우기 시작하셨는데, 그 내용에는 생소한 단어가 거의 없습니다. :) 오늘날 OOP는 가장 일반적인 프로그래밍 방법론입니다. Java 외에도 OOP 원칙은 여러분이 들어봤을 많은 인기 언어에서 사용됩니다. 여기에는 C++(컴퓨터 게임 개발자가 적극적으로 사용함), Objective-C 및 Swift(Apple 장치용 프로그램 작성), Python(머신러닝에서 가장 수요가 많음), PHP(가장 인기 있는 웹 개발 언어 중 하나), JavaScript(무엇을 하지 않는지 간단히 말해) 및 기타 여러 가지. 실제로 OOP의 "원칙"은 무엇입니까? 좀 더 자세히 말씀드리겠습니다.

OOP 원칙

이것이 기본입니다. 객체 지향 프로그래밍 패러다임을 함께 구성하는 4가지 주요 기능입니다. 이를 이해하는 것이 성공적인 프로그래머가 되는 열쇠입니다.

원칙 1. 상속

좋은 소식은 여러분이 이미 OOP의 일부 원칙에 익숙하다는 것입니다! :) 우리는 이미 강의에서 상속에 대해 몇 번 접했고, 이에 대해 작업해 볼 시간도 가졌습니다. 상속은 기존(부모) 클래스를 기반으로 새 클래스를 설명할 수 있는 메커니즘입니다. 이 경우 상위 클래스의 속성과 기능은 새 클래스에서 빌려옵니다. 상속이 필요한 이유는 무엇이며 어떤 이점을 제공합니까? 우선, 코드 재사용입니다. 상위 클래스에 설명된 필드와 메서드는 하위 클래스에서도 사용할 수 있습니다. 모든 유형의 자동차에 10개의 공통 필드와 5개의 동일한 메소드가 있는 경우 이를 상위 클래스에 넣기만 하면 됩니다 Auto. 자손 클래스에서도 문제 없이 사용할 수 있습니다. 확실한 장점: 양적으로(코드가 적음), 결과적으로 질적으로(클래스가 훨씬 단순해짐). 동시에 상속 메커니즘은 매우 유연하므로 자손에 누락된 기능을 별도로 추가할 수 있습니다(특정 클래스에 특정한 일부 필드 또는 동작). 일반적으로 평범한 삶에서와 마찬가지로 우리는 모두 어떤 면에서는 부모와 비슷하지만 어떤 면에서는 다릅니다 :)

원칙 2. 추상화

이것은 매우 간단한 원리입니다. 추상화는 객체의 주요하고 가장 중요한 특성을 강조하는 것을 의미하며 그 반대의 경우도 마찬가지입니다. 즉, 이차적이고 중요하지 않은 특성을 폐기하는 것입니다. 바퀴를 재발명하지 말고 수업에 관한 오래된 강의의 예를 기억하지 맙시다. 회사 직원의 파일 캐비닛을 만들고 있다고 가정해 보겠습니다. 직원 객체를 생성하기 위해 클래스를 작성했습니다 Employee. 회사 파일에 설명하는 데 중요한 특성은 무엇입니까? 이름, 생년월일, 사회보장번호, 세금 식별 번호. 그러나 이 유형의 카드에는 키, 눈, 머리 색깔이 필요하지 않습니다. 회사에서는 직원에 대한 이러한 정보가 필요하지 않습니다. 따라서 클래스에 대해서는 변수 , , , Employee를 설정 하고 눈 색깔 등 우리에게 불필요한 정보를 버리고 추상화하겠습니다. 하지만 에이전시를 위한 사진 모델 카탈로그를 만들면 상황이 극적으로 변합니다. 패션 모델을 설명하려면 키, 눈 색깔, 머리 색깔이 매우 중요하지만 TIN 번호는 필요하지 않습니다. 따라서 클래스에서는 변수 , , 을 만듭니다 . String nameint ageint socialInsuranceNumberint taxNumberModelString heightString hairString eyes

원칙 3: 캡슐화

우리는 이미 그것을 경험했습니다. Java의 캡슐화는 데이터에 대한 액세스와 데이터 변경 기능을 제한하는 것을 의미합니다. 보시다시피 "캡슐"이라는 단어를 기반으로합니다. 이 "캡슐"에는 누구도 변경하지 못하도록 하는 몇 가지 중요한 데이터가 숨겨져 있습니다. 인생의 간단한 예. 당신은 이름과 성을 가지고 있습니다. 당신이 아는 모든 사람들은 그것을 알고 있습니다. 하지만 귀하의 성과 이름을 변경할 수 있는 권한은 없습니다. 이 과정은 여권 사무소에서 "캡슐화"되어 있다고 말할 수 있습니다. 여기서는 성과 이름만 변경할 수 있으며 오직 본인만이 변경할 수 있습니다. 다른 "사용자"는 귀하의 성과 이름에 대해 읽기 전용 액세스 권한을 가집니다. :) 또 다른 예는 귀하의 아파트에 있는 돈입니다. 방 중앙에 잘 보이는 곳에 두는 것은 좋은 생각이 아닙니다. 모든 "사용자"(귀하의 집에 오는 사람)는 귀하의 돈 수를 변경할 수 있습니다. 그들을 데리러. 금고에 넣어두는 것이 좋습니다. 귀하만이 특수 코드를 통해서만 접근할 수 있습니다. 이미 작업한 캡슐화의 명백한 예는 액세스 수정자( private등 public) 및 getter-setter입니다. age클래스 필드가 Cat캡슐화되지 않은 경우 누구나 다음을 작성할 수 있습니다.

Cat.age = -1000;

그리고 캡슐화 메커니즘을 사용하면 age나이가 음수가 될 수 없는지 확인할 수 있는 setter 메서드를 사용하여 필드를 보호할 수 있습니다.

원칙 4. 다형성

다형성은 여러 유형을 동일한 유형인 것처럼 처리하는 능력입니다. 이 경우 객체의 동작은 해당 객체가 속한 유형에 따라 달라집니다. 좀 복잡해 보이죠? 이제 알아 봅시다. 가장 간단한 예인 동물을 살펴 보겠습니다. Animal단일 메소드( ) voice()와 그 하위 항목 두 개( Cat및 ) 를 사용하여 클래스를 만들어 보겠습니다 Dog.

public class Animal {

   public void voice() {

       System.out.println("Voice!");
   }
}

public class Dog extends Animal {


   @Override
   public void voice() {
       System.out.println("Bow-wow!");
   }
}

public class Cat extends Animal {

   @Override
   public void voice() {
       System.out.println("Meow!");
   }
}

Animal이제 링크를 생성 하고 이를 객체에 할당해 보겠습니다 Dog.

public class Main {

   public static void main(String[] args) {

       Animal dog = new Dog();
       dog.voice();
   }
}

어떤 메소드가 호출될 것이라고 생각하시나요? Animal.voice()또는 Dog.voice()? 클래스 메소드는 다음과 같이 호출됩니다 Dog: Woof-woof! 참조를 생성했지만 Animal객체는 처럼 동작합니다 Dog. 필요한 경우 고양이, 말 또는 다른 동물처럼 행동할 수 있습니다. 가장 중요한 것은 Animal특정 하위 클래스의 객체에 일반 유형의 참조를 할당하는 것입니다. 모든 개는 동물이기 때문에 이것은 논리적입니다. 이것이 바로 "객체가 어떤 유형인지에 따라 다르게 동작한다"고 말한 의미입니다. 객체를 생성한다면 Cat-

public static void main(String[] args) {

   Animal cat = new Cat();
   cat.voice();
}

메서드는 voice()"Meow!"를 출력합니다. "여러 유형을 동일한 유형인 것처럼 작업할 수 있는 기능"은 무엇을 의미합니까? 이것도 꽤 쉽습니다. 우리가 동물을 위한 미용실을 만든다고 상상해 봅시다. 우리 미용실에서는 모든 동물을 자를 수 있어야 하므로 shear()매개변수 Animal(우리가 자를 동물)를 사용하여 방법(“자르기”)을 만들겠습니다.

public class AnimalBarbershop {

   public void shear(Animal animal) {

       System.out.println("The haircut is ready!");
   }
}

이제 shear객체 Cat와 객체를 모두 메서드에 전달할 수 있습니다 Dog!

public static void main(String[] args) {

   Cat cat = new Cat();
   Dog dog = new Dog();

   AnimalBarbershop barbershop = new AnimalBarbershop();

   barbershop.shear(cat);
   barbershop.shear(dog);
}

여기에 명확한 예가 있습니다. 클래스는 마치 동일한 유형인 것처럼 AnimalBarbershop유형을 사용하여 작동합니다 . 동시에 그들은 다른 행동을 취합니다. 그들은 목소리를 다르게 사용합니다. CatDogCatDog

OOP 출현 이유

왜 이 새로운 프로그래밍 개념인 OOP 가 등장했을까요 ? 프로그래머에게는 작동하는 도구가 있었습니다. 예를 들어 절차적 언어가 있습니다. 근본적으로 새로운 것을 발명하게 된 이유는 무엇입니까? 우선, 그들이 직면한 작업의 복잡성입니다. 60년 전에는 프로그래머의 작업이 "이런 수학 방정식을 계산하는 것"처럼 보였다면 이제는 "사용자가 게임 순간 A, B, C, D에서 내린 결정에 따라 STALKER 게임에 7개의 서로 다른 엔딩을 구현하는 것"처럼 들릴 수 있습니다. , E, F 및 이러한 솔루션의 조합입니다." 보시다시피 작업은 지난 수십 년 동안 확실히 더욱 복잡해졌습니다. 이는 데이터 유형이 더욱 복잡해졌음을 의미합니다. 이것이 OOP 출현의 또 다른 이유입니다. 방정식이 포함된 예는 일반 기본 요소를 사용하여 쉽게 풀 수 있으며 여기에는 개체가 필요하지 않습니다. 하지만 당신이 개발한 몇몇 클래스를 사용하지 않고는 게임 엔딩의 문제점을 설명하는 것조차 어려울 것입니다. 그러나 동시에 이를 클래스와 객체로 설명하는 것은 매우 쉽습니다. Game 클래스, Stalker 클래스, Ending 클래스, Player's Decision 클래스, Game Moment 클래스 등이 분명히 필요합니다. 즉, 문제 해결을 시작하지 않고도 문제 해결의 "스케치"를 머릿속에서 쉽게 상상할 수 있습니다. 문제의 복잡성이 증가함에 따라 프로그래머는 문제를 여러 부분으로 나누어야 했습니다. 하지만 절차적 프로그래밍에서는 이것이 쉽지 않았습니다. 그리고 종종 프로그램은 작동에 대해 가능한 모든 옵션을 갖춘 여러 가지로 구성된 "트리"였습니다. 특정 조건에 따라 프로그램은 한 분기 또는 다른 분기를 따라 실행되었습니다. 작은 프로그램의 경우 이 옵션은 편리했지만 큰 작업을 여러 부분으로 나누는 것은 매우 어려웠습니다. 이러한 필요성은 OOP 출현의 또 다른 이유가 되었습니다. 이 개념은 프로그래머에게 프로그램을 클래스의 "모듈" 묶음으로 나눌 수 있는 능력을 제공했으며, 각 클래스는 자신의 작업 부분을 수행했습니다. 서로 상호 작용하는 모든 개체는 우리 프로그램의 작업을 구성합니다. 게다가 우리가 작성한 코드는 프로그램의 다른 곳에서 재사용될 수 있어 시간도 많이 절약됩니다.