“낮은”응용 계층이“높은”계층을 인식하지 않는 것이 좋은 생각 인 이유는 무엇입니까?


66

일반적인 (잘 설계된) MVC 웹 앱에서 데이터베이스는 모델 코드를 인식하지 못하고, 모델 코드는 컨트롤러 코드를 인식하지 않으며, 컨트롤러 코드는 뷰 코드를 인식하지 못합니다. (하드웨어에서 시작하거나 더 나아가서 패턴이 동일 할 수 있다고 생각합니다.)

다른 방향으로 가면 한 레이어 만 내려갈 수 있습니다. 뷰는 컨트롤러를 인식 할 수 있지만 모델은 인식 할 수 없습니다. 컨트롤러는 모델을 인식 할 수 있지만 데이터베이스는 인식 할 수 없습니다. 모델은 데이터베이스는 알 수 있지만 OS는 알 수 없습니다. (더 깊은 것은 아마 관련이 없습니다.)

이것이 왜 좋은 아이디어인지 직관적으로 파악할 수는 있지만 명확하게 표현할 수는 없습니다. 이 단방향 스타일의 레이어링이 좋은 아이디어 인 이유는 무엇입니까?


10
데이터베이스에서보기로 데이터가 "업"되기 때문일 수 있습니다. 데이터베이스에서 "시작"하고보기에서 "도착"합니다. 데이터가 "이동"함에 따라 레이어 인식이 반대 방향으로 진행됩니다. "따옴표"를 사용하고 싶습니다.
Jason Swett

1
마지막 문장에 단방향 태그를 달았습니다. 연결 목록이 이중 연결 목록보다 훨씬 일반적인 이유는 무엇입니까? 단일 연결 목록으로 관계 유지 관리가 훨씬 간단 해집니다. 우리는 재귀 호출이 훨씬 적어지고 일반적인 그래프 특성이 전체적으로 추론하기 쉬워지기 때문에 이러한 방식으로 의존성 그래프를 만듭니다. 합리적인 구조는 본질적으로 유지 관리가 쉬우 며, 마이크로 레벨 (구현)에서 그래프에 영향을 미치는 것과 동일한 것이 매크로 레벨 (아키텍처)에서도 마찬가지입니다.
지미 호파

2
실제로 대부분의 경우 View가 Controller를 인식하는 것이 좋은 방법이라고 생각하지 않습니다. 컨트롤러는 컨트롤러의 인식보기를 가진보기의 거의 항상 인식하고 있기 때문에 생성 순환 참조
에이미 Blankenship의

8
나쁜 비유 시간 : 같은 이유로, 운전하는 동안 차에서 등을 대고 때리는 사람은 일반적으로 사고에 책임이 있고 책임이 있습니다. 그는 당신이 무엇을하고 있고 통제해야하는지 볼 수 있으며, 당신을 피할 수 없다면 그것은 안전 규칙을 존중하지 않았다는 것을 의미합니다. 다른 방법은 아닙니다. 그리고 체인으로 연결하면 뒤에서 일어나는 일에 대해 걱정할 필요가 없습니다.
haylem

1
분명히 뷰는 강력한 형식의 뷰 모델을 알고 있습니다.
DazManCat

답변:


121

계층, 모듈, 실제로 아키텍처 자체는 사람이 컴퓨터 프로그램을보다 쉽게 ​​이해할 수 있도록하는 수단입니다 . 문제를 해결하는 수치 적으로 최적의 방법은 수백만 년이 지난 메모리 제한이나 DNA 시퀀스를 방해하는 임베디드 시스템에서 어셈블러 코드가 엄청나게 최적화되어 있는지 여부에 관계없이 거의 항상 모듈화되지 않은 자체 참조 또는 자체 수정 코드의 부정한 혼란입니다. 선택 압력. 이러한 시스템에는 계층이없고 정보 흐름의 식별 가능한 방향이 없으며 실제로 우리가 전혀 식별 할 수있는 구조가 없습니다. 저자를 제외한 모든 사람들에게 그들은 순수한 마술로 일하는 것 같습니다.

