메서드, 클래스 명명규칙 어떡하면 좋을까?

http://springmvc.egloos.com/539238

많은 개발자들이 개발 중에 종종 고민하는 "이 메서드명은 뭘로 해야 좋을까?"란 문제는 흡사 직장인들이 "오늘 점심 뭘 먹을까?"와 거의 비슷한…, 또 본의 아니게 심각한 트라우마에 빠질 수도 있는 고민 중 하나이다. 사실 어떻게 보면 별것도 아닌 고민일 수 있는데 한국인인지라 영어도 잘 모르는 상황에서 컴퓨터랑 영어로 대화를 하려니 발생하는 헤프닝일 수도 있겠다.

아마 대부분의 개발자들이 처음에는 구현해야할 기능의 성격이 어느 정도 명확하니까 비교적 단순한 영단어로 get, put, remove…같은 식으로 지어나가곤 한다. 그리고 그렇게 도메인 계층이나 DAO계층을 어느 정도 마무리 짓고 본격적으로 서비스 계층, 서포트 계층으로 올라가려다보면 어느덧 명명규칙의 트랩에 빠지게 되고 사전에 야기했던 본의 아닌 트라우마에 빠지기 시작한다.

예를 들어 메서드를 하나 만드는데 내용이 '클라이언트가 전달 파라미터를 가지고 User 테이블의 인덱스를 검사한 뒤, 그 결과값 바탕으로 다시 Friends 테이블에 검색해서 나온 결과값을 가공하여 뷰가 해석할 수 있는 클래스로 변환한 값을 리턴'한다고 하자. 도대체 이런 해괴망칙한 과정을 거치는 메서드 명은 당신은 뭐라고 지을 것인가?

더욱이 이런 메서드를 한 두개 만드는 것도 아니고 보통 하루에 30~40개 정도의 (어느 정도 의미있는) 메서드를 찍어내고 7~10개 정도의 클래스를 만들어내는 게 프로그래머들이다. 매번 게임 아이디 만드는 것도 아니고 쓸데없는 메서드명 창작에 심혈을 기울이고 싶은 사람은 아무도 없을 것이다.

에다가 심각한 것은 문제가 이게 끝이 아니라는 것이다. 메서드명 짓기도 짜증이 나는데 클래스명 창작은 더욱 난해하고 심오해서 세상에서 가장 어려운 단어 찾기의 게임 속으로 빠져든다. 왜냐하면 보통 클래스명은 많은 의미를 함축하고 있으면서도 명확한 목적을 표현해야 하므로 여러가지 정황을 고려해 지어지는 것이 일반적이다. 예를 들어 AnnotationConfigApplicationContext.class의 이름은 @Configuration 어노테이션으로 설정된 클래스를 ApplicationContext 형태로 가공해주는 클래스인데 스프링 제작자가 이름 짓기 귀찮아 ApplicationContextImpl과 같이 단순히 인터페이스를 구현했다고 가정해보자. 이런 상황에서 작성자는 자신이 만든 클래스의 기능을 속속들이 알고 있지만 사용자는 대개 메서드명만 보고 단순 예측한 상태에서 기능을 사용하기 때문에 자칫 혼란을 가져오는 문제를 발생 시키기도 한다.

그러므로 메서드명과 클래스명에서 발생되는 문제는 개발자 본인에게는 별 것 아닌 문제처럼 치부될 수도 있지만 직접 사용하는 사용자에게는 매우 중요한 역할을 수행하게 되므로 사전에 충분히 작성이 필요한 메서드들을 예측하여 약속된 문법과 단어들을 조합하여 메서드와 클래스를 작성하는 규칙이 필요하다.

그리고 만약에 그럴 사람은 드물겠지만 프로그래밍의 메서드와 클래스명을 짓기 위해 조금이나마 영어공부를 하고 싶다면 on, by, after, before, of…와 같은 단순전치사나 전치사구는 여러모로 프로그래밍 명명규칙에 활용하기 좋은 영단어이므로 콩글리쉬로만 알지 말고 내포하고 있는 다양한 의미를 습득하는 것이 좋다.

