일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- 최적화
- 튜토리얼
- Effective C#
- shader
- 유니티 그래픽 최적화
- 깃허브
- 에러
- tutorial
- 파이널 IK
- github
- 애님
- 쓰는 법
- 2판
- error
- 오류
- 리깅
- 메모리
- 속성
- 애니메이션
- 사용법
- 유니티
- 쉐이더
- Final IK
- 익명 타입
- 리팩토링
- 프로퍼티
- 유니티 그래픽스 최적화 스타트업
- unity
- NavMesh
- c#
- Today
- Total
목록리팩토링 (3)
참치김밥은 최고의 한식이다
타입을 public으로 만드는 것이 너무 쉬운 나머지 무조건적으로 public으로 선언하는 경우가 있다. 사실 상당수의 독립 클래스는 public 보다 internal로 선언하는 것이 낫다. 또한 가시성을 제한하기 위해서 기존 클래스 안에 protected나 private으로 중첩 클래스를 만드는 것도 좋은 방법이다. 이처럼 가시성을 제한하면 코드의 일부를 변경하였을 때, 시스템 전반에 걸쳐 수정해야 하는 부분이 적어진다. 외부에서 접근하는 코드가 적기 때문에 변경해야 할 코드의 내용이 적어지는 것은 어찌 보면 당연하다. 예시 코드 ↓ //수정 전 코드 public class PhoneValidator{ public bool ValidateNumber(PhoneNumber ph){ //... return..
선택적 매개변수가 있기 전에는 아래와 같이 일일이 오버로드를 구현해야 했다. void Person(string name); void Person(string name, int age); void Person(string name, int age, int gender); void Person(string name, int age, int genter, string address); ... 하지만 선택적 매개변수 기능을 통해 아래와 같이 간결히 표현할 수 있게 되었다. void Person(string name = "", int age = 0, int gender = 0, string address = ""); 그리고 명명된 매개변수를 이용해서, 원하는 매개변수만 전달할 수 있다. Person(name : ..
대부분의 사용자는 속성(프로퍼티)이 데이터 멤버와 동일하게 동작할 것으로 기대하며, 그렇지 않을 경우 타입을 잘못 사용할 수 있다. 속성을 사용하는 문법이 데이터 멤버를 직접 사용하는 것과 같기 때문에, 동작 방식 또한 같으리라고 생각하게 된다. 즉, 프로퍼티가 데이터 멤버를 올바르게 모델링하도록 작성해야 사용자들이 불편하지 않다. 프로퍼티는, 다른 변경 사항이 없다면, get 접근자를 반복해서 호출할 때 늘 같은 값을 반환해야 한다. 덧붙여, 사용자들은 프로퍼티 접근자가 많은 작업을 수행할 것으로 생각하지 않는다. get 접근자가 내부적으로 너무 많은 작업을 수행하지 않도록 한다. 또, set 접근자에서도 값의 유효성 검증 정도만 처리하도록 작성하는 것이 좋다. 아래가 적절한 예시이다. public s..