[💬] 리팩토링 : null 비교를 is has 로 바꾸긔

[산적대왕(raveneer)]

리팩토링 하고싶다!

오늘은 간만에 리팩토링 즐기는 중인데

꽤 괜찮은 리팩토링이라 생각되서 적어봄

if(xxx == null)

if(xxx != null)

들을

if(xxx.Isxxed)

if(xxx.Hasxxx)

로 바꾸는 리팩토링임.

이러면 장점이 널체크가 해당 클래스의 책임이 되어서

특정 클래스의 특정 변수가 null인지 여부를 신경쓰지 않게 됨.

특히 xxx == null 이것은 해당 변수가 null 인지 여부를 체크하는 것이지,

어떤 '의미'를 가지고 있는 것은 아니잖아?

구현은 매우 심플함

class Actor{

Item Item {get; private set;}

}

을

class Actor{

private Item _item;

public bool HasWeapon => _item != null;

public bool IsUnEquipped => _item == null;

}

요렇게 고치면 땡임.

이러면 널체크는 Actor 안에서만 행하게 되고,

외부에서는 좀 더 의미있는 코드를 쓸 수 있음.

if(Actor.HasWeapon) {

Actor.Attack();

}

if(Actor.IsUnEquipped){

Actor.Equip(newItem)

}

액터의 아이템이 null인지 외부에서는 알 필요가 없어졌다.

그리고 나중에 HasWeapon 등의 bool 이 보다 복잡한 조건을 가지게 되어도,

Actor 클래스만 고쳐주면 되므로 외부코드에는 아무런 수정사항이 생기지 않아 좋음.

하...

c#8 도 안되는 유니티 붙들고 고생한다...

[리슬링(lucid74)]

원래 IsValid같은건 많이들 쓰지않음?

[로코복실한(dovecreative)]

나도 클래스 초기화됐는지 안됐는지 채크할때 저렇게 하긴 함. 루프 안에서 언제 호출될지 모르는데 얘가 초기화된앤지 아닌앤지 모르니까

[익명(39.7)]

xxx =! null 문제를 xxx.hasblah 로 바꿨다고? 뭐가좀 이상하지 않니;;? - dc App

[산적대왕(raveneer)]

꼭 has를 쓰는 건 아니고, 코드 문맥에 따라 이름은 바뀔 수 있음. 딱 바꾸고 나면 이걸 왜하나 싶지만, 조건들이 추가되기 시작하면 유용함. 특히 외부에서 Actor.Item == null 을 검사하기 시작하면 골치아픔. 이미 Item이 노출된 거라서 Item의 public 변수를 수정할 우려도 생기고.

[ㅈㅈ(220.122)]

if(Actor.HasWeapon) { Actor.Attack(); }

[ㅈㅈ(220.122)]

이거를 Actor?.Attack();로 하는게 낫지않나

[산적대왕(raveneer)]

그건 Actor 가 null 인지 여부에 따라 작동하는 코드고, Actor.TryAttack() 같은걸로 퉁쳐도 되겠네. 이 리팩토링의 포인트는 널체크를 좀 더 의미있는 검사로 감싸서 읽기 편하게 하는 거임.

[산적대왕(raveneer)]

그리고 리팩토링은 취향도 상당히 타는 분야라서 걍 이렇게도 생각하는구나 하면 좋겠다.

[산적대왕(raveneer)]

빼먹은건데, 이건 해당 프로퍼티(변수) 가 public get일 때 이야기임. private 변수들은 굳이 이렇게 할 필요 없이 걍 널체크 해야지 뭐... 그걸 빼먹으니 되게 이상하게 보이네 ㅠㅠ

[익명(1.234)]

언리얼이 IsValid씀

[익명(222.234)]

?. sugar 쓰지