대상의 자치와 행위의 확장과 적합

나쁜 디자인에서 데이터는 종종 분산되고 심지어 난잡하다. 이것은 마치 의식을 잃은 맹수들처럼 우리는 그것들을 통제하고 조율하며 관리할 수 없다.이런 두서없는 산란 데이터는 맹수의 제멋대로 행동하는 것과 같이 시스템에 끝없는 재난을 가져올 것이다.시스템이 진화함에 따라 이런 재난은 점차 시스템의 구석구석으로 번질 것이다.따라서 대상을 대상으로 설계하는 과정에서 데이터 분류는 대상을 식별하는 전제 조건이다.그러나 데이터를 봉인한 대상만 있고 데이터를 조작하는 행위가 없으면 여전히 무의식적인 사망 대상이다.
대상자는 자신의 데이터를 가진 상태에서 자치적이어야 한다고 시종 생각한다.이런'자치'는 SOA에서 서비스 자치의 개념과 유사하지만 대상이 충분한 합리적인 세립도를 유지해야 하기 때문에 이런 자치는 유한한 자치이다.전문가의 자치를 보여준다고 할 수도 있다.만약에 대상이 충분한 데이터 정보를 가지고 있다면 반드시 이런 정보의 권위를 세워야 한다. 이런 정보의 처리는 반드시 대상 자신이 해야 한다.만약 그것이 가지고 있는 정보량이 부족하거나 전혀 갖추지 못하면 다른 대상에게 위임할 수 있다.이때 행위는 대상의 의식이고 대상이 자치할 수 있는 전제 조건이다.
대상 자치는 대상을 대상으로 설계하는 중요한 원칙인 대상의 데이터와 행위가 함께 봉인되어야 한다는 것에 의존한다.Craig Larman이 제시한'정보 전문가 모델'이 바로 이 점을 설명하는데, 이 모델은 정보를 가진 대상이야말로 이런 정보를 처리하는 전문가라고 주장한다.
대상 자치는 매우 흥미로운 개념이다. 우리는 대상을 의인화하여 대상을 지역사회를 구성하는 기본 요소로 만든다.이 지역사회에서 모든 대상의 행동은 스스로 통제해야 한다.어떤 조작을 완성하든지 요청을 하든지 이벤트에 응답하든지 대상은 반드시 자신의 판단을 해야 한다.판단의 합리성은 그것이 파악하는 정보량과 우리가 부여한 의식의 영성에서 나온다.소프트웨어 시스템을 구축할 때 우리의 목표는 무질서한 혼돈의 세계가 아니라 자치 대상으로 구성된 지역사회를 구축하는 것이다.우리가 데이터를 조작할 때마다 데이터가 발산, 혼란, 모호, 만연 등 특징을 가지기 시작할 때 바로 데이터를 봉인하는 신호이다.이러한 데이터의 수량이든 크기든 모두 시스템에 대상으로 존재해야 하며 이 대상은 이 데이터를 조작하는 능력을 갖추어야 한다.
예를 들어 보고서 시스템에서 우리는 구축된 보고서를 전체적으로 Excel 파일로 내보내려고 한다.내보내기 기능을 위해 보고서 객체와 워크시트 객체를 수신하여 보고서를 Excel 파일로 내보내는 전용 인터페이스 ExcelTableExporter를 정의했습니다.

   
   
   
   

    
    
    
    public
    
    
    
     
    
    
    
    interface
    
    
    
     ExcelTableExporter {
    
    
    
    
    public
    
    
    
     
    
    
    
    void
    
    
    
     export(ReportTable table, WritableWorkbook workbook);
}
   
   
   
   