앞으로 여기서 나열하는 단어들과 의미는 스프링 프레임워크에서 사용되고 있는 메서드와 클래스 이름의 규칙들이며 가급적 특정한 의미만을 내포하지 않고 규칙적으로 사용되는 단어들을 선별하고자 노력하였다. 그리고 단순히 영어단어의 뜻만이 아니라 프로그래밍 적으로 사용되는 뜻까지 포함할 수 있도록 하였으니 정독만 했다면 독자의 개발과정에 어느 정도 도움이 되리라 본다.

패키지명

패키지명은 하나의 단어만 사용할 것이 권장되며 만약 단어의 길이가 10자를 넘어 가독성에 무리가 간다 판단될 경우에 단어의 앞 3글자만 따서 지을 수도 있다. 항상 하위 패키지는 상위 패키지와 깊은 연관을 맺어야하며 만약 서로 다른 성격의 패키지가 부모 자식 패키지로 설정될 경우 혼동이 올 수가 있다.

사용되는 대표적인 패키지명들

domain (영역, 범위, 소유지) - 단위로 표현할 수 있고 원자성을 띄는 자바빈 클래스, Enum 클래스 등이 위치한다. 다른 곳에서 VO라고 하는 것을 본적이 있는데 필자는 domain이란 이름이 더 마음에 든다.

dao (Data Access Object) - 데이터액세스 계층과 관련된 클래스와 인터페이스들이 자리한다. DB과 관련된 작업을 한다면 사용할 수 있는 패키지명이다.

service (근무, 봉사, 편익, 이용…) - 역시 웹에서 사용되는 계층 중 하나이며 대개 dao를 조합하고 트랜잭션의 경계가 설정되는 구간이기도 하다.

core (속, 중심부, 핵심…) - 어플리케이션의 핵심적인 역할을 수행하는 클래스와 인터페이스들이 자리하는 구간이다.

task (일, 과업, 과제…) - 단어와는 가장 딴판으로 사용되는 용어 중 하나이다. 자바에서 스레드와 관련된, java.lang.Runnable 클래스의 활동을 지원하는 클래스들이 위치한다.

access (접근, 진입로, 증가…) - DB 뿐만이 아니라 다른 리소스의 자원을 불러들이고 이를 자바에서 사용가능한 상태로 가공해주는 클래스들이 위치한다.

support (지지, 지원…) - 가장 잘 이해하고 사용해야 할 패키지명이며 어느 어플리케이션이든 기본적으로 하나씩은 포함되곤 한다. 스프링 프레임워크에서는 대개 구현체를 지원하는 팩토리빈 클래스라던가 객체를 다른 클래스에서 요구하는 형태로 가공해주는 역할의 클래스들이나 부모 패키지의 인터페이스들이 구현된 클래스들이 위치해 있었다.

※ 혹시 이 패키지에 대한 다른 견해가 있으면 꼭 댓글로 말해주길 바란다.

config (구성, 설정) - 다른 언어 또는 외부 자원을 자바의 형태로 파싱해주고 그 설정을 Builder와 같은 설정 구현체에 저장해주는 역할을 담당한다.

validation (확인) - 부모 패키지의 객체들을 검증하는 검사자 클래스들이 위치한다.

util (유용한, 쓸모 있는…) - 부모 패키지의 객채들에 대해 기본적인 CRUD(Create · Remove · Update · Delete)작업을 해주거나 컬렉션 프레임워크과 비슷한, 혹은 좀 더 복잡한 작업을 도와주는 도구 클래스들이 위치한다.

인터페이스

인터페이스는 굉장히 추상적이면서도 핵심의 의표를 찔러야 하는 명명규칙이 필요하다. 그러므로 가장 직관적이고 누구나 이해할 수 있는 단어로 선별해 내는 것이 중요하며 전치사나 동사를 사용하지 않는 것이 좋다.