소프트웨어 엔지니어링에서는이를 피하고 싶습니다. 좋은 아키텍처는 정상적인 사람들이 시스템을 이해할 수 있도록하기 위해 일부 효율성을 희생하려는 의도적 인 결정입니다. 한 번에 한 가지를 이해하는 것이 함께 사용될 때만 이해되는 두 가지를 이해하는 것보다 쉽습니다. 그렇기 때문에 모듈과 레이어가 좋은 아이디어입니다.

그러나 필연적으로 모듈은 서로 함수를 호출해야하며 레이어는 서로 위에 작성되어야합니다. 따라서 실제로는 일부 부품에 다른 부품이 필요하도록 시스템을 구성해야합니다. 선호되는 타협은 한 부분이 다른 부분을 필요로하지만 그 부분은 첫 번째 부분을 요구하지 않는 방식으로 구성하는 것입니다. 이것이 바로 단방향 계층화가 제공하는 것입니다. 비즈니스 규칙을 몰라도 데이터베이스 스키마를 이해하고 사용자 인터페이스를 몰라도 비즈니스 규칙을 이해할 수 있습니다. 양방향으로 독립성을 갖는 것이 좋을 것입니다. 누군가가 아무것도 몰라도 새로운 UI를 프로그래밍 할 수 있습니다.비즈니스 규칙에 대해서는 전혀 없지만 실제로는 불가능합니다. "순환 종속성이 없음"또는 "종속성이 한 수준 아래로만 도달해야합니다"와 같은 경험의 규칙은 단순히 한 번에 한 가지가 두 가지보다 이해하기 쉽다는 기본 아이디어의 실질적으로 달성 가능한 한계를 포착합니다.


1
" 정상적인 사람들 이 시스템을 이해할 수있게한다"는 것은 무엇을 의미 합니까? 새로운 프로그래머가 대부분의 사람들처럼 자신이 대부분의 사람들보다 똑똑하다고 생각하기 때문에 좋은 점을 거부하도록 권장하는 문구라고 생각합니다. 나는 "인간이 이해할 수있는 시스템을 만드는"말할 것
토마스 Bonini

12
완전한 디커플링이 노력하기에 이상적이라고 생각하지만 왜 작동하지 않는지 이해하지 못하는 사람들에게는이 내용을 읽어야합니다.
Robert Harvey

6
글쎄, @Andreas, 항상 Mel 있습니다.
TRiG

6
"더 이해하기 쉽다"는 것만으로는 충분하지 않다고 생각합니다. 또한 코드를보다 쉽게 ​​수정, 확장 및 유지 관리 할 수 ​​있도록합니다.
Mike Weller

1
@Peri : 그러한 법이 존재합니다 ( en.wikipedia.org/wiki/Law_of_Demeter 참조) . 당신이 그것에 동의하는지 여부는 또 다른 문제입니다.
Mike Chamberlain

61

근본적인 동기는 다음과 같습니다 : 당신은 전체 층을 제거하고 완전히 다른 (재 작성된) 층을 대체 할 수 있기를 원하며, NOBODY는 차이를 통지해야합니다.

가장 확실한 예는 아래쪽 레이어를 제거하고 다른 레이어를 대체하는 것입니다. 이것은 하드웨어 시뮬레이션에 대해 상위 계층을 개발 한 다음 실제 하드웨어를 대체 할 때 수행하는 작업입니다.

다음 예는 중간 레이어를 제거하고 다른 중간 레이어를 대체하는 경우입니다. RS-232를 통해 실행되는 프로토콜을 사용하는 응용 프로그램을 고려하십시오. 언젠가는 "다른 것이 바뀌었기 때문에"프로토콜 인코딩을 완전히 바꿔야합니다. (예 : LA 시내에서 Marina Del Rey 로의 무선 링크를 통해 작업하고 있고 LA 시내에서 유로파 궤도를 도는 프로브로의 무선 링크를 통해 작업하고 있기 때문에 ASCII 스트림의 직선 ASCII 인코딩에서 리드-솔로몬 인코딩으로 전환 , 목성의 위성 중 하나이며, 그 링크는 훨씬 나은 순방향 오류 수정이 필요합니다.)

