(Day 27) OOP; 인터페이스와 equals()

복습

필드나 메서드에 접근을 제어해야 하는 상황은 언제가 있을까?

대부분의 상황에서 접근을 제어해야 할 것이다. 다른 클래스에서 필드에 임의 접근이 가능하다면 캡슐화가 깨진다. 캡슐화는 추상화를 지원하는 도구이고, 추상화는 현실 세계를 데이터와 연산자로 표현하기 위한 노력이다. 그래야 컴퓨터가 처리할 수 있으니까.

Modifer 란?

private (default) protected public이 있다. 클래스 내부, 같은 패키지, 서브 클래스, 그 외(외부 패키지)

getter/setter, property

메서드를 통해 필드에 접근하게 만드는데, 그 메서드들은 이름을 getOOO, setOOO 으로 관습적으로 사용한다. 그래서 그런 메서드를 게터, 세터 메서드라고 부른다. 그리고 게터와 세터를 가지고 있는 것을 프로퍼티로 표현한다. raed only, write only, read/write property 를 가지고 있다고 말한다.

추상 클래스와 추상 메서드의 활용을 설명해보기

보통 일반화 과정에서 자주 사용한다. 상속만을 위한, 즉 필드와 메서드를 직접 인스턴스로 만들어서 쓰는 게 아니라, 서브클래스에서 사용할 목적으로 클래스를 만들 때 추상 클래스를 만든다. 추상 메서드는 이러한 추상 클래스에서 어떤 메서드를 서브 클래스에서 꼭 구현하도록 만들기 위한 것이다.

학습

도제식 교육..

개인적인 생각이다. 프로그래밍은 도제식 교육이 어울리지 않는, 강의가 정말 많이 오픈되어 있는 영역이라고 생각했는데 그렇지 않은 거 같다. 교육은 정말 많이 오픈되어있는데, 도제식으로 배우는 것의 효과가 줄어드는 영역은 아니다…

인터페이스 문법에 대해

default 메서드

인터페이스와 그 인터페이스를 구현하는 클래스들을 가지고 있는 상황이다. 인터페이스를 구현하는 다른 클래스를 추가로 만들 때 메서드 형식을 인터페이스에 추가하면 (public abstract) 기존의 클래스들이 영향을 받는다.

영향을 안 주면서 인터페이스에 메서드를 추가할 수 있을까? 그것은 deafult modifier를 통해서 가능하다. 이렇게 인터페이스에서 메서드를 선언하면, 그것은 디폴트 메서드이다.

문제: 인터페이스를 구현할 클래스에서 메서드 구현을 강제 할 수 없다. 사용이유: 기존에 인터페이스를 구현했던 클래스에 영향을 미치지 않는다.

이런 단점이 있기에, 아래와 같은 선택지들이 생긴다.

1. 인터페이스를 구현하는 기존의 클래스들을 수정한다.
2. 구현을 강제하지 않는 deafult 메서드를 추가한다.
3. 인터페이스를 상속받는 다른 인터페이스를 만들어서 사용한다.

인터페이스를 구현한 클래스에서, 그럴 일은 거의 없겠지만 인터페이스의 default method를 호출해야 할 경우가 있을 수 있다. 그 경우 super.[defaultmethod]를 통해서 호출할 수는 있다. 인터페이스를 사용하는, 객체지향 프로그래밍의 목적에 어긋나는 일이 될 수 있으니 정말 피치 못할 경우에만 사용될 이야기다.

private 메서드

인터페이스 또한 private modifier를 사용할 수는 있다. 이것은 인터페이스 내부에서 사용하는 메서드만을 위한 것이다. 추상메서드에서는 불가하므로 오로지 default 메서드에서만 사용 가능하다. 이런 것이 있다는 정도만 알아두자. 인터페이스의 복잡도가 너무 높아지게 될 수 있다.

.. = Callee 들을 더 추가하고 싶을 때 = 피호출자들을 더 추가하고 싶을 때 = 인터페이스를 구현하는 클래스들을 더 만들고 싶을 때 (위 세 문장이 완전히 동일하다는 의미는 아니다.)

