Redux는 삭제 된 신 개체 패턴을 사용합니까?

Redux에 대해 배우는 동안 God-object 패턴 (또는 안티 패턴)이 떠 올랐습니다. 모두 하나의 큰 객체가 있으며 모든 앱 데이터와 조작 방법을 보유하고 있습니다. 그러나 Redux는 엄격한 서명을 유지하면서 객체를 불변으로 만들고 이벤트를 순수하게 만드는 것과 같은 제약을가했습니다.

그래서 Redux는 위생 처리 된 버전의 신 객체를 사용하고 있습니까? 아니면 고전적인 강력한 형식의 OOP가 아닌 Javascript와 관련이 있습니까?

redux

— 굴샨
소스

짧은 대답 : 아닙니다. 긴 대답 (실제로 대답을 이끌어 내야 할 질문) : 데이터베이스는 클래스입니까? 아니면 파일 시스템은 어떻습니까? 아니면 캐시는 어떻습니까? 이 모든 신 패턴도 있습니까?

— code4life

그렇습니다. Redux에 대한 첫 번째 성명서에는 "JavaScript 단일 페이지 응용 프로그램의 요구 사항이 점점 복잡 해짐에 따라 코드가 그 어느 때보 다 많은 상태를 관리해야합니다." -이것은 앱의 상태를 하나의 얼룩으로 관리해야 함을 의미합니다. 나는 그것이 웹 앱에만 국한된 문제라고 생각하며 웹 앱을 구현하는 데 사용되는 가난한 / 결코 설계되지 않은 프레임 워크에 의해 생성되었습니다.

— n13

@ n13 : 중앙 위치에서 액세스 할 수 있다고해서 그것이 하나의 거대한 덩어리라는 것을 의미하지는 않습니다. 예를 들어, 내 데이터베이스는 중앙 집중식으로 액세스 DbContext되지만 ( ) 내부 데이터는 더 작은 부분 (테이블, 스키마)으로 세분됩니다.

— Flater

@Flater 많은 세분화가있는 큰 얼룩은 여전히 큰 얼룩입니다. 평범한 오래된 OO 모델은 모든 데이터를 알아야 할 필요에 따라 구획화합니다. 즉, 각 객체는 매우 적은 양의 상태 / 데이터 만 처리하며 모든 것이 매우 간단합니다. 하나의 거대한 전역 구조체에 모든 것을 저장할 수도 있지만 소프트웨어 디자인이 잘못되어 그렇게 할 수는 없습니다. 소프트웨어 101.

— n13

@ n13 로직을 서브 클래스 (숨겨 지거나 숨기지 않음)로 분리하고 문자와 모범 사례 의 의도 를 모두 준수 하면서 로직에 대한 액세스를 중앙 집중화 할 수 있습니다. 마이크로 서비스와 단일 API를 사용하는 것과 같은 주장입니다. 마이크로 서비스는 옵션이지만 "정상"REST API가 나쁜 습관임을 의미하지는 않습니다.

— Flater

답변:

신의 대상은 무엇입니까? Wikipedia에서 :

프로그램의 전체 기능은 대부분의 "알고있는"객체로 코딩되어 전체 프로그램에 대한 대부분의 정보를 유지하고이 데이터를 조작하기위한 대부분의 방법을 제공합니다. 이 객체는 많은 양의 데이터를 보유하고 있으며 많은 방법을 필요로하기 때문에 프로그램에서의 역할은 신과 비슷합니다 (모든 지식과 모든 것을 포괄).

Redux 저장소에는 하나의 데이터 개체 만 포함되며 2 개 또는 3 개의 메서드 만 필요합니다. 이런 점에서 그것을 신의 대상으로 생각하는 것은 상상하기 어렵습니다. "모두 아는 것" 이 아닙니다 .

이제 감속기가 전혀 고장 나지 않으면 모든 논리가 하나의 기능에 있으면 자격 이 될 수 있지만 상황을 피하기 위해 감속기를 여러 개의 작은 조각으로 나누는 것은 간단합니다.

— 다니엘 T.
소스

OP가 모든 감속기 와 함께 Store를 "하나님의 개체"로 간주 하는지 궁금합니다 .

— user949300

