데이터베이스 프로그래밍에는 저장하려는 데이터에 대해 "정규화"라는 기술이 있습니다.

누구든지이 개념을 객체 디자인에 적용하려고 했습니까? 어떻게 지냈어? 어떻게 작동 했습니까?

편집 : 확장 / 명확하게하기 위해 데이터베이스 정규화는 중복을 줄이는 원칙 이상의 것입니다. 실제로 진행하는 단계와 단계가 있으며 현재 어느 단계에 있는지 알려주는 객관적인 조치가 있습니다. 개체 디자인에는 고유 한 원리가 있으며 냄새의 개념이 있지만 비슷한 말을 할 수있는 방법이 있습니까? XX-form0,1,2 ... etc ... 및 다음 "정규화 된"레벨로 이동하는 방법에 있습니까?

데이터베이스 표준화를 추진하는 근본적인 긴장은 OO 시스템에 존재하지 않지만 그 중 일부는 존재합니다. 이들은 최소한 OO 시스템이 관계형 데이터베이스와 유사하기 때문에 표준화와 유사한 방식으로 OO 디자인 패턴과 원칙을 발생 시켰습니다. 예를 들면 다음과 같습니다.

• 단일 책임 원칙
• 우려의 분리
• 한 번만 , 일명 드라이

즉, 누구나 데이터베이스 표준화 기술을 OOP에 적용하려고 했습니까? 아니요. OOP에는 관계형 데이터베이스의 정규화로 해결되는 공유 문제에 대한 솔루션이 이미 있습니다.

예, 그래요

나는이 주제에 대해 오랫동안 조용히 해왔다. 말할 시간이야

• 누구든지이 개념을 객체 디자인에 적용하려고 했습니까?

예. 저는 20 년 이상 객체 정규화 (따라서 기본 객체 지향 이론)를 공식화하는 작업을 해왔습니다.

• 어떻게 지냈어?

최소한 이론적으로는 데이터와 코드가 상호 교환 가능하다는 것을 인식함으로써. 이는 정규화 원칙과 관계 연산이 코드뿐만 아니라 데이터에도 적용될 수 있음을 의미합니다.

• 어떻게 작동 했습니까?

지금까지는 잘 작동했습니다. 얻은 통찰력은 디자인, 분석 및 리팩토링 능력의 "비밀 무기"였습니다.

나는 결국 연구를 끝내고 내재 된 도구를 스스로 만들 시간을 가질 것이라고 생각했기 때문에 이것에 대해 공개적으로 언급하지 않았습니다.

그러나 나는 인생에서 일어나고있는 모든 일이 더 중요하고, 더 재미 있고, 그리고 더 수익성이 높기 때문에, 스스로 연구를 마칠 시간이 없을 것이라는 결론에 도달했습니다. 이제까지. 또한 작업을 혼자 완료하는 데 필요한 CS 이론적 기초가 단순히 없을 가능성도 있습니다.

나는 지역 대학에서 원인을 받아들이려면 박사 후보자를 후원하는 것에 대해 문의했지만, 우리 지역 대학은 프로그래밍 언어 의미론에 대한 적절한 기초를 가르치지 않습니다.

이 분야에 대한 흥미로운 연구가 있었지만, 내가 알고있는 모든 것이 그 점수에 미치지 못했습니다. 정규화가 관계형 배경에서 비롯되어 객체 지향 모델에 적용되지 않거나 정규화가 객체에 의해 정의 된 데이터에만 적용되는 것으로 잘못 가정합니다. 그러나 매우 흥미로운 니어 미스 프로젝트가 있습니다 ...

정말 흥미로운 것은 코드에 정규화를 적용 할 때 발생합니다. 모든 리팩토링 의 기초입니다. . .

그래서 지금해야 할 가장 좋은 일은 DC의 DevDays 2011에서 발언 해달라고 요청함으로써이 단어에 흥미를 느끼는 커뮤니티가 있는지 알아내는 것입니다.