이 작업을 수행 할 수있는 유일한 방법은 각 레이어가 알려진 정의 된 인터페이스를 해당 레이어로 내보내고 아래 정의 된 레이어로 알려진 정의 된 인터페이스를 기대하는 것입니다.

이제 하위 계층이 상위 계층에 대해 전혀 아는 것은 아닙니다. 오히려 하위 계층이 아는 것은 바로 상위 계층이 정의 된 인터페이스에 따라 정확하게 작동한다는 것입니다. 정의 된 인터페이스에없는 내용은 통지없이 변경 될 수 있으므로 더 이상 알 수 없습니다.

RS-232 계층은 ASCII, Reed-Solomon, Unicode (아랍어 코드 페이지, 일본어 코드 페이지, Rigellian Beta 코드 페이지) 또는 무엇을 실행하는지 알 수 없습니다. 그것은 일련의 바이트를 얻는다는 것을 알고 있으며 그 바이트를 포트에 쓰고 있습니다. 다음 주에 그는 완전히 다른 무언가에서 완전히 다른 바이트 시퀀스를 얻을 수 있습니다. 그는 상관하지 않습니다. 그는 바이트 만 움직입니다.

레이어드 디자인의 첫 번째 (그리고 가장 좋은) 설명은 Dijkstra의 고전 논문 "The Multiprogramming System의 구조" 입니다. 이 사업을 반드시 읽으십시오.


도움이되었으며 링크에 감사드립니다. 두 가지 답변을 가장 좋은 답변으로 선택할 수 있기를 바랍니다. 나는 기본적으로 내 머리에 동전을 뒤집어 놓고 다른 것을 골랐지만 여전히 당신의 돈을 올렸습니다.
Jason Swett

훌륭한 예는 +1입니다. 나는 JRS에 의해 주어진 설명처럼
VISU

@JasonSwett : 동전을 뒤집었다면, 그 답을 지정할 때까지 동전을 뒤집었을 것입니다! ^^ 요한에게 +1.
Olivier Dulac

비즈니스 규칙 계층을 제거하고 다른 규칙으로 바꾸려는 경우는 거의 없기 때문에이 점에 다소 동의하지 않습니다. 비즈니스 규칙은 UI 또는 데이터 액세스 기술보다 훨씬 느리게 변경됩니다.
Andy

딩 딩 딩 !!! 나는 당신이 찾고있는 단어가 '디커플링'이라고 생각합니다. 이것이 좋은 API입니다. 모듈의 공용 인터페이스를 정의하여 범용으로 사용할 수 있습니다.
Evan Plaice

8

더 높은 레벨 이 변경 될 수 있기 때문 입니다.

이러한 상황이 발생하면 요구 사항 변경, 새로운 사용자, 다른 기술, 모듈 식 (즉, 단방향 계층화) 응용 프로그램으로 인해 유지 관리가 덜 필요하고 새로운 요구에 맞게보다 쉽게 ​​조정되어야합니다.


4

주된 이유는 그것이 더 밀접하게 결합되어 있기 때문이라고 생각합니다. 커플 링이 강할수록 나중에 문제가 발생할 가능성이 높아집니다. 이 기사 더 많은 정보보기 : 커플 링

발췌문은 다음과 같습니다.

단점

단단히 결합 된 시스템은 다음과 같은 발달 특성을 나타내는 경향이 있으며 종종 단점으로 간주됩니다. 한 모듈을 변경하면 일반적으로 다른 모듈 변경의 파급 효과가 발생합니다. 모듈 간 어셈블리는 모듈 간 종속성이 증가하여 더 많은 노력과 시간이 필요할 수 있습니다. 종속 모듈이 포함되어 있어야하므로 특정 모듈을 재사용 및 / 또는 테스트하기가 더 어려울 수 있습니다.

티저 결합 시스템을 갖는 이유는 성능상의 이유 때문이다. 내가 언급 한 기사에도 이것에 대한 정보가 있습니다.


4

IMO는 매우 간단합니다. 사용 된 컨텍스트를 계속 참조하는 것을 재사용 할 수 없습니다.


4

레이어에는 양방향 종속성이 없어야합니다.