대개 1~2 단어만 조합되므로 명명규칙이 필요 없을 것 같지만 설계가 좀 더 다양화되고 구체적이게 될수록 인터페이스 간의 관계 또한 복잡해지므로 다음의 스프링 클래스의 이름을 보면서 개발자들이 사용하고 있는 명명규칙을 조금이나마 이해하면 도움이 될 듯 하다.

예) ApplicationContext

// ApplicationContext는 사실 총 6개의 각기 다른 성격의 인터페이스들을 상속받고 있으며 스프링에서 중요한 역할을 담당하는 컨텍스트의 가장 원시적인 모델이기도 하다.

ApplicationContext -▷ EnvironmentCapable, ListableBeanFactory, HierarchicalBeanFactory, MessageSource, ApplicationEventPublisher, ResourcePatternResolver

ConfigurableApplicationContext -▷ ApplicationContext (and LifeCycle)
AbstractApplicationContext -▷ ConfigurableApplicationContext
GenericApplicationContext -▶ AbstractApplicationContext
GenericXmlApplicatonContext -▶ GenericApplicationContext
AnnotationConfigApplicationContext -▶ GenericApplicationContext

위의 인터페이스와 클래스 간의 이름들을 보면 알 수 있는 뻔한 사실이긴 하지만 ApplicationContext 인터페이스를 상속 또는 구현하고 있는 모든 객체가 동일하게 ApplicationContext란 원시 인터페이스의 이름을 유지하고 있다는 것이다. 물론 ApplicationContext 인터페이스 자체는 본인의 이름과 전혀 관계없는 인터페이스들을 구현하고 있긴 하지만 그것도 이유가 다 있다.

왜냐하면 ApplicationContext란 인터페이스에는 2가지의 개념이 적용되고 있는데 바로 인터페이스 간의 포함과 상속개념이 그것이다. 과거에 초보시절에 자바를 배우던 기억을 어렴풋이 더듬어보면 클래스끼리는 클래스 내부에 다른 클래스를 포함시키면 포함관계고 상속 받으면 상속 관계라고 배웠고 인터페이스는 상속은 가능해도 클래스처럼 포함관계를 가질 수 없다고 배웠다.

물론 인터페이스끼리 포함관계가 성립될 수 없다는 것이 맞는 말이긴 하나, 중요한 것은 원칙에 의해 프레임워크를 만들다 보면 때로는 인터페이스 간에도 포함이라는 관계가 필요하다는 것이다. (사실 필자는 그런 경지에 까지 올라가야할 어플리케이션을 만들어 본적은 없지만…) 물론 정확한 사실은 아니지만 필자가 예측하기에 스프링 개발팀은 합치기엔 너무도 다른 성격의 기능들을 각기 다른 클래스로 분리해야만 했고 분리해냄과 동시에 또 의존적 주입이 가능하도록 분리한 클래스들의 인터페이스를 구현해야만 했다. 그리고 그 분리해낸 기능이 합쳐지는 클래스 또한 의존적 주입이 가능하도록 다시 합쳐진 인터페이스를 구현해야 했기 때문에 저런 형태의 인터페이스와 클래스나 나왔던 것이다.

스프링 팀이 이런 문제를 해결하기 위해 반드시 복잡한 인터페이스 다형성 기술을 도입할 필요는 없었지만 아마 자신들의 의존적 주입방식에 대한 확고한 철학이 있었기에 이런 방식으로 문제를 해결할 수 밖에 없었을 것이다. 물론 인터페이스의 다형성 원칙이 원래는 존재하지 않았던 엄청난 기술은 아니지만 대개 인터페이스 상에서 다형성을 구현할 정도로 복잡한 코드를 짜는 프로그래머들이 많지 않기에 조금 시간을 할애해서 설명을 덧붙일 필요성은 있지 않나 싶다.

