앱의 일부가 다른 언어로 작성된 경우 데이터 구조의 중복을 피하는 방법은 무엇입니까?

예를 들어, Java 로 앱을 작성한다고 가정하십시오 .

앱은 Python으로 작성된 API 서버와 통신합니다 .

Python 서버는 SQL 데이터베이스 와 통신 합니다.

JavaScript로 작성된 앱 웹 사이트도 있습니다 .

4 개의 다른 언어를 사용하면 본질적으로 동일한 데이터 구조를 4 개의 다른 시간으로 반복하는 것이 쉽습니다.

예를 들어, User유형은 다음과 같습니다 (의사 코드).

type User {
  integer id;
  string name;
  timestamp birthday;
}

프로젝트의 모든 부분은에 대한 일종의 표현이 필요합니다 User. Java와 Python 부분에는 두 가지 다른 class선언 이 필요합니다 . 데이터베이스에는 User테이블 선언 이 필요합니다 . 그리고 프런트 엔드 사이트 User도 역시 표현해야합니다 .

이 유형을 4 번 반복하면 실제로 반복하지 말아야 할 원칙 이 깨집니다 . 또한 User유형이 변경되면 프로젝트의 모든 다른 부분에서 이러한 변경 사항을 반복해야한다는 문제가 있습니다.

Google의 protobuf 라이브러리는 특수 구문을 사용하여 데이터 구조를 작성한 다음 라이브러리가 여러 프로그래밍 언어로 구조 선언을 생성하는이 문제에 대한 일종의 솔루션을 제공 한다는 것을 알고 있습니다. 그러나 이것은 여전히 유형에 대한 유효성 검사 논리를 반복 해야하는 문제를 다루지 않습니다.

누구든지 이것에 관한 책이나 블로그 게시물에 대한 제안이나 링크가 있습니까?

design-patterns object-oriented-design code-reuse

— 노르 망고 르 만
소스

이것이 많은 사람들이 모든 개발을 JavaScript로 옮기는 이유 중 하나입니다. 클라이언트 (웹, 모바일 용 이온, 데스크탑 용 전자), 서버 (노드), 데이터베이스 (MongoDB)에서 작동합니다.

— Paul

백엔드와 프론트 엔드가 동일한 언어를 사용하는 경우 동일한 데이터 구조를 공유 할 수 있습니다. 다른 코드베이스를 사용하는 경우 반복하지 않습니다. 툴링을 사용하여 다른 개발 플랫폼의 xml 스키마 또는 Json 문자열에서 클래스를 생성하십시오.

— Jon Raynor

Repeating this type 4 different times really breaks the Don't-Repeat-Yourself principle. 그렇지 않습니다. 다른 일을하는 4 가지 시스템이 있습니다. 너무 많이 말리고 있습니다. 내 경험에 비추어 볼 때, 재사용 가능성은 악의 씨앗입니다. 그것은 User4 개의 다른 언어로 4 번 반복되는 것보다 더 나쁩니다 . 분산 환경에서 커플 링은 문제입니다. 건조하지 않습니다.

— Laiv

답을 찾을 시간이 없다 : 필요에 따라 OWL을 사용하여 유효성 검사 규칙을 공식화 할 수있다 (온톨로지 구축). 그런 다음 유효성 검사 규칙은 "데이터"가되어 필요한 지점에서 사용할 수 있습니다. 그런 다음 중앙 위치에서 규칙을 변경할 수 있습니다.

— Daniel Jour

답변:

당신은하지 않습니다. 아니면 정말 안됩니다.

앱, 서버 및 웹 사이트를 별도의 컨텍스트로 생각하면 중복 구조가있는 것이 좋습니다. 이것이 좋은 이유 :

구조는 비슷하지만 동일하지 않습니다. 구조의 90 %가 모든 상황에서 동일하더라도. 그것은 당신에게 엄청난 두통을 줄 10 %입니다.
패턴과 구현이 다를 수 있습니다. 다른 언어와 프레임 워크를 사용하면 모든 언어와 프레임 워크에서 동일한 구현을하기가 너무 어려워집니다.
공유 구조는 종속성이되어 관리해야합니다. 한 상황에서 큰 변화가 다른 상황에서는 무섭기 때문에, 의존성을 공유하면 개발이 크게 복잡해집니다. 따라서이 공유 의존성 개발을 조정하기 위해 많은 노력이 필요합니다
컨텍스트마다 배포가 다릅니다. 모든 컨텍스트에서 동일한 데이터 구조와 동일한 유효성 검사 코드를 공유하도록 관리하더라도 한 컨텍스트의 새 버전이 배포되고 다른 컨텍스트는 이전 버전에 배치 될 수 있으므로 버전의 비동기 화가 필요한 상황은 여전히 해결되다

DRY 원칙은 놀랍지 만 컨텍스트 나 레이어간에 데이터 구조를 공유하면 해결하는 것보다 더 많은 문제가 발생한다고 생각합니다. 특히 프로젝트가 커지면 다른 사람들이 다른 상황에서 작업 할 수 있습니다.

— 크게 기쁘게
소스

@Euphoric은 코드를 복제하지 않는 몇 가지 좋은 이유를 나열했다고 생각합니다. 그러나 그렇게 해야하는 경우 코드 생성을 사용하는 것이 좋습니다.

정식 형태의 데이터 찾기

효과적으로 수행하려면 먼저 표준 형식의 데이터가 무엇인지 찾아야합니다. SQL 스키마입니까, 아니면 Java 프로그램의 클래스입니까?

그것으로부터 다른 형태를 (자동으로) 파생 시키십시오

그런 다음 표준 형식에서 다른 모든 형식을 생성하는 방법을 고안하십시오. 예를 들어, 표준 형식이 SQL 스키마라고 가정하면 JavaScript, Java 및 Python 코드를 쉽게 생성 할 수 있습니다 (SQL은 쉽게 구문 분석되고 표준 소스의 좋은 후보입니다).

차이점 수용

생성 된 코드의 섹션을 "만지지 마십시오"로 쉽게 표시 할 수 있어야합니다. 이렇게하면 모든 다른 표현 (예 : JS 프론트 엔드 및 Java 백엔드 용으로 작성한 사용자 정의 코드)간에 필요한 차이를 수용 할 수 있습니다. 재생 전반에 걸쳐 보존되어야합니다.
힘내에서 예를 들어; 당신은이 파일이 이미 텍스트를 포함 커밋 메시지를 입력 할 수 편집기를 엽니 다,하지만이있을 때 # -------- >8 --------알 수있는 마커 당신의 내용 끝을, 어디 는 자동으로 생성 된 텍스트가 시작됩니다.

그래도 가능하다면-그러한 복제를 피하십시오. 대부분의 코드가 자동으로 생성 되더라도 PITA입니다.

이 답변은 "여기에 모범 사례가 있습니다"대신 약간의 이야기 시간입니다. 내가 설명 한 것은 내가 당신과 같은 문제가 있고 시스템의 다른 부분에 동일한 데이터가 있어야 할 때 한 번 한 일입니다. (또는 오히려 두 개의 다른 시스템에서).

— 마엘
소스