OOP의 중요한 원칙 중하나가 인터페이스를 잘 만드는 것이다.

아무리 고민을 해봐도 정답이 없고 계속 이리 저리 바꾸며 시간을 보낸적이 많다.

아래는 http://www.nextree.co.kr/p6960/ 에서 Open Close Principle 부분을 인용해 온 글이다.

```

 

  1. 확장되는 것과 변경되지 않는 모듈을 분리하는 과정에서 크기 조절에 실패하면 오히려 관계가 더 복잡해 질 수 있습니다. 설계자의 좋은 자질 중 하나는 이런 크기 조절과 같은 갈등 상황을 잘 포착하여 (아깝지만) 비장한 결단을 내릴 줄 아는 능력에 있습니다.

  2. 인터페이스는 가능하면 변경되어서는 안 됩니다. 따라서 인터페이스를 정의할 때 여러 경우의 수에 대한 고려와 예측이 필요합니다. 물론 과도한 예측은 불필요한 작업을 만들고, 보통 이 불필요한 작업의 양은 상당히 크기 마련입니다. 따라서 설계자는 적절한 수준의 예측 능력이 필요한데, 설계자에게 필요한 또 하나의 자질은 예지력입니다.

  3. 인터페이스 설계에서 적당한 추상화 레벨을 선택해야 합니다. 우리는 추상화라는 개념에 '구체적이지 않은' 정도의 의미로 약간 느슨한 개념을 갖고 있습니다. 그래디 부치(Grady Booch)에 의하면 ‘추상화란 다른 모든 종류의 객체로부터 식별될 수 있는 객체의 본질적인 특징’이라고 정의하고 있습니다. 즉, 이 '행위'에 대한 본질적인 정의를 통해 인터페이스를 식별해야 합니다.

```

 

1메서드 1인터페이스로 한다면 인터페이스 관련 OOP원칙에 잘 맞을 것이다.

하지만 뭐하나 만들 때마다 그 많은 인터페이스를 다 적어주는 것도 코딩을 피곤하게 만든다.

모든 상황에서 사용하기 편한 인터페이스는 존재하지 않을 수 있다.

수 많은 상황속에서 가장 자주 쓰고 특수한 상황을 잘 대처해 나갈 수 있는 인터페이스를 만드려면

도메인에 대한 이해가 중요하다.

하지만 도메인에 대한 완전한 이해는 많은 시간이 걸리는 일이다.

FP라면 이러한 상황을 좀 더 유연하게 대처할 수 있을 것이다.

견고함과 목적성의 불확실성은 다소 가질 수 있겠지만 FP를 통해 OOP를 구현하는 것이 쉬워 보인다는 생각이든다.

 

 

'개발 방법론' 카테고리의 다른 글

기능 설명서와 우선 순위  (0) 2017.12.19
javascript package  (0) 2017.12.10

투자자 - 시행사 - 하청업체 


시행사와 하청업체는 협력업체 관계

이런 구조에서 시행사에서 PM이 나오고

하청업체 개발자들(나)과 일을 한다.


하나의 일에만 전념한다면 프로젝트가 성공적으로 가겠지만

두 업체 모두 개발이 체계적으로 잡혀있지 않은 경우 참 힘들다.

만1년이 되가는 개발자(나) 매일 야근하면서 피곤에 쩔어 개발중

프로그램 전체 구조를 볼 수가 없다.

자꾸 뭔가 새로운게 생기지 않길 기도하고 걱정하면서 개발한다.

PM과 하청업체 관리자는 개발에 대한 관심보다 자기일 하기 바쁘다.

개발은 늦어지지고 본인들 생각과 결과물은 점점 거리가 멀어진다.

해야 할게 너무 많다. 개발 직접 도와줄거 아니면 나한테 아무말 안시켰으면 하는 마음

결국 시험테스트날 문제가 터진다.

시행사와 하청업체는 서로 말이 달라 티격태격

예상 했던 일이다.

어떻게 하면 이일을 막을 수 있었을 까

나한테는 어느정도 책임이 있는 걸까

어째든 다음에 내가 이런 일을 막으려면

아무리 개발할 시간이 부족해도 요구사항에 대한 우선 순위를 표를 만들어서

매일 보고하는 수 밖에 없을 것 같다.

내 실력이 어느정도 위치인지 계속 눈치를 봐왔지만 이제 그럴 필요 없는 것 같다.

그냥 지금 상황은 내가 주도해서 다 하는게 차라리 낫다.

개발일정이 조금이라도 늦어지면 철저히 보고를 해야 겠다.

답답하면 사람 더 뽑겠지

그리고 늦어지는 이유를 설명하고 야근은 배째야겠다.(하지만 그럴 수 있을까?)

물론 내 삽질로 늦어진거면 마무리 지어야한다.


답답하면 직접 개발하던가~


'개발 방법론' 카테고리의 다른 글

어떻게 좋은 인터페이스를 구현할 수 있을까?  (0) 2019.04.06
javascript package  (0) 2017.12.10

javascript는 package가 없다

하지만 package.json 이라는 파일을 많이 본적이 있다.

아마도 프레임워크에서 쓰는 것으로 추측된다.

아는 프레임 워크는 없지만

javascript트도 package관리의 필요성이 절실히 느껴졌고

namespace를 package처럼 쓰기로 했다.


클래스 패키지는 아니지만

여러 사이트의 api를 짬뽕해서 쓰다보니(이런 프로젝트는 최대한 피하도록 합시다.)

관련 url 주소들을 패키지화해서 관리하는 것도 괜찮다.

값들을 final로 주고 싶지만 json 내부 요소들은 const지정을 할 수 없다.


+ Recent posts