기존 인터페이스를 구현한 클래스들에 오류를 만든다.

인터페이스

인터페이스는 보통 최소 상태의 추상클래스를 거쳐서 콘크리트 클래스로 구현한다. 왜? 인터페이스를 준수하는 클래스를 만들 때 추상클래스를 통해서 상속받는다면, 그 추상클래스에서 최소구현만 해두고, 인터페이스 규칙 중 필요한 규칙만 구현하면 되기 때문이다. 인터페이스의 아주 많은 요구사항 중 일부만 준수하는 클래스를 만들 수 있다는 것이다.

java.util 의 ArrayList 클래스를 보면 계층도에서 이러한 형태를 취한 것을 확인해 볼 수 있다. 대부분이 이렇게 만들어진다.

… 최소상태로 구현한 것이 문제가 되진 않을까?

GPT에게 물어보면 아래처럼 대답해주네. 더 넓은 관점에서 생각해 볼 수 있겠다.

장점	내용
유연성과 확장성	추상 클래스를 통해 일부 메서드의 구현을 제공함으로써, 인터페이스 구현 클래스들이 공통 로직을 상속할 수 있음
일반적인 구현 제공	추상 클래스는 인터페이스의 기본 구현을 제공하여 구현 클래스들이 일반적인 동작을 미리 상속받을 수 있음
인터페이스 변경 대응	추상 클래스를 사용하면 변경 사항에 대응하는 로직을 해당 클래스에서만 수정하면 되므로 유지보수가 편리함
추상 클래스 생성자 활용	초기화 로직이나 필수 데이터 설정 등을 추상 클래스의 생성자에서 처리 가능
다중 상속 한계 극복	단일 상속 제약을 극복하기 위해 여러 인터페이스를 구현하는 대신, 추상 클래스를 활용할 수 있음
자원 관리 및 소멸자 활용	리소스 관리, 소멸자 등을 처리할 수 있어 특정 작업에 필요한 자원 관리를 쉽게 구현 가능
디폴트 메서드 제어	추상 클래스를 통해 인터페이스의 디폴트 메서드를 오버라이드하거나 재정의하여 제어 가능

인터페이스- 추상클래스 콜라보레이션의 예시

Servlet Servlet은 인터페이스이다.

• init()
• service()
• destory()
• getServletInfo()
• getServletConfig()

이러한 인터페이스가 있는데, 이를 미리 구현한 추상클래스인 GenericServlet 가 있다. 이 추상클래스는 위 메서드들을 최소한으로 미리 구현해두었다. (단 service() 는 미구현) 그래서 GenericServlet을 상속받아서 서블릿을 만들면 service()만 구현하면 되며, 혹시라도 다른 메서드들을 직접 구현하고 싶다면 오버라이딩하여 메서드를 재정의하면 된다.

이렇게 만들어진 구조는 어떻게 개발자를 행복하게(?) 해 주는가? 서블릿이라는 콘크리트 클래스를 작성할 때, 매번 모든 메서드를 구현할 필요가 없이, 반드시 구현해야 하는 부분만 구현하면 되고, 상황에 따라서 오버라이딩을 통해 메서드를 재정의할 수 있게 된다. 그래서 중복코드가 없어진다!

.eqauls() 메서드에 대해

자바의 모든 클래스는 Object 클래스의 서브클래스이다. Object 클래스에는 .eqauls() 메서드가 정의되어 있는데, 이는 인스턴스를 가리키는 주소가 같은지를 비교하도록 정의되어 있다. ㅇ Wrapper 클래스들은 Object 클래스의 .equals() 클래스를 재정의(Overriding) 한다. 레퍼런스 변수를 피연산자로 받으니, 그 변수가 가진 인스턴스의 주소를 비교하는 것보다는, 레퍼런스 변수가 가진 인스턴스의 내용물을 비교하고자 하는 필요가 생겼기 때문이다.

대표적인 클래스는 String 클래스가 있다. String 클래스는 인스턴스 주소를 비교한다면 == 비교연산자를 통해서 비교할 수 있고, 내용물을 비교한다면 오버라이드한 .equals() 메서드를 통해서 비교할 수 있다.

