CoC - Convention over Configuration

 개발자가 내려야할 수 많은 결정들(decisions)을 줄여주어, 단순성(simplicity)을 확보하면서, 유연성(flexibility)을 잃어버리지 않도록 하기 위한 소프트웨어 디자인 패러다임


 CoC의 단어상의 근본적인 의미는 개발자는 단지 어플리케이션에서 관습적이지않은 면(unconventional aspects of the application)만 정의할 필요가 있다는 것입니다. 예를들어 Model에 Sale이란 클래스가 있다면, 데이터베이스 내에 대응하는 테이블은 기본적으로 sales라고 불리운다라는 관례(convention)가 있다면, 모든 데이터베이스에 테이블을 생성할때 테이블 명을 관례에 따라 작성한다면 자연스럽게 모델에 대응될 것입니다. 만약 이 관례에 벗어나는 테이블인 products_sold와 같은 테이블이 있는 경우에만, 개발자들은 이러한 테이블 명에 대응하는 코드를 작성할 필요가 있다는 것입니다.


 여러분이 원하는 기능들에 일치하는 관례에 따라 툴에 의하여 개발한다면, 여러분들은 설정 파일을 작성할 필요없이 이러한 장점들을 누릴 수 있는 것입니다.

 하지만, 이러한 공통의 관례는 모두가 알고 있어야 한다는 점을 주의하여야 합니다.
 즉 공통 부분을 책임지시는 분들의 경우 CoC 기반의 개발을 지원하고 계신다면, 공통 프레임웍이나 유틸리티 뿐만 아니라 개발자들에게 공통의 개발 관례까지 지원하여야 합니다. 만약 관례를 벗어나는 개발을 하는 경우에 공통된 관례를 따르지 않으므로, 공통의 관례를 따를 때 자동으로 지원하였던 트랜잭션 처리, 로깅 등의 처리를 개별적으로 처리할 수 있는 방안까지 마련해주어야 하며, 이를 최소화 할 수 있도록 개발자들에게 공통의 관례에 대한 이해를 높일 수 있도록 지속적으로 교육을 할 필요가 있습니다.

 CoC는 실질적으로 추상화 레이어를 생성하지 않고도 높은 수준의 추상화 작업을 프로그래머들이 할 수 있도록 지원하는 프로그래밍적인 접근 방식이며, 수 많은 설정들에서 프로그래머들을 해방시켜줍니다.


CoC의 동기
 전통적으로, 프레임웍은 여러 다중 설정 파일들을 필요로하며, 각 설정 파일은 많은 설정들을 포함하고 있습니다. 이러한 설정 파일들은 각 프로젝트에 맞는 특정한 정보를 제공하며, 이러한 설정의 범위는 URL에서부터 클래스들과 데이터베이스 테이블 사이의 매핑까지입니다. 즉 엄청나게 다양할 수 있다는 의미입니다. 어플리케이션의 복잡도에 따라 이러한 설정 파일들의 수와 크기는 매우 쉽게 늘어납니다. 이에따라 설정의 방법도 복잡해지며, 이러한 설정을 개발자가 일일이 하여야 하기 때문에 개발의 속도는 감소되며, 개발의 복잡도는 증가하게 됩니다.

 예를들어, 잘 알려진 자바 영속성 매퍼(Java persistence mapper)인 Hibernate의 이전 버전의 경우, 엔티티들을 엔티티에 대응하는 데이터베이스의 필드를 연결시키기 위하여 XML 파일 안에 각 관계를 기술하여야 하였습니다. 클래스(class) 명은 데이터베이스의 테이블(table) 명 같으며, 필드(field) 명은 컬럼(column)과 각각 같도록 관례적으로 표현하였기 때문에 대부분의 정보는 이러한 정보들을 가지고 있었습니다. CoC를 채용한 이후의 버전에서 이러한 XML 설정 파일들 대신 많은 관례(convention)들을 채용하였으며, 자바의 어노테이션을 사용하여 이러한 변화를 수용하였습니다.


활용
 대부분의 현대적인 프레임웍에서는 CoC적인 접근방법을 사용하고 있습니다.
CoC는 현재 Ruby on Rails, Zend Framework, Grails, Spring, Castle MonoRail, JUnit, JBoss Seam, CakePHP, symfony 와 Kohana에 포함되어 있습니다.



참고 사이트
- http://softwareengineering.vazexqi.com/files/pattern.html