클래스

스프링을 이용한다면 Dependency Injection이 가능한 형태로 클래스를 만들도록 정말 노력해야 한다. 설마가 사람잡는다고 "이걸 확장할 필요가 있겠어?"란 생각에 인터페이스도 없이 작성한 클래스가 어쩌다보니 확장이 필요하게 되는 경우가 생길 수도 있는 것이다. 그러므로 모든 클래스는 가급적 작성 전에 원시 형태의 인터페이스를 우선 작성하는 것을 고려해야 하며 최대한 모든 조건 하에 주입관계가 이루어지도록 코드를 작성해야 한다.

그러므로 필자는 스프링을 이용하고 항시 인터페이스를 구현한 클래스를 사용한다는 조건 하에 설명하겠다.

Simple + 인터페이스명 : Simple로 시작하는 클래스명은 이 인터페이스의 가장 기본적인 구현체를 뜻한다. 간혹 인터페이스명 + Impl과 같이 사용하는 경우도 있는데 좀 더 의미를 명확하게 하기 위해 Simle이란 접두어를 사용할 것을 권장한다.

용도명 + 인터페이스명 : 기본 구현체 외에 다른 방식으로 이용된다면 용도를 접두어로 사용하는 클래스가 구현된다.

인터페이스명 + Utils : 특정 구현체를 인자로 받아 다양한 역할을 수행해주는 도움 클래스를 지칭한다.

메서드

마지막으로 메서드의 작명규칙이다. 아마 개발자들이 가장 고민하고 답답해하는 부분이 바로 메서드명이 아닐까 싶다. 사실 메서드 명에는 정말 자세히 들여다 보지 않으면 눈에 띄지 않는, 정말 깨알 같이 적용되곤 하는 규칙들이 존재한다. 뭐 get, set같은 거는 이미 오래 전부터 널리 알려진 규칙이고 아래에 작성된 규칙들 또한 프로그래머들 간에 보이지 않는 약속 축에 속한다고 보면 된다.

접두어로의 사용

get… : 어떠한 리소스를 리턴하는 메서드

set… : 프로퍼티에 해당 리소스를 내장시키는 역할의 메서드

init… : 초기값이 필요하다면 초기값을 설정하고 내부에서 관련 validate를 실행하는 역할의 메서드

load… : 전달인자를 기준으로 어떠한 값을 불러와 내장시켜주거나 카운팅하는 역할의 메서드

is… : 불리언 메서드에서 사용되는 접두어이다. 용도는 get…과 같다.

has… : contains 메서드처럼 어떠한 값을 가지고 있는지 확인해준다. 다른 점이 있다면 contains는 좀 더 범위가 넓지만 has는 특정 값으로 범위가 한정되있다.

register… : 기본적으로 set과 동작하는 방식이 같지만 set은 자바빈 규약에 얽혀있기 때문에 복잡한 연산을 포함할 수 없다. 보다 지능적인 set이 요구될 때 register과 같은 접두어를 사용한다.

create… : register…는 보통 void 형태이지만 create는 전달인자를 통해 새로운 객체를 만든 뒤에 이 객체를 리턴해준다. 등록과 생성은 엄밀히 다르므로 create를 register처럼 써서는 안될 것이다.

to… : 많이 만들어두면 참 좋은 접두어 메서드이다. 해당 객체를 다른 형태의 객체로 변환해준다.

전치사로의 사용

A-By-B : B를 기준으로 A를 하겠다는 뜻
ex) getUserByName(String name) : 이름값을 통해 유저를 불러옴

A-With-B : B와 함께 A를 하겠다는 뜻
ex) registerWithGeneratedName(BeanDefinition beanDefinition) : beanDefinition으로 다른 메서드를 통해 GeneratedName 값을 불러와 함께 저장.

접미사로의 사용

