트레이트 – 01.문서 출처 및 용어 정리

문서 출처

용어 정리

behavior, behavioral

객체지향 프로그래밍에서 behavior는 주로 행위 또는 비헤이비어라고 번역되고 있으며, 의미에 따라 행동, 동작 등으로 표기되기도 합니다. 이 문서에서는 behavior라는 용어가 대부분 메소드와 관련되어 나타나고 있고, 그 내용을 쉽게 이해할 수 있도록 가능한 동작으로 번역하여 표기하며, 동작 이상의 의미를 내포하고 있을 때는 행위라고 표기하겠습니다.

insert traits into a class

PHP 매뉴얼에 insert traits into a class, the combination of Traits and classes, RFC 문서 horizontal reuse에 the classes composed from traits, classes build using traits, RFC 문서 nonbreakable traits에 the scope of the including class 라는 문장에서 보여주듯이 use 문을 이용하여 트레이트를 클래스에 삽입(insert)하는 과정을 combine, compose, build, include 등 다양한 용어로 표현하고 있습니다. 이 문서에서는 트레이트를 use 문으로 클래스에 삽입(insert)하는 행위를 조합한다라고, 그 상태를 조합이라고 표현하겠습니다.

조합(組合)하다의 의미 ① 여럿을 한데 모아 한 덩어리로 짜다. ② 여러 개 가운데에서 몇 개를 순서에 관계없이 한 쌍으로 뽑아내어 모으다. 가령 a, b, c 셋 가운데서 두 개씩 뽑아 모은 조합은 ab, bc, ca의 세 가지이다. (출처: 국립국어원 우리말샘)

insert vs. import

이 용어들은 사용되는 위치와 목적 등에 따라 해석이 달라질 수 있음을 염두에 두고, 제한적 의미에서 정리합니다.

css, javascript에서 import란 외부 모듈(스타일 규칙, js 라이브러리)을 내 문서(파일)로 불러오는 행위를 의미하며, PHP의 네임스페이스에서 import란 외부의 네임스페이스라는 가상 공간을 공유할 목적으로 내 문서로 불러옴으로 동일 공간으로서 클래스, 인터페이스, 트레이트 등을 직접 참조할 수 있도록 하는 행위를 의미합니다.

JAVA에서 import문의 역할은 컴파일러에게 소스 파일에 사용된 클래스의 패키지에 대한 정보를 제공하여, 컴파일할 때 클래스 이름 앞에 패키지 이름을 붙여 줍니다. JAVA 소스 파일에서 import문은 package문 다음에, 그리고 클래스를 선언하기 전에 선언하여야 합니다.

반면에, PHP에서 클래스에 트레이트를 insert하는 행위는 클래스 정의 내에서 트레이트를 복사하여 클래스에 붙여넣기하는 것과 같이 원하는 위치에 직접 집어넣는 행위를 의미합니다.

개인적인 견해는 각자 다를 수 있겠지만, 문서 차원(전역 스코프라고 할 수 있음)에서 외부 문서를 내 문서에 불러오는 (가상) 행위를 insert라고 표현하는 것도 부적절한 것 같고, 클래스 차원(지역 스코프라고 할 수 있음)에서 클래스에 트레이트를 집어 넣는 행위를 import라고 표현하는 것도 부적절하게 보입니다. 이에 따라 이 문서에서 트레이트는 insert(조합하다)로, 네임스페이스는 import(임포트)로 구별하여 표현하겠습니다.

exhibiting class

PHP 매뉴얼의 트레이트 섹션에 2번 나타나는 용어입니다. 일반적으로 exhibit가 미술관에 그림을 전시하다와 같이 전시하다, 전람하다, 출품하다, 진열하다, 공개하다라는 의미입니다. 개인적인 생각이지만, exhibiting class라는 용어는 여러 개의 트레이트들이 클래스의 use 문(statement)에 나열(listing), 즉 진열(exhibiting)되어 있는 모습을 상상케 합니다. 이러한 의미로 쓰여진 것이라면 exhibiting class란 ‘트레이트가 전시된 클래스’를 의미한다고 할 수 있습니다. 전시(展示)는 펼 전(展) 보일 시(示)로 ‘펼쳐 보이다’라는 뜻입니다.

이러한 exhibiting class를 RFC 문서 horizontal reuse에서는 composed class, RFC 문서 nonbreakable traits에서는 including class, combined class, RFC 문서 abstract trait method validation에서는 using class 라고도 표현하고 있습니다. RFC 문서 nonbreakable traits에서는 현재의 use 문이 아닌 include 문을 이용해 트레이트를 클래스에 조합하고 있었기 때문에 including class라는 용어를 주로 사용하고 있는 것 같습니다.

