skeleton code, pseudo code 사용 후 느낀 점
어제 skeleton코드와 pseudo코드를 사용해 할 일 목록을 만들기 전에 전체적인 틀을 잡았고, 오늘은 어제 작성한 코드를 기반으로 메소드를 만들었다.
메소드를 만들 때, 이미 pseudo코드에서 어떻게 만들어야 할지 적혀있기 때문에 그대로 따라가면서 만들었고, 정말 하나도 힘들지 않았다.
한글로 적혀있는 pseudo코드를 보면서 프로그래밍 언어로 쭉쭉 코드를 작성하고, 테스트 코드를 통해 내가 원하는 값이 나오는지, 오류가 없는지 확인까지 마쳤을 때의 기분을 잊을 수가 없다.
막히는 것 하나 없이 클래스 구현을 완료해서 조금 얼떨떨하지만 이것이 설계를 하는 이유인 것 같다.
중간에 살짝 당황했던 것으로는 어제 틀을 잡을 때, 할 일 관리 클래스와 할 일 보여주기 클래스를 만들겠다고 설계를 했었는데 할 일 관리 클래스에는 프로퍼티로 todosList가 들어가 있어서 메소드에서 todosList를 참조해서 사용할 수 있었지만, 할 일 보여주기 클래스에서는 할 일 관리 클래스의 todosList를 참조해야 하는 문제점이 있었다.
예전에 class에 대해 공부할 때 봤던 class 확장을 사용해서 할 일 관리 클래스와 할 일 보여주기 클래스를 하나로 묶어서 해결했는데, 지금 다시 생각해보면 이렇게 하면 굳이 클래스를 두 개로 나눈 이유가 없어지는 것 같아서 잘못된 것 같다.
내가 원하는 것은 할 일 관리 클래스는 관리만 하고, 보여주는 클래스는 보여주기만 하는 것인데, 지금은 보여주기 클래스가 확장이 되어서 관리까지 하고 있기 때문에 그냥 하나의 클래스에 만들어 놓은 것과 다를 바가 없다...
방법을 생각해 봐야 할 것 같다. 지금 생각나는 것은 굳이 클래스를 두 개로 나누지 않고 한 개의 클래스에서 모두 관리하는 것과 보여주기 클래스의 메소드를 호출할 때마다 현재 todosList를 인수로 넘겨주는 것이다.
클래스에 대한 고민
항상 클래스를 만들 때, 인스턴스에게 필요하지 않는 메소드나 프로퍼티를 어떻게 숨길 수 있을까?에 대한 고민을 하는데 아직까지도 명확하게 알지 못했다.
다만, 메소드를 쪼갤 때, 인스턴스에게 필요하지 않으면 대부분이 클래스 자체의 책임이 아니라는 것을 알게 되었는데 이 메소드는 util함수로 빼야 한다고 한다.
하지만 그냥 뺀다고 빼는 것이 아니라 util함수인 만큼 어디에서나 사용할 수 있게 자신만의 책임을 가지고 있어야 하는데 책임을 가지게 하는 것이 정말 어렵다.
이번에도 메소드에서 중복된 이름이 있는지 검사하는 것과 todosList에서 특정한 값을 찾는 등과 같은 메소드의 책임이 아닌 것들을 분리해줬는데, 이것은 역시 할 일 관리 클래스의 책임이 아닌 것 같다는 느낌이 강하게 들었다.
그래서 util함수로 분리하기 위해서 중복된 값을 찾고, 특정한 값을 찾는 함수로서의 기능을 만들어주기 위해 고민을 했는데, 이름도 변경되고, 받아야 하는 매개변수가 너무 많아지고 (3개는 괜찮나??..) 과연 다른 곳에서도 사용할 수 있을지 의문이 드는 함수가 탄생했다.
이 부분에 대해서는 정해진 답이 없을 것 같고, 끊임없이 고민해서 나만의 방법을 찾는 것이 가장 좋은 해결책인 것 같다.
그래도 예전보다 가독성 있고, 모듈화가 잘 된 코드인 것 같아 성장하고 있다는 생각이 들어 기분이 좋다.
요약
skeleton코드와 pseudo코드를 사용하면 코드 구현이 쉬워지고, 가독성이 좋아지며, 클래스에 대한 책임과 모듈화에 대한 생각을 하게 되고, 무엇보다도 한글로 작성된 언어를 프로그래밍 언어로 작성할 수 있다는 기쁨과 내가 한 설계대로 구현이 된다는 것에 대한 기쁨을 느낄 수 있다.
꼭 써봐야 한다!!