살짝 살펴보기 : 정규화는 무언가를 최소화하고 비 중복으로 만드는 과정입니다. 따라서 객체 지향 프로그래밍의 DRY (Do n't Repeat Yourself) 원칙은 정규화 목표를 분명히 나타냅니다. 잘 알려진 모든 객체 지향 디자인 / 프로그래밍 / 리팩토링 원칙이 객체 정규화의 논리적 결과임을 보여줄 수 있다고 생각합니다. 또한 리팩토링보다 ONF (Object Normal Form)의 시스템으로 수행 할 수있는 더 흥미로운 작업이 있음을 보여줄 수 있다고 생각합니다.

이것은 Rein Henrichs의 훌륭한 답변 에 대한 의견으로 시작 되었지만 너무 길었습니다 ...

정규화는 관계형 데이터에 적용됩니다. 중복을 피하는 데 사용되므로 각 데이텀이 한 곳에만 저장되므로 데이터 무결성을보다 쉽게 ​​보장 할 수 있습니다. 정규화 된 양식의 위반을 찾아서 수정하여 데이터베이스를 정규화합니다.

객체 지향 프로그래밍은 데이터 작업에 적용됩니다. 데이터를 조작하는 방법을 그룹화하기위한 것입니다. 작업이 조작하거나 의존하는 데이터를 살펴보면 중복 메서드를 제거하기 위해 비슷한 기술을 클래스에 적용 할 수 있습니다. 예를 들어, OO Perspective의 1NF는 클래스 내에 중복 조작이 없습니다. 3NF는 일반적으로 사용되는 코드가 수퍼 클래스에있는 우수한 상속 구조에 해당 할 수 있습니다. 거기에 의존성 주입에 적합한 장소를 찾을 수 있다고 확신합니다. 좋은 디자인 원칙과 리팩토링을 위반하면 더 나은 디자인에 도달 할 수 있습니다 (일반적인 형태는 아직 발견되지는 않았지만).

어느 쪽 세상에서나 좋은 디자인에 도달하는 알고리즘 방법은 없습니다. Rein Hendrichs가 지적했듯이 잠재적 문제 (일명 코드 냄새)를 식별 할 수있는 많은 원칙이 있습니다. 디자인 패턴과 모범 사례는 사람들이이를 해결하려는 몇 가지 방법입니다. 테스트 중심 개발은 외부에서 코드를 실행하여 코드를 조기에 찾으려고합니다. 데이터베이스 개발과 마찬가지로 경험과 분석을 통해 최상의 솔루션을 찾을 수 있습니다.

정규화와 유사한 비즈니스 모델 개체를 디자인하는 매우 좋은 방법은 UML 모델링 (컬러)입니다 입니다.

Peter Coad가 비즈니스 모델 개체를 추상화하는 데 도움이되는 디자인 전략입니다.

불행히도이 책 -UML을 사용한 색상의 Java 모델링 : 엔터프라이즈 구성 요소 및 프로세스 은 매진되었으며 사용한 것만 구입할 수 있습니다.

이 기술에 대한 인터넷 기사가 몇 개 있습니다.

관계형 디자인에 익숙한 경우 UML 모델링 (컬러) 이 다음을 안내하는 데 유용합니다.

• Peter Coad의 '색상 모델링'-Stephen R. Palmer의 노트

클래스 다이어그램을 작성하는 동안 코드에서 ORM java 어노테이션을 사용하도록 조사 했습니까? 모델링 단계가 완료되면 최대 절전 모드가 데이터베이스를 생성합니다. 이 예제에서 다이어그램은 코드 뷰어 일뿐입니다.

객체 참조 또는 포인터는 외래 키와 유사합니다. 내가 이것에 대해 생각하고 싶은만큼 깊다. :)

실제로 나는 더 깊이 생각할 것이다. 데이터 복제가 0 인 객체를 모델링하고 객체를 "쿼리"하고 세트 기반 업데이트를 수행 할 수있는 경우 연결이 끊어지지 않습니다. 실제로 객체 소비자 라이브러리를 만들어이 작업을 수행 할 수 있습니다. Microsoft는 이미이 기능을 사용하고 있지만 "쿼리 라이브러리"를 통해 C #의 집합 기반 LINQ 구문을 만드는 방향으로 나아갔습니다.