계층 구조의 장점은 계층을 독립적으로 사용할 수 있어야한다는 것입니다.

  • 하위 계층을 변경하지 않고 첫 번째 프리젠 테이션 계층 외에 다른 프리젠 테이션 계층을 구축 할 수 있어야합니다 (예 : 기존 웹 인터페이스 외에 API 계층 구축)
  • 최상위 레이어를 변경하지 않고 하위 레이어를 리팩토링하거나 결국 대체 할 수 있어야합니다.

이러한 조건은 기본적으로 대칭 입니다. 그것은 단지 하나의 종속 방향을 가지고 일반적으로 더 나은,하지만 그들은 왜 설명 한다 .

종속성 방향은 명령 방향을 따라야합니다.

하향식 종속성 구조를 선호하는 이유는 상단 객체하단 객체를 만들고 사용 하기 때문 입니다. 종속성은 기본적으로 "A 없이 B없이 작동 할 수없는 경우 A B에 종 속됨"을 의미하는 관계입니다 . 따라서 A의 객체가 B의 객체를 사용하는 경우 종속성이 어떻게 적용되는지입니다.

이것은 다소 임의적 인 방법입니다. MVVM과 같은 다른 패턴에서는 컨트롤이 맨 아래 레이어에서 쉽게 흐릅니다. 예를 들어, 보이는 캡션이 변수에 바인딩되고 그에 따라 변경되는 레이블을 설정할 수 있습니다. 기본 개체는 항상 사용자가 상호 작용하는 개체이며 대부분의 작업을 수행하기 때문에 하향식 종속성을 갖는 것이 일반적으로 여전히 바람직합니다.

위에서 아래로 메소드 호출을 사용하지만 아래에서 위로 (일반적으로) 이벤트를 사용합니다. 이벤트는 컨트롤이 다른 방향으로 흐를 때에도 종속성이 하향 조정되도록합니다. 최상위 계층 개체는 하위 계층의 이벤트를 구독합니다. 맨 아래 레이어는 맨 위 레이어에 대해 아무것도 몰라 플러그인 역할을합니다.

예를 들어 단일 방향을 유지하는 다른 방법도 있습니다.

  • 연속 (람다 또는 호출 할 메소드 및 비동기 메소드로 이벤트 전달)
  • 서브 클래 싱 (B와 같은 부모 클래스의 A에 서브 클래스를 생성 한 다음, 플러그인과 같은 하위 레이어에 주입)

3

Matt Fenwick과 Kilian Foth가 이미 설명한 것에 2 센트를 추가하고 싶습니다.

소프트웨어 아키텍처의 한 가지 원칙은 더 작고 독립적 인 블록 (블랙 박스)을 구성하여 복잡한 프로그램을 작성해야한다는 것입니다. 이는 의존성을 최소화하여 복잡성을 줄입니다. 따라서이 단방향 종속성은 소프트웨어를보다 쉽게 ​​이해하고 소프트웨어 관리에서 복잡성을 관리하는 것이 가장 중요한 문제이기 때문에 좋은 아이디어입니다.

따라서 계층 구조에서 하위 계층은 상위 계층이 구축 된 추상화 계층을 구현하는 블랙 박스입니다. 하위 계층 (예 : 계층 B)이 상위 계층 A의 세부 사항을 볼 수있는 경우 B는 더 이상 블랙 박스가 아닙니다. 구현 세부 사항은 사용자의 일부 세부 사항에 따라 다르지만 블랙 박스의 아이디어는 컨텐츠 (구현)는 사용자와 관련이 없습니다!


3

재미로.

치어 리더의 피라미드를 생각해보십시오. 맨 아래 행은 그 위의 행을 지원합니다.

그 줄의 치어 리더가 아래를 내려다보고 있으면 안정적이고 균형을 유지하여 그 위의 사람들이 떨어지지 않습니다.

그녀가 자신의 모든 사람이 어떻게 지내고 있는지 살펴보면 균형을 잃어 전체 스택이 떨어집니다.

실제로 기술적 인 것은 아니지만 도움이 될 것으로 생각되는 비유였습니다.


3

