간단 하면 서도 효과 적 인 깊이 있 는 디자인 모델

모든 단계 에서 나 는 디자인 모델 에 대해 서로 다른 이 해 를 가지 고 있다.
함수 식 작성 에 대한 사랑 에 따라 관계 형 데이터 베이스 와 문서 형 데이터 베 이 스 를 비교 하면 서 저 는 디자인 모델 에 대해 새로운 느낌 을 가지 게 되 었 습 니 다.
나 는 범례 가 항상 가장 효과 적 인 설명 이 라 고 생각한다. 만약 에 우리 가 한 식당 을 대상 으로 한다 면 (나의 영 어 는 그다지 좋 지 않 으 니 맞 춤 법 을 따 지지 마라):
Eatery (식당 류)
우선 식당 종류 가 하나 생 긴 다음 에 식당 이 제공 하 는 인 터 페 이 스 를 더 하면 식당 이 일 을 할 수 있다.현재, 먼저 제공:

    milk()                    //     
    rice()                    //     

물론 식당 이 설립 된 시간, 도시, 사장, 직원, 가격 도 있어 야 합 니 다. 그래서 다음 과 같은 것 도 추가 해 야 합 니 다.

    build_date             //     
    city                      //     
    boss_a                  //   a
    employee_a           //   a
    employee_b           //   b
    employee_c           //   c
    price_milk              //     
    price_rice              //     
    menu_milk             //     
    menu_rice             //     

또한 손님 이 식당 에 들 어 오 면 가격 을 제시 해 야 하기 때문에 더 해 야 합 니 다.

    get_price()            //       

프로그램 을 만 들 려 면 설립 날짜, 도 시 를 보고 해 야 하기 때문에 더 해 야 합 니 다.

    get_build_date()        //       
    get_city()                 //       
    get_boss()                //         
    get_employee()          //         
    get_price()                //       
    get_menu()               //        

우선 대체로 그 렇 죠. 그래서 사용 할 수 있 는 식당 을 얻 었 습 니 다.

Eatery:

    build_date               //     
    city                        //     
    boss_a                   //   a
    employee_a             //   a
    employee_b             //   b
    employee_c             //   c
    price_milk                //     
    price_rice                //     
    menu_milk               //     
    menu_rice               //     

    get_build_date()       //       
    get_city()                //       
    get_boss()               //         
    get_employee()         //         
    get_price()               //       
    get_menu()              //        

    milk()                      //     
    rice()                      //     

현재 식당 은 이렇게 운영 되 어야 한다.

          get_build_date()

          get_city()

           get_menu()

            get_price()

        milk()

        rice()

지금 은 대상 을 대상 으로 하 든 관계 형 데이터 베 이 스 를 먼저 생각해 보고 식당 의 데이터 베 이 스 를 만 들 려 면 어떻게 초 고 를 해 야 합 니까?

table_eatery:       ，           

    id                           //           
    build_date                //     
    city                        //     

그래 야 되 는 거 아니 야?
우 리 는 항상 기 초 를 유지 하 는 그 표 는 가능 한 한 간단 하고 효율 적 이다.
이 표 는 식당 설립 날짜 와 도시, 그리고 id 번 호 를 통 해 이 식당 을 얻 을 수 있 음 을 알려 준다.
이렇게 많아
식당 주인 을 알 고 싶 으 면 어떻게 합 니까?
간단 하 다
표를 만 들 고 show me the info:

table_boss:

    id
    boss_name
    eatery_id

그 랬 을 거 야.
id 번 호 를 통 해 어떤 사장 님 을 찾 은 다음 에 관련 된 식당 번호 eateryid.
사장 은 틀림없이 어떤 식당 의 사장 일 것 이다.
보스 보스a 당연히 eateryid 번호 이 식당 주인.
더 많은 것 은 우선 토론 하지 않 겠 다.
왜냐하면, 여기,
재 미 있 는 곳 이 이미 나 왔 다.
table_eatery 와 tableboss 는 대상 을 대상 으로 하 는 본질 을 전면적으로 밝 혔 다.
확장 및 연결
우 리 는 먼저 기 초 를 세 웠 다. eatery, 그리고?
우리 가 새로운 것 을 필요 로 할 때, eatery 를 확장 합 니 다.
어떻게 확장 하나 요?
새 표를 만 드 는 것 을 통 해
그 새 표 tableboss 어떻게 tableeatery 연락 은 요?
새로 확 장 된 tableboss eateryid 로 tableeatery。
언뜻 보기 에는 계승 이 아 닐 까?
먼저 tableeatery 대상, 그리고 이 상 대 를 계승 하여 위 에 boss 를 추가 합 니 다.name。
하지만 자세히 살 펴 보면 상속 이 아니 라 는 것 을 알 수 있다.(그리고 상속 이 좋 은 대상 이 아니 라 는 것 을 잘 알 고 있다)
여 기 는 '조합' 입 니 다.
새로운 대상 에 기 존 대상 의 인용 을 넣 고 되 었 다.

objectA   --->    objectB   [  objectA     ]

이러한 유추 로 우 리 는 관계 형 데이터베이스 표 의 구축 을 심화 시 켰 다.
직원 표 만 들 기:

    id
    employee_name
    eatery_id

식당 메뉴 만 들 기:

    id
    menu_item
    menu_price
    eatery_id

...