이 문서에서는 exhibiting class, composed class, including class, combined class, using class 등을 조합 클래스로 표기하겠습니다. 또한 트레이트로 조합된 트레이트(Trait Composed from Trait)를 조합 트레이트라고 표기하겠습니다.

flattening

RFC 문서 nonbreakable traits에 플래튼(flatten)과 플래튼이 아닌 것(don’t flatten)에 대한 개념이 정리되어 있습니다. 이에 따르면 플래트닝(flattening)이란 ‘컴파일 할 때(compile time)에 모든 프로퍼티와 메소드를 플래트닝 속성(flattening property)에 따라 클래스 소스 위치(class definition)에 배치함으로, 실행할 때(runtime)에는 마치 트레이트가 존재하지 않는 것처럼 된다‘는 개념입니다.

RFC 문서 horizontal reuse에 The Flattening Property라는 섹션이 있으며, 이를 설명하는 내용 중에 “They are used to group methods and reuse code and are totally flattened into the classes composed from them.”라는 문장에서 “트레이트(They)는 트레이트(them)를 조합(compose)한 클래스에 플래트닝 된다“고 설명하고 있습니다. 참고로 포토샵에서 모든 레이어를 모아 하나의 레이어로 합치는 것을 Flatten Image라고 합니다.

method

(이하 지극히 개인적인 견해임)

국립국어원에서는 외래어 표기법에 따라 method의 영어 발음 [ˈmeθəd]에 따라 메서드로 표기할 것을 제시하고 있습니다만 외래어 표기법 제1장 제5항에 따르면 “이미 굳어진 외래어는 관용을 존중하되, 그 범위와 용례는 따로 정한다”라고 관용을 허용하고 있습니다. 객체지향 프로그래밍 분야에서는 이미 메소드라는 용어가 가장 많이/폭넓게 통용되고 있는 터라 이를 외래어 표기법에 따른다고 어색하게 메서드라는 용어를 사용해야 하는지는 의문의 여지가 있습니다.

비슷한 예로 method signature에서의 signature의 경우를 보면, 외래어 표기법에 따르면 영어 발음 [sígnǝtʃǝr]를 시그너처로 표기해야 합니다만 그럼에도 불구하고 시그니처로 일통하여 사용되고 있는 것이 현실입니다. 일관성이 없는 것이지요.

외래어 표기법에는 “그 범위와 용례는 따로 정한다”라고 되어 있지만 법에 모든 것을 담을 수는 없습니다. 가능한 외래어 표기법에 따르는 것이 필요하겠지만, [méθǝd] 메소드메서드, [sígnǝtʃǝr] 시그니처시그너처에 따라, 메소드 시그니처 또는 메서드 시그너처로 표기하여, 관용에 따르던가 표기법에 따르던가 통일하는 것이 바람직할 것 같습니다. 부분적으로 따르다 보면 일관성이 없어져 메서드 시그니처와 같은 어색한 경우들이 계속 생길 수밖에 없습니다. 이 문서에서는 관용에 따라 method메소드라고, method signature메소드 시그니처라고 표기하겠습니다.

fine-grained way

소프트웨어 공학에서는 하나의 프로세스를 쪼개는 정도를 표현하기 위하여 fine-grained, coarse-grained라는 용어를 사용하고 있는데, 각각의 원래의 의미는 농업에서 곡물, 곡식을 잘게 쪼개느냐, 굵게 쪼개느냐의 의미 차이를 나타냅니다. 소프트웨어 공학에서 이 용어들을 차용했을 때는 프로세스를 세분화하느냐, 세분화하지 않느냐의 의미 차이입니다. 이 문서에서는 fine-grained way세분화된 방식 정도로 표현하겠습니다.

base class

base class는 파생 클래스(derived class)의 상대 개념으로, 슈퍼 클래스(super class), 부모 클래스(parent class)와 같은 의미입니다. 여기서는 기반 클래스로 표기하겠습니다.

concrete class & method

concrete class는 추상 클래스(abstract class)의 상대 개념으로, 모든 멤버가 구체적으로 구현된 클래스를 의미합니다. 추상(抽象)의 상대 개념이 구상(具象)임을 감안하여 어색하지만 구상 클래스, 구상 메소드로 표기하겠습니다.

signature

