인터페이스- 모든 메서드가 추상 메서드지만, 다중상속 가능, '선언'만 가지고 있고, '구현' 을 명시적으로 요구함.


추상클래스- 모든 메서드를 추상 메서드로 할 필요 없고, 단일 상속만 가능. '추상메서드의 구현의 강제'


추상클래스는 추상메서드의 강제적 구현을 요구함. 다만 추상클래스는 일반메서드도 포함시킴으로써, 상속할때 일반 메서드는 추상클래스에서 구현하게 돌릴 수 있음


비슷하게 가상 테이블을 활용한 가상 클래스(버츄얼)는 꼭 구현을 강제하지 않더라도, 구현을 하지 않으면 상속받는 버츄얼 클래스에서 구현된거 실행하게함


하지만 이 버츄얼 클래스와 추상클래스는 낮은 추상도를 가지고 있고 OOP에서 상속을 함으로써 사실상 캡슐화를 위반하는 사례가 생길 수 있음.

(상속 구조에 따라서 잘못된 캡슐화가 발생할 수 있음)


다르게 말해서 이 캡슐화가 깨진다는 것은 프로그래머가 프로퍼티와 메서드 기능 범위를 파악하기 어렵게됨


따라서 인터페이스를 추가함으로써 메시징을 강화해서 범위 통제를 강화함


그리고 이 인터페이스를 통한 메시징을 함으로써 객체간의 최소한의 통신을 할 수 있게된거


따라서 일반적으로 최근의 '좋은' 프로그래밍은 인터페이스로 통신하는 걸 권장함. 물론 이거에 더해서 컴포지션도 더해야하는거고


물론 컴포넌트와 추상클래스의 경우에도 기능의 재사용성, 객체 단순화할때 컴포넌트로 분리하긴함. 다만 어쨌건 현대적 프로그래밍에서는 인터페이스는 사실 빠질수가 없긴해.


패턴의 경우에는


패턴을 많이 쓰냐 덜 쓰냐는 걍 패턴을 어디에 쓰는지만 알면 다 쓸 수 있음


MVP같은 코드 아키텍쳐에 빌더 패턴도 메서드 체이닝을 통한 Fluent Builder로 바꿔 쓸 수 있듯이 말이지.


결국 패턴은 일종의 산물이라서 알수록 많이 쓸 수 있는거지 꼭 쓸 필요 없음


그리고 많이 쓰는 패턴은 사람의 성향에 따라 다른거지.


오히려 나의 경우에는 더티 플래그를 제일 많이 쓰는듯.


다만 이부분은 웹분야가 아니라서 뭐라하긴힘든데, 꼭 쓸 필요도 없고 주력 패턴 몇개 정해두면 쉽긴함


다만 패턴도 람다식을 이용해서 쓸 수 있음 


개인의 코드 컨벤션에 따라 전략 패턴은 람다식으로 간단하게 고친다거나, 


커맨드 패턴의 경우도 비슷하게 메서드 참조나 익명함수로 표기할 수 있음


팩토리도 람다식과 딕셔너리를 통해서 더 간단하게 바꿀 수 있음


다만 결국 팀의 컨벤션에 따라서 어떻게 하냐 다른거지 뭐.


기본적으로 로직 캡슐화를 할때 람다식을 많이 쓰지. 다만 이럴 경우 람다식에 해박한 팀원이 존재해야하고 코드 일관성때문에


선호되지 않을뿐. 기본적으로 람다식같은 FP는 코드의 예측가능성을 높일 수 있긴한데, 기본적으로 코드 일관성이라는 또다른 문제와 맞닿뜨릴 수 있음


다만 저런식으로 쓸 경우엔 기본적으로 메모리 사용량을 추가로 사용해서 불필요한 오버헤드가 발생할 수도 있다~ 라는 점도 염두에 두는데


현대적 컴파일러에서는 그정도는 무시해도됨 ㅇㅇ