이것 은 사실 대상 을 향 한 과정 이다.
그래서 프로그램 에 있어 서 이 식당 을 설계 하면 이렇게 대상 을 대상 으로 할 수 있다.

Eatery (build_date, city)

    build_date             //     
    city                      //     
    get_build_date()     //       
    get_city                //       

Boss (eatery)

    name                    //     
    set_name              //     
    get_name              //        

Employee (eatery)

    names                   //       
    add_name              //       
    remove_name         //       
    get_name(i)           //           
    get_names()          //            

Food (name, price)

    name                    //     
    price                    //           
    get_name()           //       
    get_price()           //       

Menu (eatery)

    foods                   //    
    add_food(food)      //    
    remove_food(food) //    
    get_food_price(i)   //          
    get_food_prices     //         
    get_food_names    //         
    get_food_name(i)  //          

Cook (name, food_names)

    name                    //     
    food_names           //         
    get_name()           //        
    get_food_names()  //             
    make(food_name)   //       food_name  

Cooklist (eatery)

    cooks                  //   entery         
    add_cook(cook)     //       
    get_cook_names()  //            
    get_cook_name(i)   //           

OK. 식당 구조 가 끝나 면 지금부터 운영 을 시작 합 니 다.

var entery_pie = new Eatery('2014-5-1', 'Beijing');  // 2014 5 1 ，       pie

entery_pie.get_build_date();  // => 2014-5-1

entery_pie.get_city();  // => Beijing


var boss = new Boss(eatery_pie);  //    pie    

boss.set_name('Tom');  //    Tom

 

var employee = new Employee(eatery_pie);  //    pie    

employee.add_name('Lili');  //   Lili

employee.add_name('Lina');  //   Lina

employee.add_name('Jerry');  //   Jerry

employee.get_names();  // => Lili,Lina,Jerry

employee.get_name(1);  // => Lina

 

var menu = new Menu(eatery_pie);  //    pie    

menu.add_food(new Food('milk', '12.00￥'));  //     12.00￥   

menu.add_food(new Food('rice', '26.00￥'));  //     26.00￥   

menu.get_food_names();  // =>   ,  

menu.get_food_prices();  // => 12.00￥,26.00￥

menu.get_food_name(1);  // =>   

 

var cooklist = new Cooklist(eatery_pie);  //    pie    

cooklist.add_cook(new Cook('Daxiong', ['milk', 'rice', 'tomoto'])); //         、  、      

cooklist.add_cook(new Cook('Xiaoxiao', ['milk', 'rice']));  //         、     

cooklist.get_cook_name(1).make('milk');  // Xiaoxiao       

cooklist.get_cook_name(0).make('tomoto');  // Daxiong        

이것 이 바로 제 가 현재 생각 하 는 대상 을 대상 으로 하 는 것 입 니 다. 더욱 간단 한 모델, 더 많은 확장 과 관련 이 있 습 니 다.
오 랜 시간 전에 제 가 수집 한 정 보 는 가능 한 한 포장 하고 a. get (). method () 의 표현 이 은밀 하지 않다 는 것 을 알려 주 었 습 니 다.
a. get (). nethod () 가 있다 면 가능 한 한 a. method () 로 바 꿔 숨 겨 야 합 니 다.
그러나 지금 나 는 이런 교조 적 인 방법 이 불필요 하고 비효 율 적 이라는 것 을 느 꼈 다.
많은 작은 상 대 를 담 는 것 보다 큰 대상 에 던 져 서 포장 하 는 것 보다 나 는 지금 많은 작은 상 대 를 만 들 고 책임 을 나 누 어 할당 하 는 것 을 더 좋아한다.
여러 가지 측면 에서 볼 때 코드 줄 수 를 간소화 하 는 외관 모델 은 모두 반 모듈 화 되 어 한 대상 으로 만 많은 함 수 를 조종 한다.
사실 밑바닥 은 층 층 이 전달 되 어야 진정 으로 기능 을 실현 할 수 있 는 곳 에 도착 할 수 있다.
이것 은 비효 율 적 이 며, 확장 을 작성 할 때 도 매우 어렵다.
만약 당신 이 충분 한 대상 을 다 썼 다 면, 내용 을 늘 려 야 할 때, 이 대상 의 관련 '체인' 에 대해 속수무책이다.
그리고 흩 어 진 작은 대상 군 은 함수 식 스타일 에 더욱 가 깝 고 소스 대상 의 인용 만 지정 하면 그 를 확장 할 수 있 으 며 계승 이 아 닌 조합 을 사용 할 수 있 습 니 다.
그리고 어떤 면 에서 이것 이 바로 함수 식 이라는 것 을 알 게 될 것 이다.
데이터 구조 Eatery 와 데이터 구 조 를 둘 러 싼 Eatery 함수 군:

eatery

fn1(eatery, arg1, arg2, ...)

fn2(eatery, arg1, arg2, ...)

fn3(eatery, arg1, arg2, ...)

...

장점 은 확장 (기능 증가, 내용 증가, 관련 증가,...) 과 수정 이 매우 쉽다 는 것 이다.
나 쁜 점 은?e............................................................................................
그러나 저 는 좋 은 점 은 절대적 인 것 이 라 고 생각 합 니 다. 왜냐하면 이것 은 함수 의 특성 에 더욱 부합 되 기 때 문 입 니 다.

         ，show me the result

    fn1(eatery_pie, arg1, arg2) =>   pie