.equals()메서드를 재정의하지 않으면 슈퍼클래스인 Object 클래스에 정의된 대로 인스턴스의 주소만을 비교하게 된다. 그래서 이를 재정의하는 경우가 많고 (통일성을 위해 별도의 메서드를 정의하기보다는 그대로 쓰는게 낫다) 이 작업이 반복되다보니 IDE에서 반복작업을 자동화해주었다.

이클립스로 치면, Context Menu > Source > Generate ... 하는 메뉴에 .equals() 를 자동으로 작성해주는 기능이 있다. 인스턴스의 어떤 변수들을 비교할지도 GUI를 통해 선택할 수 있다. 바로 값을 비교하는 것이 아니고 인스턴스가 같은지부터 확인하는 등의 코드도 같이 작성되니 편하다.

참고로 네이버 필기시험에서, 자주 사용되는 클래스의 .eqauls() 메서드가 오버라이딩 되었는지 알고있는 문제를 낸 적이 있다고 한다.

해쉬

어떤 데이터를 받으면 그것을 기준으로 어떤 계산을 거쳐서 더 작은 값을 뽑아낸다. 이 작은 값은 신원을 검사할 때 쓰는 지문처럼 데이터의 동일성을 조사하는데 쓰인다.

해쉬 값은 가능하면, 다른 내용이면 다른 값을 가지게 한 것이며, 실제 데이터를 전부 표현하지는 못하기 때문에, 다른 데이터끼리도 해쉬 값이 같을 수도 있다. 낮은 확률이지만 불가능한 일은 아니다. 그래도 파일의 뱐서를 막는데는 아직까지도 좋은 수단이다.

N타임

중소기업도 1:500~800 정도의 경쟁률이 나오는 경우가 있음. 그만큼 공급이 아주 많은 상황임. 솔루션 : 눈에 띄어야 한다. 채용담당자가 좋아할만한 인재상을 이해하고 거기에 맞춘 모습을 보여줄 수 있어야 한다.

1. 이력서와 포트폴리오 작성법
   1. 기본제공 템플릿 사용 금지!!
   2. 시각적인 자극이 있는, 디자인적 요소가 있는 이력서를 줘야 눈에 띈다.
   3. 노션 및 마크다운 언어를 적극적으로 활용하길 바란다.
   4. 개발팀장이 확인할텐데, 가장 의미있는 건 깃허브 메인이나 깃허브 블로그임. 무조건 꾸며야 함.
   5. 리포지토리도 꾸며주는 것이 좋다. 관심있는 지원자면 리포도 한번 볼 거다.
   6. 리포지토리 들어갔을 때 README.md 꾸며두라는 이야기다. 그리고 이 내용을 블로그에도 재활용하라.
      1. 내용은? 문제 해결한 경험, 본인이 참여한 부분 (버스타지 않았음)을 증명하는 것이다.
   7. 노션, PDF로 포트폴리오 작성해두기. PDF 만들 때는 캔바(canva) 추천.
      1. PDF에서 링크나 QR코드(출력된 경우 대비) 관리해둘 것 10.결국 전달력을 높이는 것
   8. 단축URL을 활용하는 것 추천. 출력물은 직접 쳐서 들어가야 하는 경우 생길 수 있기에.
2. 기업이 원하는 인재상
   1. 일반적인 인재상
      1. 문제해결능력(코딩테스트도 여기 포함됨)
         1. 깃허브 리포 리드미를 꾸며야 하는 이유.
            1. 팀워크 인프라 웹 코드… 이런 부분의 근거가 되어 준다.
            2. 고려했던 사항
      2. 정량적 데이터로 어필 및 설득 (정성X)
      3. 수동적X, 능동적 업무
      4. 조직내 분위기 융화 (개발은 협업업무)
      5. 예측 가능성 (성실성, 책임감)