이해의 용이성과 어느 정도 교체 가능한 구성 요소는 확실히 좋은 이유이지만, 동일한 유지 보수 이유 (그리고 아마도 레이어가 처음에 발명 된 이유)는 소프트웨어 유지 보수 관점에서 나옵니다. 결론은 종속성으로 인해 문제가 발생할 수 있다는 것입니다.

예를 들어, A가 B에 의존한다고 가정 해 봅시다. A에 의존하는 것이 없기 때문에 개발자는 A 이외의 다른 것을 깰 염려없이 걱정없이 A를 마음의 내용으로 바꿀 수 있습니다. 그러나 개발자가 B를 변경하려는 경우 변경 B에서 만들어진 A는 잠재적으로 A를 깨뜨릴 수 있습니다. 이것은 개발자가 프로그램의 한 부분에서 버그를 수정하고 다른 곳에서는 프로그램과 전혀 관련이없는 부분에서 버그를 발생시키는 초기 컴퓨터 시절 (구조적 개발을 생각하십시오)에서 빈번한 문제였습니다. 의존성 때문입니다.

예제를 계속 진행하기 위해 A가 B에 의존하고 B가 A에 의존한다고 가정합니다. 순환 종속성. 이제 언제 어디서나 변경하면 다른 모듈이 손상 될 수 있습니다. B의 변화는 여전히 A를 깰 수 있지만 이제 A의 변화는 B를 깰 수도 있습니다.

따라서 원래의 질문에서 소규모 프로젝트를 위해 소규모 팀을 운영하는 경우 자유롭게 모든 모듈을 자유롭게 변경할 수 있기 때문에이 모든 것이 과도합니다. 그러나 규모가 큰 프로젝트를 수행하는 경우 모든 모듈이 다른 모듈에 의존하는 경우 변경이 필요할 때마다 다른 모듈이 손상 될 수 있습니다. 대규모 프로젝트에서는 모든 영향을 아는 것이 결정하기 어려울 수 있으므로 일부 영향을 놓칠 수 있습니다.

많은 개발자가있는 대규모 프로젝트 (예 : 계층 A 만 작업하는 계층, 계층 B 및 계층 C 등)가 더 악화됩니다. 변경 사항이 작업중인 내용을 변경하거나 재 작업하지 않도록하기 위해 각 변경 사항을 다른 계층의 구성원과 검토 / 토론해야 할 가능성이 높아집니다. 변경 사항이 다른 사람에게 변경 사항을 강제 적용하면 모듈에서 작업을 수행하는 새로운 방법이 있기 때문에 더 많은 작업을 수행하지 않기 때문에 변경 사항을 변경해야한다고 설득해야합니다. 관료적 인 악몽 IOW.

그러나 A에 대한 종속성을 B에 의존하고 B는 C에 의존하는 경우 C 계층 만 변경 사항을 두 팀에 조정하면됩니다. 레이어 B는 레이어 A 팀과 변경 사항을 조정하기 만하면되고 레이어 A 팀은 코드가 레이어 B 또는 C에 영향을주지 않기 때문에 원하는대로 자유롭게 할 수 있습니다. 따라서 이상적으로는 레이어 C를 매우 변경하도록 레이어를 설계해야합니다. 레이어 B는 약간 변경되고 레이어 A는 대부분의 변경을 수행합니다.


+1 내 고용주에게는 실제로 내가 작업하는 제품에 적용되는 마지막 단락의 본질을 설명하는 내부 다이어그램이 있습니다. 즉, 스택의 속도가 내려 갈수록 변화율이 낮아질 것입니다.
RobV

1

하위 레이어가 상위 레이어를 인식하지 않아야하는 가장 기본적인 이유는 더 많은 종류의 상위 레이어가 있기 때문입니다. 예를 들어, Linux 시스템에는 수천 및 수천 개의 서로 다른 프로그램이 있지만 동일한 C 라이브러리 malloc함수를 호출합니다 . 따라서 이러한 프로그램에서 해당 라이브러리로의 종속성이 있습니다.

"하위 레이어"는 실제로 중간 레이어입니다.

