기능 "정상화"

다음은 DB 정규화 이론 개념의 : 키가 아닌 필드가 다른 키가 아닌 필드에 대한 사실 인 경우기능 "정상화"

3 정규형을 위반된다.

비슷한 개념을 함수/함수 매개 변수에 적용하면 이해가되지 않습니까? 세번째 매개 변수는 상기 제 설명없이 제 향해 '자세'가있는 것,이 예 함수

function validate(field, rule_name, rule_value); 

// Usage 

validate("password", "min_length", 6); 
validate("password", "matches_regex", "/^\S+$/");

는 다음의 기능을 고려한다. 그것은 어떤면에서 비정규 화 된 함수처럼 느껴집니다.

제가이 권리를 공식화할지 모르겠지만 테이블 이름과 테이블 필드, DB 및 함수 이름과 함수 매개 변수를 유추 할 수 있습니다.

만약 그러한 비유가 합리적이라면, 함수 설계자가 DB 정규화 이론으로부터 개념을 빌려 오는 것도 의미가 없습니까?

출처

2011-02-28 Emanuil Rusev

이 함수는 값에 의해 매개 변수화 된 일종의 "규칙"개념을 제안합니다. 그러한 규칙/값 쌍의 목록을 갖고 모든 규칙을 반복함으로써 유효성을 검사 할 수 있다면 좀 더 일반적으로 만들 수 있습니다. 전략 디자인 패턴을 사용하는 경우

function validate(field, rule); 

// Usage 

validate("password", MinLengthRule(6)); 
validate("password", RegExRule("/^\S+$/"));

출처

2011-02-28 16:50:25

저는이 기능을 게시 한 것을 매우 기쁘게 생각합니다. 지금은 기능에 문제가 있다고 생각하는 것이 아니라는 사실을 알고 있기 때문입니다. 그래도 기분이 좋지 않은가? 어떤 규칙을 위반합니까? –

@Emanuil 원래 기능이 분리 문제를 위반하는 경우 : @ MadKeithV의 메서드는'validate' 함수에 실제 유효성 검사 동작을 삽입 할 수있게하여 재사용 성을 높입니다. 주어진 간단한 예제를 사용하더라도 원본은 여러 데이터 유형에 대한 규칙을 수용하기 위해 다중 서명이 필요합니다. –

@djacobson - 네, 고마워요. 그건 실제로 내 마음 속에있었습니다. 유효성 검사는 하나의 서명을 갖는 단일 함수가되며 "규칙"은 "필드"문자열을 처리하고 문자열이 유효성 검사를 통과하는지 여부를 나타내는 부울 값을 반환하도록 쉽게 확장 될 수있는 추상화가됩니다. –

동의하지 마십시오. 6에는 min_length이 나와 있지 않습니다. 오직 둘 다 의미있는 것을 만듭니다.

가비지 문자는 정규식이라는 것을 알기 전까지는 아무 것도 의미하지 않습니다.

출처

2011-02-28 16:10:37

'규칙 이름'과 '규칙 _ 값'은 특별한 관계가 있습니다. 'rule_value' 해석 방법은'rule_name'의 값에 의해 결정됩니다. 보시다시피 값은 첫 번째 사용 예제에서는 int이고 두 번째 예제에서는 정규식입니다. –

이 예를 들어,의 OOP의 변형을 고려 : 다음과 같이 기능을 해석하는 경우에 다른 방법을 찾고

은 아무것도 손실 될 것 같다. 이 경우 규칙 이름이 Rule 클래스의 속성으로 자연 스럽다 (적어도 나에게). 이는 아이디어를 뒷받침합니다.

출처

2011-02-28 17:27:47 Raedwald

그것은 주제에 대해 매우 흥미로운 각도입니다. –

@MadKeithV는 규칙 객체의 사용도 고려합니다. – Raedwald

기능 "정상화"

답변

관련 문제