3. 지원 및 면접 준비
   1. 자료를 만들어가기. 뭐든 만들어두고 기록해두면 활용하게 된다.
   2. 완벽한 이력서나 완벽한 포트폴리오를 만들겠다는 생각은 버려야 한다.
   3. 최대한 많은 기회를 얻고 실제 면접을 경험하기
   4. N캠프에서 지원하는 채용지원 프로그램(특히 모의면접) 적극 참여할 것
   5. 하루 단위, 한 주 단위의 구체적인 목표 세우고 최대한 빨리 취업하기
   6. 기술 면접은 최소 주 2회이상 동료들과 롤플레잉으로 연습
   7. 서류전형 통과시 해당사 도메인 및 기술스택에 대해 알아보고나서 면접응하기
   8. 평소에도 동료들과 개발자다운 대화 즐기기

마인드스토밍 : 나의장점이나 왜 개발자가 되려고했는지 뭘 하고싶은건지, 관심있는 부분은 뭔지, 이런 것들을 생각해보기. 그러면 스토리가 생긴다. 스토리가 있어야, 내러티브가 있어야 듣고싶은 이야기가 된다. 그 내러티브가 생겨야 의미있는 1분 자기소개를 만들게 해준다.

• 단점을 장점으로 재포장하는 과정 필요

  나이가 많다는 점은 늦은 출발만큼의 간절함과 절박함으로 다른 분야 출신의 비전공자라는 점은 변화와 배움을 즐긴다는 기질로 받아들여주신다면 정말 감사하겠습니다.

도전의 불확실성에서 오는 불안감을 성취감으로 전환하여 도전을 즐긴다.

단점을 물어본다. 단점을 고민해보았는지, 단점을 극복하려고 해봤는지가 궁금한거다.

하루, 일주일의 구체적인 목표를 세우는 이유중에 하나는, 불안감을 해소하기 위해서이기도 하다. 또한 취업이 늦어지더라도, 구체적인 목표를 계속 수행했다면 깃허브도 잘 꾸며지고 포트폴리오도 더 만들어져서 더 높은 확률이 만들어질 것이다.

코딩테스트도 준비하자. *라이브러리가 강하고 간결한 파이썬을 쓰는 경우도 있지만.. 화이트보드 코딩을 시키는 경우가 종종 있다. 문제해결, 논리력, 언어활용능력 보고 싶어서 그렇다. 그래서 한가지 도출되는 사항. IDE 없이 풀어볼 필요가 생긴다.

블로깅이나 깃허브 꾸밀 때도 이미지가 중요한데, 이미지도 AI로 만들 수 있고, 텍스트는 뭐 말할 것도 없이 만들 수 있다.

미니프로젝트 진행도 추천한다.

메인프로젝트 진행 때 아쉬웠던 부분을 미니프로젝트로 진행해본다면? 그 흐름이 리드미에서 나온다면? 학습하는 모습을 보여주는 증거가 된다. 아쉬웠던 부분을 학습해서 개선했다? 문제를 해결한 예시가 바로 보이니 뽑고싶고, 돋보이는 (눈에 띄는) 사람이 된다. 미니프로젝트는 비지니스 로직이 간단해도 상관없다. 그 외에, 기술면접에서 중요하게 생각되는 부분을 직접 구현해보면서 행동하면서 공부하고 적용까지 하는 사람이라는 걸 어필하는 것도 방법이다. 시간적 여유가 비교적 많다면, 조금 더 의미있는 미니프로젝트를 진행하고 싶다면, 포트폴리오 웹 사이트를 만들어보는 것이 좋다. (근데 선택사항. 시간이 많이 걸린다)

취업 후도 마찬가지다

능동성이 중요하다. 회사에서 시킨 일이 아닌데 능동적으로 문제를 해결하고 더 많은 가치를 만든 걸 정량적인 근거와 함께 기록을 쌓아간다면? 그러면 이직시에도 도움이 많이 될 것이다! 물경력이 되지 않으려면! 이렇게 해야 할 것이다!

나의 생각

인간의 기억은 무한하지 않다. (물리적으로도 그럴 것이다) 그러나 늙는다고 해서 기억력이 급격히 감소하진 않는다. 이전의 기억들이 소거될 것이다. 내가 살아가고 학습하는 방법이 나의 전체 기억을 바꿀 것이다. 프로젝트 도중 문제 해결했던 부분은 남겨두면 정말 좋은 부분이다.