일부 장치 드라이버를 통해 외부를 통해 통신하는 응용 프로그램을 생각해보십시오. 운영 체제가 중간에 있습니다.

운영 체제는 응용 프로그램 또는 장치 드라이버의 세부 정보에 의존하지 않습니다. 동일한 유형의 장치 드라이버에는 여러 종류가 있으며 동일한 장치 드라이버 프레임 워크를 공유합니다. 때때로 커널 해커는 특정 하드웨어 나 장치를 위해 프레임 워크에 특별한 경우를 처리해야합니다 (최근의 예제 : 리눅스의 USB- 시리얼 프레임 워크의 PL2303 특정 코드). 이런 일이 발생하면 그들은 일반적으로 얼마나 많이 빨려 제거해야하는지에 대한 의견을 제시합니다. OS가 드라이버에서 함수를 호출하더라도 호출은 드라이버를 동일하게 보이게하는 후크를 통과하지만, 드라이버가 OS를 호출 할 때 종종 특정 기능을 이름으로 직접 사용합니다.

그래서, 어떤 방법으로, 운영 체제는 정말 응용 프로그램의 관점에서 낮은 층 일을 연결하고 데이터가 적절한 경로를 갈 전환 통신 허브의 종류 : 응용 프로그램의 관점에서. 통신 허브를 설계하면 어떤 용도로든 사용할 수있는 유연한 서비스를 내보내고 장치 나 응용 프로그램 별 해킹을 허브로 옮기지 않아도됩니다.


특정 CPU 핀에 특정 전압을 설정하는 것에 대해 걱정할 필요가없는 한 행복합니다 :)
CVn

1

우려의 분리와 분할 / 정복 접근법은이 질문에 대한 또 다른 설명이 될 수 있습니다. 우려 사항 분리는 이식 기능을 제공하고 좀 더 복잡한 아키텍처에서는 플랫폼 독립적 인 확장 및 성능 이점을 제공합니다.

이와 관련하여 5 계층 아키텍처 (클라이언트, 프리젠 테이션, 비즈니스, 통합 및 리소스 계층)에 대해 생각할 경우 하위 레벨의 아키텍처는 상위 레벨의 논리 및 비즈니스를 인식하지 않아야하며 그 반대도 마찬가지입니다. 나는 통합 및 자원 수준으로서 낮은 수준을 의미합니다. 통합 및 실제 데이터베이스 및 웹 서비스 (타사 데이터 공급자)에서 제공되는 데이터베이스 통합 인터페이스는 리소스 계층에 속합니다. 따라서 확장 성 또는 기타 측면에서 MySQL 데이터베이스를 MangoDB와 같은 NoSQL 문서 DB로 변경한다고 가정하십시오.

이 접근 방식에서 bussiness 계층은 통합 계층이 리소스에 의한 연결 / 전송을 제공하는 방식에 신경 쓰지 않습니다. 통합 계층에서 제공하는 데이터 액세스 개체 만 찾습니다. 이것은 더 많은 시나리오로 확장 될 수 있지만 기본적으로 우려의 분리가 가장 큰 이유 일 수 있습니다.


1

Kilian Foth의 답변을 확장 하면서이 레이어링 방향은 인간이 시스템을 탐색하는 방향에 해당합니다.

계층화 된 시스템의 버그를 수정하는 새로운 개발자라고 가정 해보십시오.

버그는 일반적으로 고객의 요구와 얻는 것과의 불일치입니다. 고객이 UI를 통해 시스템과 통신하고 UI (문자 그대로 '사용자 인터페이스'를 의미 함)를 통해 결과를 얻으면 버그도 UI 측면에서보고됩니다. 따라서 개발자는 선택의 여지가 없으며 UI를 살펴보고 어떤 일이 발생했는지 파악할 수 있습니다.

이것이 하향식 레이어 연결이 필요한 이유입니다. 이제 연결이 양방향으로 진행되지 않는 이유는 무엇입니까?

글쎄, 당신은 그 버그가 어떻게 발생할 수 있는지 세 가지 시나리오를 가지고 있습니다.

UI 코드 자체에서 발생할 수 있으므로 현지화 될 수 있습니다. 이것은 쉽습니다. 장소를 찾아서 고치면됩니다.

