코드 정리 #3

이번 소스는 여기에 있다.

 

출처 : https://github.com/bytedeco/javacv/blob/master/src/main/java/org/bytedeco/javacv/FFmpegFrameFilter.java

 

 

깃허브에서 무작위로 아무 코드나 들어가서 구경하다 보면 난해한 코드들이 보인다.

난해한 이유는 로직이 정교하고 복잡해서 난해할 수도 있겠지만 위의 소스는 최적화가 덜되어 난해한 것 같다.

 

나를 처음 당혹스럽게 만든 것은 이 부분이다.

 

 

 

자바는 명시적 메모리 프리를 지원 안하지만 개비지 콜랙터를 위해서 null을 할당하기도 한다.

그런데 위 코드에서 null을 넣어서 동작시킨다는 것은 넣지 않으면 예상대로 동작 안할 수도 있다는 것이다.

 

저렇게 조금은 중구난방하게 메모리 해제를 하는 부분은 실수 여지를 크게 만들어 버린다.

 

그래서 어떻게 고칠 수 있을까 생각해보다가 여러 프로퍼티들의 선언이 궁금해졌다.

이런. 선언이 어디있는 거야?

 

그래서 소스를 좀더 뜯어보면 밑에 프로퍼티 선언이 나와 있다.

이것도 지적할 수 있는 것이 프로퍼티 선언은 클래스 선언 상단에 위치해야 한다.

왜냐하면 많은 자바 클래스 코드들이 프로퍼티 선언을 클래스 선언 상단에 하기 때문이다.

혼자하는 코딩이 아닌 한 코드 작성은 관례, 규칙성을 잘 고려하는 것이 필요하다.

 

다시 본론으로 돌아와서...

코드를 분석해 보면 AVFilterContext, AVFilterGraph 등등이 사용되고 있다.

무슨 코드인가 뜯어보려고 했는데 결국 저 클래스들의 정의문은 깃허브의 레포지토리 검색에서도 실패했다.

 

이제 여기서부터 말로 코딩을 하는 구로그래밍을 할것이다.

_free 접미어가 붙은 function이 있는 것으로 봐서 jni와 관련된 클래스로 보인다.

그리고 그 클래스들이 인터페이스화가 덜되어 있다.

이렇게 추측하는 근거는 릴리즈 코드가 동일 레벨 선상에서 각각 다르게 동작하고 있기 때문이다.

그러므로 jni를 적용한 class들의 입출력 구조를 최대한 동일하게 맞춰서 재구성 하는 것이 권장된다.

인터페이스를 사용해도 좋고 Wrapping Class를 사용해도 좋다.

 

한차례 더 가공하여 동일한 인터페이스로 접근을 하게 만들자는 것이다.

이렇게 하는 목적은 물론 소스코드의 가독성 증가와 유지보수 편의성 증가를 위한 것이다.

 

그럼 희망하는 코드를 작성해 보겠다.

 

void releaseUnsafe() throws Exception 
{
	filterGraph.Free():
	aFilterGraph.Free();
	imageFrame.Free();
	sampleFrame.Free();
	filtFrame.Free();
	
	frame = null;
}

 

Free() 메쏘드가 각 상황에 따라 implement 되어야 간결해지지 않을까 싶다.

위처럼 코딩해 놓으면 저 메쏘드를 거의 고칠 필요가 없지 않은가?