프로그램의 모든 모델 클래스가 함께 신의 대상으로 간주됩니까?

— Daniel T.

나는 전통적인 OOP에서 그것들이 모두 같은 "모든 것"데이터에 대해 작동하는 것은 아니기 때문에 그렇지 않다고 주장한다.

— user949300

감속기는 또한 모든 "모든"데이터에 대해 작동하지는 않습니다. 단일 감속기는 단일 모델 클래스와 동일합니다. 감속기의 데이터는 클래스의 필드와 동일하며 조치는 클래스의 메소드와 동일합니다 (즉, 각 사례는 특정 메소드와 동일합니다)

— Daniel T.

IMO, 위의 질문은 발생하지 않아야합니다. 함수형 프로그래밍 개념은 OOPS의 개념과 비교할 수 없으며 동일한 문제를 해결하는 다른 방법 일뿐입니다.

— Sutikshan Dubey
소스

이 표 이미지를 질문 용으로 만 만드셨습니까? 나는 텍스트로 더 잘 어울리므로 더 빨리로드되고 스크린 리더로 볼 수 있다고 생각합니다.

— Phoenix

OOP도 단방향 데이터 흐름을 장려하지 않습니까? OOP를 단순히 서로에 대한 참조를 보유 할 수있는 클래스의 개념으로 간주하지 않는 한 양방향 참조가 일반적으로 설계 결함을 나타내는 적절한 설계는 아닙니다.

— Steven Jeuris 2016 년

OOP 및 FP에서 언급 한 대부분의 내용은 첫 번째 열의 문제 설명과 관련이 없습니다. 예를 들어 함수 구성은 상태 구조를 이해하기 어렵게 만들고 변경 사항

— Ski

당신이 FP를 선호하는 것 같지만, 내 생각에 당신의 대답은 그것이 하나님의 대상이라는 느낌을 확인시켜줍니다. OMG와 마찬가지로 주 전체는 매우 복잡합니다. 왜냐하면 전체 프로그램의 전체 상태를 하나의 큰 것으로 취급하기 때문입니다. 예, 복잡합니다. OOP에는 업데이트되지 않은 논리적 객체 모델이 있습니다. 그것이 동시에 발생하면 그것도 괜찮습니다. 뷰는 객체의 상태를 반영하며 실제로는 매우 간단합니다.

— n13

첫 페이지는 Redux가 단일 페이지 웹 앱과 관련된 문제를 해결한다는 것을 명확하게 보여줍니다.

JavaScript 단일 페이지 응용 프로그램에 대한 요구 사항이 점점 복잡해지면서 코드는 그 어느 때보 다 많은 상태를 관리해야합니다. (Redux에서-동기 부여)

내 자신의 번역은 웹 응용 프로그램과 웹 응용 프로그램을 만들기위한 프레임 워크가 지저분하고 브라우저에서 실행되면서 웹 응용 프로그램 외부에서는 발생하지 않는 고유 한 문제에 직면 해 있습니다.

잘못 이해하지 마십시오. 웹 앱이 나쁘거나 프레임 워크가 나쁘다는 말은 아닙니다. 웹 페이지와 그에 대한 전체 패러다임은 결코 응용 프로그램을 염두에두고 설계되지 않았습니다. 일부 웹 앱은 놀랍도록 잘 작동합니다. 예를 들어 Google 문서를 좋아합니다. 기본 앱보다 더 좋습니다.

그러나 Redux는 브라우저에서 실행되는 웹 응용 프로그램을 만들 때 발생하는 제한 사항과 문제를 처리해야 할 때 발생하는 문제를 관리하는 도구 일뿐입니다.

iOS 앱 또는 모든 종류의 기본 앱의 경우 의미가 없습니다. 객체 모델은 비동기 변경 및 사용자 상호 작용을 쉽게 처리합니다. 당신은 항상 무슨 일이 일어나고 있는지 알 수 있습니다. 다른 상태를 렌더링하는 것은 문제가되지 않으며 MVC 및 업데이트 이벤트로 자동화됩니다.

웹 앱과 같은 상황에 처한 적이 없습니다.

** 아키텍처가 나쁘면 Redux조차도 아무것도 당신을 구할 수 없습니다.)

— n13
소스