UI에서 호출 한 결과 시스템의 다른 부분에서 발생할 수 있습니다. 어느 정도 어려운 것은 호출 트리를 추적하고 오류가 발생한 장소를 찾아 수정합니다.

UI 코드를 호출 한 결과 발생할 수 있습니다. 어려운 점은 전화를 잡고 소스를 찾은 다음 오류가 발생하는 위치를 찾아야합니다. 시작 지점이 호출 트리의 단일 브랜치에 깊숙이 위치하고 있고 올바른 호출 트리를 먼저 찾아야한다고 생각하면 UI 코드에 여러 호출이있을 수 있으므로 디버깅이 중단됩니다.

가장 어려운 경우를 최대한 제거하기 위해 순환 종속성은 권장하지 않으며 레이어는 대부분 하향식으로 연결됩니다. 다른 방법으로 연결해야하는 경우에도 일반적으로 제한되고 명확하게 정의됩니다. 예를 들어, 콜백이 일종의 역방향 연결 인 경우에도 콜백에서 호출되는 코드는 일반적으로이 콜백을 먼저 제공하여 역방향 연결을위한 일종의 "선택"을 구현하고 체계.

레이어링은 도구이며 주로 기존 시스템을 지원하는 개발자를 대상으로합니다. 레이어 간의 연결도이를 반영합니다.


-1

여기에 명시 적으로 언급 된 또 다른 이유는 코드 재사용 가능성 입니다. 우리는 이미 교체 된 RS232 미디어의 예를 가지고 있었으므로 한 걸음 더 나아갈 수 있습니다 ...

드라이버를 개발한다고 상상해보십시오. 그것은 당신의 일이고 당신은 꽤 많은 것을 씁니다. 실제 미디어와 마찬가지로 프로토콜이 특정 시점에서 반복되기 시작할 수 있습니다.

똑같은 일을 반복해서 좋아하는 팬이 아니라면 당신이 시작할 일은 이런 것들에 재사용 가능한 레이어를 작성하는 것입니다.

Modbus 장치에 대해 5 개의 드라이버를 작성해야한다고 가정하십시오. 그중 하나는 Modbus TCP를 사용하고 다른 하나는 RS485에서 Modbus를 사용하고 나머지는 RS232를 사용합니다. 5 개의 드라이버를 작성하기 때문에 Modbus를 5 번 다시 구현하지 않을 것입니다. 또한 아래에 3 개의 다른 물리적 계층이 있으므로 Modbus를 3 번 ​​다시 구현하지는 않습니다.

당신이하는 일은 TCP 미디어 액세스, RS485 미디어 액세스 및 아마도 RS232 미디어 액세스를 작성하는 것입니다. 이 시점에서 위에 모드 버스 레이어가 있다는 것을 아는 것이 현명한가? 아마 아닙니다. 다음에 구현할 드라이버는 이더넷을 사용하지만 HTTP-REST를 사용합니다. HTTP를 통해 통신하기 위해 이더넷 미디어 액세스를 다시 구현해야한다면 부끄러운 일입니다.

위의 한 계층에서는 Modbus를 한 번만 구현할 것입니다. 그 Modbus 레이어는 다시 한 번 드라이버를 알지 못합니다. 물론이 드라이버는 모드 버스와 통신해야하며 이더넷을 사용하고 있음을 알아야합니다. 그러나 방금 설명한 방식을 구현했지만 레이어를 제거하고 교체 할 수는 없었습니다. 물론 나에게 가장 큰 이점은 바로 기존 이더넷 계층을 원래 생성 한 프로젝트와 전혀 관련이없는 것으로 재사용하는 것입니다.

이것은 아마도 우리가 매일 개발자로 볼 수 있으며, 그로 인해 많은 시간을 절약 할 수 있습니다. 모든 종류의 프로토콜과 다른 것들을위한 수많은 라이브러리가 있습니다. 명령 방향에 따른 종속성 방향과 같은 원리로 인해 재사용 가능한 소프트웨어 계층을 구축 할 수 있습니다.


재사용 가능성은 이미 반년 전에 게시
gnat
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.