이 인터페이스의 정의는 결코 타당하지 않은 점이 없다.그러나 우리가 export () 인터페이스 방법을 실현할 때, 일은 통제하기 어려워지기 시작한다.우리는 export () 방법에서 전체 보고서를 훑어보고 보고서의 줄, 열, 데이터 칸을 얻어서 좌표를 계산하고, 그 형식을 얻어서 Excel 칸에 써야 한다.분명히 Excel Table Exporter는 할 일이 너무 많고, 처리할 보고서 데이터도 혼란스러워지기 시작했다.비록 우리는 보고서에 대해 합리적인 분해와 봉인을 진행했지만 좌표는 여전히 어지럽고 격식도 보고서 대상과 함께 봉인하지 않았다.보고서를 구성하는 요소 대상은 보여주는 데이터 값만 가지고 있을 뿐 자신이 어느 위치에 두어야 할지, 어떤 모습으로 보여야 할지 모른다.다시 말하면 보고서를 구성하는 대상들이 충분한 자율의식을 갖추지 못해 이들을 조작하는 Excel Table Exporter의 심력을 초췌하게 만든다는 것이다.이것은 모든 보고서 요소 대상의 데이터, 요소 간의 의존 관계를 관찰하고 그들의 좌표를 어떻게 계산하여 고객의 요구에 부합되는 형식을 얻는지 고려해야 한다.만약에 우리가 이러한 보고서를 보여주고 내보내는 기능을 보고서 데이터를 Excel 화보에 그리는 것으로 간주한다면 Excel Table Exporter는 그다지 현명하지 않은 화사처럼 전체적인 통제와 세부적인 묘사에 바쁘지만 능력이 부족하여 양자를 함께 돌볼 수 없다.만약 우리가 보고서를 구성하는 원소 대상에게 자신을 그리는 능력을 가지게 한다면 상황은 새롭게 바뀔 수 있을까?이때 Excel Table Exporter는 원소 대상을 꺼내 Excel 캔버스 위에 놓으면 어디로 가야 할지, 어떻게 그려야 할지 스스로 알 수 있어 Excel Table Exporter가 신경 쓸 필요가 없다.
단일직책원칙(SRP)에 따르면 보고서 요소의 대상은 보고서와 직접적으로 관련되어 그 자체가 그리는 책임을 져서는 안 되지만 보고서를 내보내는 장면에 놓아 보면 도리에 맞는 것이다.그리고 그리기와 관련된 데이터 자체는 보고서 데이터와 직접적으로 관련이 있다. 예를 들어 보고서 요소의 좌표는 보고서 데이터의 개수에 의존하여 그것이 차지하는 행수와 열을 결정한다.보고서의 양식도 마찬가지로 보고서 메타데이터에 설정되어 있다.그러나 추상적인 측면에서 볼 때 우리는 이를 위해 서로 다른 인터페이스를 정의해야 한다. 이것도 인터페이스 격리 원칙(ISP)에 부합된다.동시에, 우리는 그리는 행위의 확장을 고려해야 한다.예를 들어, 미래에 우리는 보고서를 HTML 페이지로 그리는 것을 고려해야 할 수도 있다.따라서 드로잉 요소의 인터페이스를 정의할 수 있습니다.

   
   
   
   

    
    
    
    public
    
    
    
     
    
    
    
    interface
    
    
    
     DrawingElement {
    
    
    
    
    public
    
    
    
     
    
    
    
    void
    
    
    
     draw(ReportCanvas canvas);
    
    
    
    
    public
    
    
    
     
    
    
    
    object
    
    
    
     getElement();
}
   
   
   
   

draw() 메서드는 보고서 요소를 ReportCanvas 객체로 그립니다.ReportCanvas는 그려진 보고서 요소를 캐리어로 추가하는'캔버스'의 은유를 구현했다.

   
   
   
   

    
    
    
    public
    
    
    
     
    
    
    
    interface
    
    
    
     ReportCanvas {
    
    
    
    
    public
    
    
    
     
    
    
    
    void
    
    
    
     addElement(DrawingElement element);
}
   
   
   
   

Excel의 경우 draw()를 구현하는 방법은 내부에 셀 객체를 작성하는 것입니다.만약 소스 프로젝트 jxl을 사용하여 excel 파일의 생성을 완성한다면, 이 칸의 대상은 Label 대상일 수도 있고, jxl일 수도 있습니다.write.Number 객체그러나 ReportCanvas는 이런 것에 관심이 없다. Drawing Element만 추가하면 된다.여기에 추상적인 Drawing Element의 장점이 나타난다.보고서 요소 객체가 인터페이스를 구현할 때 Excel을 내보내는 경우 Label 및 Number 같은 셀 객체를 구현 클래스로 캡슐화할 수 있습니다.예를 들어, 보고서의 행 헤더 객체는 DrawingElement 인터페이스를 사용할 수 있습니다.

   
   
   
   

    
    
    
    public
    
    
    
     
    
    
    
    class
    
    
    
     RowHeaderExcelElement implements DrawingElment{
    
    
    
    
    private
    
    
    
     
    
    
    
    object
    
    
    
     cell;

    @Override
    
    
    
    
    public
    
    
    
     
    
    
    
    void
    
    
    
     draw(ReportCanvas canvas) {
        canvas.addElement(
    
    
    
    this
    
    
    
    );
    }

    @Override
    
    
    
    
    public
    
    
    
     
    
    
    
    object
    
    
    
     getElement() {
        
    
    
    
    if
    
    
    
     (isNumber()) {
            cell 
    
    
    
    =
    
    
    
     createNumberCell();
        } 
    
    
    
    else
    
    
    
     {
            cell 
    
    
    
    =
    
    
    
     createLabelCell(); 
        }
        
    
    
    
    return
    
    
    
     cell;
    }
}
   
   
   
   