메소드 시그니처(method signature)는 메소드의 정의에서 메소드 이름, 매개변수 목록(수량, 자료형)의 조합을 의미하며, 메소드를 다른 메소드와 구분할 수 있게 해 줍니다. 언어에 따라서 반환 값 자료형(return type)을 시그니처의 일부로 보기도 합니다. C++, 자바같은 언어에서는 시그니처 중 매개변수 목록이 다른 동일한 이름의 메소드를 오버로딩할 수 있습니다. 서명으로 번역되기도 하지만 이 문서에서는 시그니처로 표기하겠습니다.

express requirements by abstract methods

추상 메소드는 구현(implementation)없이 하위 클래스에서 준수해야 할 약속(contract), 즉 해당 메소드의 구조와 사용법을 명세(specification)하고 그 명세(specification)에 따라 하위 클래스에서 구현(implementation)할 것을 요구합니다. 트레이트에서 지원하는 추상 메소드도 조합 클래스가 준수해야 할 표준화된 명세(specification) 만을 선언하고, 조합 클래스(exhibiting class)에게 추상 메소드와 약속(contract)한 표준화된 명세(specification)에 따라 구현하도록 요구하게 됩니다.

PHP 매뉴얼의 추상 트레이트 멤버(Abstract Trait Members) 섹션에서는 조합 클래스에 요구하는 표준화된 명세(specification)requirement라는 용어로 표현하고 있습니다. requirement의 사전적 의미로는 요구사항, 요구조건, 요구자격 정도로 번역되겠지만, 이러한 용어들이 추상 트레이트 멤버에서 의미하는 requirement를 대표하는 용어로 사용하기에는 직관성이 부족해 보여서, 이 문서에서는 requirement요구명세(requirements specification)로 표기하고, express requirement요구명세를 나타내다 또는 소스 코드에서의 의미 전달을 위해 요구명세를 선언하다라고 표현하겠습니다. 사실 requirement시그니처(signature)로 표현해도 의미 상 큰 무리는 없으나, 전혀 다른 용어라서 피합니다.

SW프로젝트 수행시 사용자의 요구사항(requirement)을 분석하여, 소프트웨어 시스템이 수행해야 할 모든 기능과 구현상의 제약 조건에 대해 개발자와 관련자가 합의한 후, 그 스펙(specification)에 대한 사항을 정리하여 기록하게 되는데, 이러한 문서를 요구사항 정의서, 요구사항 명세서 또는 요구명세(Requirements Specification)라고 합니다. – “SPRI Insight Repoet 제2018-001호 ‘요구명세(SRS)의 중요성과 제도화 방향’, 소프트웨어정책연구소(SPRI)” 참고

context

컨텍스트(context)의 사전적 의미로는 문맥, 전후관계, 정황 등으로 이해할 수 있으나, 컨텍스트(context)라는 용어는 여러 분야에서 다양한 의미로 사용되고 있으며, 프로그래밍에서 사용할 때도 명쾌하게 그 의미를 규정하기가 쉽지 않습니다. 개인적인 생각으로는 프로그램이 진행되고 있을 때, 진행되고 있는 순간의 실행 상태가 가지고 있는 데이터를 통털어서 컨텍스트(context)라고 하는 것 같습니다. 여기서 순간의 실행 상태를 하나의 독립된 실행 객체로 보고, 순간의 독립된 실행 객체가 받고 처리하고, 다음 과정의 실행 객체에게 넘기게 되는 과정에서 형성되는 순간의 실행 객체가 가지고 있는 데이터의 집합이라고 할 수 있습니다.

자바스크립트에서 실행 컨텍스트(execution context)라는 것은 실행 코드에 제공할 정보들을 모아 놓은 객체, 실행 가능한 코드가 실행되기 위해 필요한 환경 등으로 이해하고 있습니다. 또 다른 곳에서는 컨텍스트를 어떤 객체를 핸들링하기 위한 접근 수단을 의미한다고 해석하고 있습니다.

위키백과에서 프로그래밍 언어에서의 구문(syntax)의 단계를 설명하면서 아래와 같이 세 단계로 구별하고 있습니다.

  • 단어(word) – 문자가 어떻게 토큰을 형성하는 지를 결정하는 어휘적 수준
  • 구(phrase) – 어떻게 토큰이 구를 형성하는 지를 결정하는 문법 수준
  • 컨텍스트(context) – 어느 객체나 변수 이름이 참조하는 지를 결정(형이 유효한지 등)

답글 남기기