OOP 사상과 디자인

OOP - 객체 지향 프로그래밍. OOP 사고란 객체지향 그 자체의 개념을 말합니다. OOP 디자인은 모든 코드를 클래스로 캡슐화하는 것을 의미하지 않습니다. 왜냐하면 그것은 객체 지향 프로그래밍만을 의미하기 때문입니다.

OOP - 객체 지향 프로그래밍은 단지 연습일 뿐입니다. OOP 사고는 기본입니다. 중요한 것은 접근 방식이 아니라 달성하려는 실제 목표입니다.

JAVA 언어는 항상 대부분의 객체 지향 목표를 달성할 수 있습니다. 그 이유는 아주 간단합니다. 그것은 언어 자체의 한계 때문이다.

JAVA의 모든 것은 클래스에 있어야 합니다. 클래스 외부의 독립형 함수는 허용되지 않습니다. 디자인 패턴은 JAVA의 출현으로 인해 존재합니다. 이러한 관점에서 JAVA는 소프트웨어 세계의 사고 방식을 변화시켰습니다.

OOP의 목표는 코드가 SOLID 원칙을 준수하도록 만드는 것입니다. 이러한 원칙은 디자인 패턴에 관한 모든 책의 시작 부분에 소개됩니다.

하지만 이는 이론적인 목표입니다. 실제 목표는 우리가 하는 일을 왜 하는지 답하는 것입니다. 우리는 항상 미래를 알 수 없기 때문입니다. 수요가 어떻게 변할지는 알 수 없습니다. 오늘은 제한된 시간 동안만 단순화된 버전을 제공할 수 있을 것입니다. 하지만 앞으로는 확실히 확대될 것이다. 오늘 우리가 한 일이 모든 것을 다루었을지 모르지만 언젠가는 고려되지 않은 또 다른 구성 요소가 있다는 것을 알게 될 것입니다.

객체지향이 없다면 가장 간단한 스위치 케이스 구조로 완성했습니다. 이 때문에 우리는 핵심 코드를 재작업해야 했습니다. 그러나 코드가 SOLID 원칙을 준수한다면 기존 코드에 새 CLASS를 추가하기만 하면 됩니다.

찾기는 어렵지 않습니다. 플러그인 아이디어는 OOP에서 유래되었습니다. 그래서 이때 OOP를 살펴보면 단순히 흩어져 있는 코드를 클래스로 캡슐화하는 문제가 아닙니다.

SOLOD 원칙에 따라 무엇이 추상적이고 무엇이 구체적인지 명확히 해야 합니다. 우리는 제한된 문제별 코드만 제공하지만 모두 전체적인 추상화에 의존합니다. 동일한 유형의 새로운 특정 문제가 있는 경우 클래스를 추가하기만 하면 됩니다. 이것이 디자인 패턴 아이디어의 핵심이다.

OOP 디자인은 그것과는 거리가 멀다. 코드 가독성과 유지 관리성 역시 디렉토리와 문서에 따라 달라집니다. 표면적으로 이것은 중요한 세부 사항이 아닙니다. 그러나 현실은 매우 중요합니다. 특히 특정 문제에 대한 핵심 모듈 설계 또는 PHP 개발 프레임워크 설계. 디렉토리의 가독성이나 OOP 준수 여부에 따라 사람들이 디렉토리를 얼마나 빨리 이해하고 수용할 의지가 있는지가 결정됩니다. 예를 들어 SYSMFONY의 디렉터리 구조는 그다지 좋지 않습니다. 오래된 브랜드임에도 불구하고 초기에는 큰 시장을 점유했다. 그러나 시장은 여전히 ​​몇 가지 새로운 프레임워크로 나누어져 있습니다. 돌이켜보면 그런 코드들은 KOHANA처럼 디자인이 별로 좋지 않았지만 CI는 꽤 수용하기 쉬웠고 디렉토리 구조와도 연관이 있었습니다. 이는 일부 국내 프레임워크가 사용자에게 수용될 수 있는 이유이기도 합니다. 단지 중국어 버전이기 때문만은 아니다.

OOP 디자인의 아이디어는 단지 코드 측면이 아니라 아키텍처와 디자인의 모든 측면에서 나타난다고 볼 수 있습니다.

Php 프레임워크의 가장 큰 문제점은 오픈소스 시스템에는 대규모 프로젝트를 실제로 경험한 건축가만큼 충분한 경험을 가진 사람이 없기 때문입니다. 이것은 매우 변명의 여지가 있습니다. 그러나 기업이 오픈 소스를 사용하면 수년간 운영한 후 시스템이 더 커지고 복잡해지며, 사용하기 쉽고 유지 관리하기 쉬운 명확한 아키텍처를 갖지 못한다면 비극이 될 것입니다.

어떤 사람들은 이러한 회사들이 이를 활용하여 2차 개발이 필요한 고객을 위해 돈을 벌 수 있다고 말합니다. 사실 이런 종류의 돈을 버는 것은 항상 제한적입니다. 좋은 핵심 아키텍처가 진정한 소프트웨어 산업화를 가져올 것이기 때문입니다. 그리고 상당한 비용 절감이 있을 것입니다.

사실 그러고 보면 개발 프레임워크는 꽤 간단합니다. 한두 문장으로 요약할 수 있을 정도로 매우 간단합니다. 첫째, 사용자가 호출할 수 있는 다양한 클래스 라이브러리를 제공하므로 사용자가 더 적은 코드를 작성할 수 있습니다. 두 번째는 사용자가 필요한 플러그인을 쉽게 추가하고 사용자 개발을 줄일 수 있도록 하는 것입니다. 이것은 실제로 서로를 호출하는 관련 시스템입니다. MVC 시스템에서는 순수한 OOP 프레임워크이고 후자는 사용자의 코드를 호출하는 프레임워크입니다. 이와 관련하여 가장 눈에 띄는 것은 사용자 인터페이스 구성 요소입니다. PHP에는 이 범주에 속하는 프레임워크가 많이 있습니다. 그러나 그것들은 모두 매우 초보적이다. JAVA의 FCS나 TYPESTRY와 비교할 수 있는 것은 없습니다. 일부 초보자는 200KB 미만의 태그 엔진을 게시할 수도 있습니다. 코드를 보지 않고도 SOLID 원칙을 따르는 것은커녕 디자인 패턴도 없을 것이라고 상상할 수 있습니다. 그러면 확장 및 유지 관리에 상당한 문제가 발생합니다.

그래서 우리는 얼마나 많은 인터넷 회사들이 PHP를 기반으로 하는 웹사이트를 가지고 있는지 생각해 보았습니다. 겉으로는 PHP를 사용하면 비용이 절감되는 것처럼 보이지만 어느 정도까지 줄일 수 있을까요? 핵심은 여전히 ​​OOP 코드부터 OOP 아키텍처까지입니다. OOP 아키텍처 수준에 따라 기술 부서의 개발 효율성과 비용이 결정됩니다.