…With : 무엇과 함께 있는지, indexOf와 비슷한 성격의 접미사이다.
…s : 해당 객체가 복수의 객체를 반환하는지 단일 객체를 반환하는지 구분하는 것은 매우 중요하다. 복수형으로 표현해야 하는 메서드는 반드시 복수형으로 표현하여야 한다.

Variables naming

변수명은 대문자와 소문자를 섞어서 알아보기 쉬운 형태로 작성하되 소문자로 시작한다.
(ex. xCnt, yCnt, nameImg)
변수들 중 상수처럼 한 번 정한 후 변경할 필요가 없는 변수는 대문자를 사용할 수 있다.
(ex. Width, Height)
동사와 명사가 섞인 변수명을 작성할 때에는 동사를 먼저 적는다.
(ex. saveGame, loadGame)
되도록 변수명 앞에는 그 변수의 타입을 나타내는 접두어를 적는다.
(ex. imgBack, imgForward)
Boolean형의 변수는 접두어로 is나 can을 붙인다.
(ex. isValid, canMove)
순환문 내부에서 사용하는 인덱스 변수는 i, j, k를 사용한다.
(ex. for(i=0; i<MAX; i++))
클래스 전체에 통용되는 클래스형의 변수는 접두어로 m이나 g를 붙인다.
(ex. mContext, mThread)
변수명에는 반드시 주석을 달아주어 변수에 대한 설명을 첨부한다.
(ex. int xCnt, yCnt; //이미지의 가로, 세로 조각 수)

Methods naming

메소드명은 변수명의 명명규칙을 따르되 라이브러리에서 기본적으로 제공하는 메소드와 구분하기 위해 첫 문자를 대문자로 시작한다.
(ex. public void DrawPictures())
메소드가 private 형식이면 메소드명은 소문자로 시작한다.
(ex. private void drawPictures())
하나의 메소드가 길어져 전체를 한 화면으로 보기 곤란한 경우에는 두 개 이상으로 나누어 하나의 메소드가 30라인을 넘지 않도록 한다.
메소드명 바로 위에는 주석을 달아 메소드의 기능과 어디에서 호출하고 있는지를 명시한다.
(ex. /* DrawPicture: Option Menu에서 호출 */)
닫는 중괄호 "}" 가 많이 중첩되는 경우에는 "}" 오른편에 어느 부분의 끝인지 명시한다.
(ex. } //endfor, } //endif)

15 Best Practices for Variable & Method Naming

http://linuxism.tistory.com/573

Use short enough and long enough variable names in each scope of code. Generally length may be 1 char for loop counters, 1 word for condition/loop variables, 1-2 words for methods, 2-3 words for classes, 3-4 words for globals.
Use specific names for variables, for example "value", "equals", "data", ... are not valid names for any case.
Use meaningful names for variables. Variable name must define the exact explanation of its content.
Don't start variables with o_, obj_, m_ etc. A variable does not need tags which states it is a variable.
Obey company naming standards and write variable names consistently in application: e.g. txtUserName, lblUserName, cmbSchoolType, ... Otherwise readability will reduce and find/replace tools will be unusable.
Obey programming language standards and don't use lowercase/uppercase characters inconsistently: e.g. userName, UserName, USER_NAME, m_userName, username, ...
For example for Java,
- use Camel Case (aka Upper Camel Case) for classes: VelocityResponseWriter
- use Lower Case for packages: com.company.project.ui
- use Mixed Case (aka Lower Camel Case) for variables: studentName
- use Upper Case for constants : MAX_PARAMETER_COUNT = 100
- use Camel Case for enum class names and Upper Case for enum values.
- don't use '_' anywhere except constants and enum values (which are constants).
Don't reuse same variable name in the same class in different contexts: e.g. in method, constructor, class. So you can provide more simplicity for understandability and maintainability.
Don't use same variable for different purposes in a method, conditional etc. Create a new and different named variable instead. This is also important for maintainability and readability.
Don't use non-ASCII chars in variable names. Those may run on your platform but may not on others.
Don't use too long variable names (e.g. 50 chars). Long names will bring ugly and hard-to-read code, also may not run on some compilers because of character limit.
Decide and use one natural language for naming, e.g. using mixed English and German names will be inconsistent and unreadable.
Use meaningful names for methods. The name must specify the exact action of the method and for most cases must start with a verb. (e.g. createPasswordHash)
Obey company naming standards and write method names consistently in application: e.g. getTxtUserName(), getLblUserName(), isStudentApproved(), ... Otherwise readability will reduce and find/replace tools will be unusable.
Obey programming language standards and don't use lowercase/uppercase characters inconsistently: e.g. getUserName, GetUserName, getusername, ...
For example for Java,
- use Mixed Case for method names: getStudentSchoolType
- use Mixed Case for method parameters: setSchoolName(String schoolName)
Use meaningful names for method parameters, so it can documentate itself in case of no documentation.

변수 와 메서드 명에 대한 15가지 명명 규칙

코드의 각각 시점에 따라 변수명을 길게 혹은 짧게 쓴다. 보편적으로 말해보자면 loop counter의 경우 1 char로, condition/loop 변수 경우에는 1단어, 메서드의 경우 1-2 단어, 클래스의 경우 2-3단어, globals한 모든 변수/메서드의 경우에는 3-4단어를 사용한다.
변수의 이름에 구체적인 이름을 사용해야한다. 해서는 않되는 예를 들어보자면 “value”,”equals”,”data”이러한 이름을 사용해서는 안된다.
변수에 대한 의미있는 이름을 사용합니다. 변수 이름은 그 내용의 정확한 설명을 정의해야합니다.
변수명이 o_, obj_, m_ etc로 시작해서는 안됩니다. 변수는 변수를 나타내는 태그를 별도로 붙여서는 않됩니다.
회사 명명 표준을 준수하고 해당 응용 프로그램에 맞춰 지속적으로 변수 이름을 작성해야합니다. : e.g. txtUserName, lblUserName, cmbSchoolType, … 그렇지 않으면 가독성을 reduce and find/replace시키는 툴들을 사용할수 없을것입니다.
프로그래밍 언어 표준을 준수하고 모순되는 소문자 / 대문자를 사용하지 마십시오: e.g. userName, UserName, USER_NAME, m_userName, username, …
- Java 를 예로 들면,
- use Camel Case (aka Upper Camel Case) for classes: VelocityResponseWriter
- use Lower Case for packages: com.company.project.ui
- use Mixed Case (aka Lower Camel Case) for variables: studentName
- use Upper Case for constants : MAX_PARAMETER_COUNT = 100
- enum class 이름 과 enum values의 대문자의 경우 Camel Case를 사용합니다.
- 상수와 enum 값 (어떤는 상수)를 제외하고 어디서나 ‘_’를 사용하지 않습니다.
서로 다른 context에서 같은 클래스의 같은 변수 이름을 재사용하지 마십시오: context의 범위 ( 메서드, 생성자, 클래스 안에서). 그렇게 함으로써 모든이들이 쉽게 이해하고 유지보수 할수있습니다.
다른 목적의 method, conditional etc를 같은 변수로 쓰지말자. 차라리 새로만들거나 다른 명칭의 변수명으로 대신하자. 이것은 유지보수적인 측면과 가독성 측면에서 중요한부분이다.
ASCII 캐릭터가 아닌 변수명을 사용하지 말자. 플랫폼에 따라서 작동하지 않을수가 있다.
너무 긴 변수명은 쓰지말자 (예. 길이가 50자이상인경우) 너무 긴 이름은 보기 좋지 않고 읽기가 힘들고 몇몇 컴파일러에서 character제한에 걸려서 작동이 안한다.
하나의 언어로만 명명하자 예를들어 영어랑 독일어랑 섞어서 쓰게되면 뭔가 불일치하고 읽기도 힘들다.
이름은 메서드의 정확한 동작을 지정해야하며 대부분의 경우에 대해 동사로 시작해야합니다. 예를 들어 createPasswordHash 이런식으로 해야합니다.
회사의 명명 규칙에 따르고 어플리케이션에 따라 메서드명을 작성해야한다. getTxtUserName(), getLblUserName(), isStudentApproved(), … 같이 그러하지 않으면 가독성을 reduce and find/replace하는 tool들을 사용할수 없습니다.
회사의 명명 규칙에 따르고 대/소문자가 일치 하지 않는 characters 를 사용해서는 않됩니다. 예를 들어 getUserName, GetUserName, getusername, … 같은
- Java의 예를 들자면
  - use Mixed Case for method names: getStudentSchoolType
  - use Mixed Case for method parameters: setSchoolName(String schoolName)
메서드 매개 변수에 대해 의미있는 이름을 사용한다면, 별도의 문서 정의가 없이도 자체적으로 문서화가 될수 있습니다.

출처: http://linuxism.tistory.com/573 [linuxism]

------------------------

규칙(Convention)

● 프로젝트를 명명 규칙

각 단어의 첫글자는 대문자로 시작
언더바 쓸수 있음, 공백 없음

● 클래스 명명 규칙

언더바 쓸수 없음, 공백 없음
각 단어의 첫글자는 대문자로 시작

● 클래스 명명 규칙

파일명과 클래스명은 반드시 같아야함

● 변수 명명 규칙

카멜 케이스(camel case) : 첫번째 단어는 소문자로 시작, 다음 단어는 대문자로 시작 ex. floatNumber
변수 이름에 언더바를 쓸 수 있지만 쓰지 않는 것이 관례
$도 쓸수 있지만 쓰지 않는 것이 관례
공백 없음

● 자바에서 지원하는 타입

[기본형 : 소문자로 시작]

숫자 : 정수(4가지 int), 실수(2가지 double)
문자 : char
논리 : boolean

● 왜 대문자, 소문자가 중요할까?

대문자로 시작한다면 클래스라는 의미
소문자로 시작한다면 변수라는 의미
ex. System.out.println(); //System은 클래스, out은 변수!

변수의 형변환(Type casting) ★

(실무에서는 casting이라고 불림.)

● 캐스팅

개념 : 크기가 서로 다른 변수들을 교환한다.

boolean 빼고 다 바뀔 수 있다. float → double, char → byte, int, short, long

캐스팅 방법

명시적 : 개발자가 강제적으로 캐스팅.

(타입) 변수명

임의로 여분의 공간을 만들어내는 것이고, 선언한 변수는 변화가 없다.

주의 : 캐스팅하려는 숫자가 캐스팅받는 변수 크기범위에 속하는지 아닌지를 확인해야한다.

묵시적 : 자동으로 캐스팅.

단, 같은 타입일 때 크기(byte)가 작은 type에서 큰 type으로 변환할 때.

실무에서는 실수 → 정수, 정수 → 실수, 문자 → 숫자, 숫자 → 문자 캐스팅이 많이 쓰인다.

주석을 먼저 달고 코딩하는 방법 : Sudo Coding

예제 (1-1)

예제 (1-2)

예제 (1-3)

예제 (2)

예제 (3)

출처: http://ande226.tistory.com/7?category=166275 [안디스토리]

'프로그래밍 > JAVA' 카테고리의 다른 글

이클립스(Eclipse) 개발환경 "UTF-8" 인코딩 설정 (0)	2017.11.28
JAVA Native Method (JNI) (0)	2017.11.21
자바 환경 변수 설정 (0)	2017.11.16
Collections Framework (0)	2017.11.13
UML: 클래스 다이어그램과 소스코드 매핑 (0)	2017.11.13

코드 다이버

메서드,클래스 명명규칙