레슨

1.1 애플리케이션 아키텍처 이 과정은 오랫동안 진지한 애플리케이션의 아키텍처를 설계하지 않을 것이기 때문에 초보자를 위해 설계되었습니다. 그러나 걱정하지 마십시오. 좋은 아키텍처는 규칙이 아니라 예외입니다. 애플리케이션을 구축하기 전에 올바른 애플리케이션 아키텍처를 선택하는 것은 매우 어렵습니다 . 대형 서버 애플리케이션에 널리 사용되는 아키텍처의 예: 계층화 된 아키텍처 (Layered Architecture). 계층화된

3계층 아키텍처 소개 3계층 아키텍처는 인터넷에서 가장 일반적인 상호 작용 아키텍처입니다. 2계층 서버 부분을 논리 계층 과 데이터 계층의 두 부분으로 나누었을 때 나타났습니다 . 다음과 같이 생겼습니다. 클라이언트 계층은 사용자 상호 작용을 담당하는 "분산 응용 프로그램"의 일부입니다. 이 계층은 비즈니스 로직을 포함하지 않아야 하며 중요한 데이터를 저장하지 않아야 합니다. 또한 데이터베이스 계층과 직접 상호 작용하지 말고

MVC 아키텍처 소개 모든 프로그래머가 알고 있는 가장 인기 있는 애플리케이션 아키텍처는 MVC 입니다 . MVC는 Model-View-Controller 의 약자입니다 . 이것은 애플리케이션 구성 요소의 아키텍처만큼 애플리케이션의 아키텍처가 아니지만 나중에 이 뉘앙스로 돌아갈 것입니다. MVC란 무엇입니까? MVC 는 각 구성 요소가 독립적으로 수정될 수 있도록 응용 프로그램 데이터와 제어 논리를 세 개의 개별 구성 요소 (

능률 숙련된 프로그래머는 좋은 아키텍처와 나쁜 아키텍처를 쉽게 구분할 수 있지만 몇 마디로 설명하라는 요청을 받으면 그렇게 할 수 없을 것입니다. 좋은 아키텍처에 대한 단일 기준이나 단일 정의는 없습니다. 그러나 잘 생각해보면 좋은 아키텍처가 만족해야 할 여러 기준을 쓸 수 있다. 좋은 아키텍처는 무엇보다도 프로그램 개발 및 유지 관리 프로세스를 더 간단하고 효율적으로 만드는 논리적 아키텍처입니다. 프로그램의 아키텍처가 양호하

나쁜 디자인의 기준 인생은 매우 간단하게 작동합니다. 종종 똑똑해지기 위해 어리석은 일을 할 필요가 없습니다. 이는 소프트웨어 개발에도 적용됩니다. 대부분의 경우 어떤 일을 잘하기 위해서는 나쁘게만 하지 않으면 됩니다. 대부분의 프로그래머는 잘못 설계된 시스템 부분에 대한 경험이 있습니다. 그러나 더 슬프게도 대부분의 여러분은 자신이 그러한 시스템의 저자라는 사실을 깨닫는 슬픈 경험을 할 것입니다. 우리는 최고를 원했지만 언제

6.1 분해 다양한 기준에도 불구하고 대형 시스템 개발의 주요 과제는 시스템의 복잡성을 줄이는 것 입니다 . 복잡성을 줄이기 위해 부품으로 나누는 것 외에는 아직 발명되지 않았습니다. 때로는 단순함을 위해 이것을 "분할 정복"의 원칙이라고 부르지만 소프트웨어 설계자의 관점에서 우리는 계층 적 분해 에 대해 이야기하고 있습니다 . 복잡한 시스템은 소수의 단순한 하위 시스템으로 구축되어야 하며, 각 하위 시스템은 더 작은 부분으로

계층적 분해 응용 프로그램에 대한 클래스 작성을 즉시 시작해서는 안됩니다. 먼저 설계해야 합니다. 디자인은 사려 깊은 아키텍처로 끝나야 합니다. 그리고 이 아키텍처를 얻으려면 시스템을 지속적으로 분해해야 합니다. 분해는 계층적으로 수행되어야 합니다. 먼저 시스템은 가장 일반적인 형태로 작동을 설명하는 대형 기능 모듈/하위 시스템으로 나뉩니다. 그런 다음 결과 모듈을 더 자세히 분석하고 하위 모듈 또는 개체로 나눕니다. 객체를

8.1 분해가 전부다 명확성을 위해 설명할 주요 사항을 설명하는 좋은 기사 "객체 지향 시스템의 분리"의 그림입니다. 아직도 애플리케이션 아키텍처 설계가 쉽다고 생각하시나요? 8.2 인터페이스, 구현 숨기기 시스템의 결합을 줄이기 위한 주요 원칙은 OOP의 원칙과 그 뒤에 있는 Encapsulation + Abstraction + Polymorphism의 원칙입니다. 그 이유는 다음과 같습니다. 모듈은 서로에 대해 "블랙 박스

9.1 종속성 역전 new Thread().start()서버 애플리케이션에서는 ?를 통해 스트림을 만들 수 없다고 말한 적이 있습니다. 컨테이너만 스레드를 생성해야 합니다. 우리는 이제 이 아이디어를 더욱 발전시킬 것입니다. 또한 모든 객체는 컨테이너에 의해서만 생성되어야 합니다 . 물론 모든 개체에 대해 말하는 것이 아니라 소위 비즈니스 개체에 대해 말하는 것입니다. 그것들은 종종 빈(bin)이라고도 합니다. 이 접근 방식의

직접적인 종속성을 메시징으로 대체 때때로 모듈은 일부 이벤트/변경 사항이 발생했음을 다른 사람들에게 알리기만 하면 되며 나중에 이 정보에 어떤 일이 발생하는지는 중요하지 않습니다. 이 경우 모듈은 "서로에 대해 알" 필요가 전혀 없습니다. 즉, 직접 링크를 포함하고 직접 상호 작용하지만 메시지 (메시지) 또는 이벤트 (이벤트)를 교환하는 것으로 충분합니다. 때로는 메시징을 통한 모듈 통신이 직접 종속성보다 훨씬 약한 것처럼 보