만약 앞으로 Html을 지원할 필요가 있다면, RowHeaderHtmlElement 클래스를 정의하여 DrawingElement 인터페이스를 실현할 수 있습니다.만약 양자 사이에 공통된 논리가 존재한다면 공통된 기본 클래스인 RowHeaderElementBase를 추출할 수 있습니다.
DrawingElement 인터페이스가 도입되면서 보고서 요소 대상은 그리는 요소 대상의 데이터와 행위를 모두 봉하여 자치의 대상이 되었다.보고서 요소 객체 자체에 드로잉 기능이 있으므로 ExcelTableExporter는 드로잉 요청만 보내면 손쉽게 작업을 수행할 수 있습니다.

   
   
   
   

    
    
    
    for
    
    
    
     (DrawingElement element : table.getReportUnits()) {
    element.draw(canvas);
}
   
   
   
   

실현에 있어서 우리는 또 해결해야 할 문제가 하나 있다.Excel Table Exporter의 export () 방법은 jxl, Drawing Element 클래스로 봉인된 레이블이나 Number 대상을 사실상 jxl의 Writable Sheet에 그려야 하며, 우리의 추상적인 ReportCanvas가 아니라 jxl의 Writable Sheet에 그려야 한다.DrawingElment 인터페이스의 추상성과 미래의 확장성을 확보하기 위해 draw() 방법의 입력 매개 변수는 실현과 무관한 추상적인 유형이어야 한다.수정 방법이 Writable Sheet 객체를 수락하는 것으로 정의되면 jxl로 한정되어 쉽게 변경할 수 없으며 이것은 절대 바람직하지 않습니다.그것은 공급업체 귀속의 반모드에 위배된다.
Writable Sheet 객체가 ReportCanvas와 아무런 관계가 없기 때문에 강제적인 유형 변환도 Writable Sheet 객체를 Drawing Element 객체에 전달하는 draw() 방법을 보장할 수 없습니다.Writable Sheet의 정의를 수정하여 ReportCanvas 인터페이스를 구현하지 않는 한그러나 이것은 불가능하다. 왜냐하면 Writable Sheet은 제3자가 제공하는 공개 인터페이스이기 때문에 우리는 수정할 수 없다.이럴 때는 양자 간의 적합을 고려해야 한다.Adapter 모드를 사용하면 ReportCanvas 인터페이스를 실현하고 Writable Sheet이 제공하는 직책을 다시 사용할 수 있는 간접 대상 Writable Sheet Adapter를 도입할 수 있습니다.jxl에서 Writable Sheet은 인터페이스로 정의되어 Writable Workbook을 통해 생성됩니다.따라서 Writable Workbook에서 만든 객체를 Writable SheetAdapter에게 전달하는 방법을 고려할 수 있습니다.

   
   
   
   

    
    
    
    public
    
    
    
     
    
    
    
    class
    
    
    
     WritableSheetAdapter implements ReportCanvas {
    
    
    
    
    private
    
    
    
     WritableSheet sheet;
    
    
    
    
    public
    
    
    
     WritableSheetAdapter(WritableSheet sheet) {
        
    
    
    
    this
    
    
    
    .sheet 
    
    
    
    =
    
    
    
     sheet;
    }
    @Override
    
    
    
    
    public
    
    
    
     
    
    
    
    void
    
    
    
     addElement(DrawingElement element) {
        sheet.addCell((WritableCell)element.getElement());
    }
}
   
   
   
   

Writable Sheet Adapter는 ReportCanvas 인터페이스를 실현하는 동시에 Writable Sheet 대상을 조합하여 Writable Sheet에서 ReportCanvas로의 어울림을 완성하여 Drawing Element 대상이 그것을 받아들일 수 있도록 한다.

   
   
   
   

    
    
    
    WritableSheet sheet 
    
    
    
    =
    
    
    
     workbook.createSheet(sheetName, 
    
    
    
    0
    
    
    
    );
WritableSheetAdapter sheetAdapter 
    
    
    
    =
    
    
    
     
    
    
    
    new
    
    
    
     WritableSheetAdapter(sheet);


    
    
    
    //
    
    
    
     ， 
    
    
    
    

    
    
    
    for
    
    
    
     (DrawingElement element : table.getCellGroups()) {
    element.draw(sheetAdapter);
}