# 디자인 패턴 > 디자인 패턴은 실제 개발 현장에서 비즈니스 요구 사항을 프로그래밍으로 처리하면서 만들어진 다양한 해결책 중에서 많은 사람들이 인정한 베스트 프랙티스를 정리한 것이다. > 디자인 패턴은 객체 지향 특성과 설계 원칙을 기반으로 구현돼 있다. > 소프트웨어를 설계할 때 특정 맥락에서 자주 발생하는 고질적인 문제들이 또 발생했을 때 재사용할 할 수있는 훌륭한 해결책 > “바퀴를 다시 발명하지 마라(Don’t reinvent the wheel)” # GoF 디자인 패턴 > 23가지의 디자인 패턴을 정리하고 생성(Creational), 구조(Structural), 행위(Behavioral) 3가지로 분류했다. # GoF 디자인 패턴의 분류 > 생성(Creational) 패턴 객체 생성에 관련된 ..
/** 스프링 입문을 위한 자바 객체지향의 원리와 이해 -김종민 지음- */ # SOLID (SRP, OCP, LSP, ISP, DIP) > 객체지향의 특성을 올바르게 사용하는 방법을 설명하는 것이다 > SOLID는 코드에 녹여내야 하는 개념이다 > 리팩터링과 유지보수가 수월하다 > 객체 지향 4대 특성과 객체 지향 설계 5원칙, 디자인 패턴은 객체지향의 중요한 개념이다. # SRP - 단일 책임 원칙 "어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다." - 로버트 C.마틴 > 단일 책임 원칙은 역할을 분리하는 것이다. 클래스의 역할과 책임에 따라 분리하여 기능에 변화가 있더라도 영향을 받지 않는다는 장점이 있다. > SRP는 A클래스와 B클래스에 공통점이 없다면 C(부모 클래스)를 제거하면 ..
1. 다중상속에 관하여 인터페이스는 여러 부모클래스의 메소드를 이어 받을수 있다. 추상 클래스는 상속을 강제하기 때문에 단일 상속밖에 받지 못한다. 그렇다면 상속이랑 추상클래스의 차이점은 뭔가? 동장 방식이 똑같이 않냐? 언제 사용할까? (사용용도) 자바에는 추상클래스라는 클래스가 있다. 우리가 알고 있는 클래스와는 달리 일종의 미완성의 클래스이다. 보통 클래스가 new로 인스턴스를 생성할 수 있지만, 추상클래스는 그것이 불가능하다. 오직 상속을 통해서 자손 클래스에 의해서만 완성되는 클래스이다. 그럼 이런 미완성 클래스가 무슨 역할을 할까? 단독으로는 아무 역할을 못한다. 그러나 새로운 클래스를 작성하는데 밑바탕이 되는 역할을 할 수 있다. 새로운 클래스 작성 시 아무것도 없는 상태에서 시작하는 것보다..
# 목표 > 상속과 구현(인터페이스)의 차이점을 단순한 이론 정의에서 끝나는 것이아닌 사용용도 및 장,단점 측면에서 이해해 보자! # 의문점?! > 상속과 구현은 둘다 다형성을 구현하기 위해 사용이 되고 사용방법도 비슷하다. > 상속과 구현의 차이점이 무엇일까? # 관점1) 다중상속 상속은 다중상속을 지원하지 않고 인터페이스는 다중상속을 구현할 수 있다. 하지만 오늘 접근하고자 하는 목적은 다중상속과는 관련이 없다 # 관점2) 변화 상속과 조합(composition)의 차이점과 리스코프 치환 원칙(LSP)에 대해 공부를 하면 정답을 유추할수 있다고 생각한다. 나의 생각을 바로 이야기 한다면 상속은 코드를 하위 클래스에 공유하기 때문에 변화에 취약할수 밖에 없다. 반면 인터페이스는 코드를 하위 클래스와 공..
# 목표 1. 객체지향에서 다형성이 어떻게 사용이 되는지 이해하기! 2. 다형성은 객체나 인터페이스 또는 추상과 같이 철학적인 느낌으로 이해하는 것은 혼란을 느낄수 있다고 생각합니다. 그래서 코드 상에서 구체적으로 어떤 모습으로 드러나는지에 집중하고자 하였습니다. # 다형성이란? > 다형성은 여러 객체에게 동일한 명령을 내렸을 때 서로 다르게 반응하는 현상을 의미합니다. > 자바에서는 다형성을 이용하여 객체를 사용할 때 사용하는 변수 형태를 바꾸어 여러 타입의 객체를 참조할 수 있습니다. 결과적으로 이러한 다형성의 개념을 적절하게 이용할 때 프로그램의 소스 코드를 유연하게 구성할 수 있습니다. /** 우테코 블로그 참조(코드) */ https://woowacourse.github.io/javable/po..
/** 참고(Reference) https://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented https://brunch.co.kr/@artiveloper/20 */ # 스몰톡크에서 정의한 객체 더보기 1. Everything is An Object. 2. Objects communicate by sending and receiving messages (in terms of objects). 3. Objects have their own memory (in terms of objects). 4. Every object is an instance of a class (which must be an object). 5. The class holds the shared b..
/** 참조 (Reference) 99% 복사한 내용입니다! http://everdeenoop.blogspot.com/2017/01/java-bdd.html 참조하면 괜찮을 것 같은 블로그! 아직 안 읽음 https://mono9.tistory.com/3 */ # 객체 - 앨런케이의 정의(1) > 객체에 대해 이해하기 위해 블로그 내용을 요약! # 공부 목표 > 객체지향 프로그래밍의 선구자로 알려진 알런케이는 객체를 어떻게 정의 했는지 알아보자 > 객체지향 프로그래밍에 대한 블로그나 설명은 많지만, 누가 어떤 의도로 만들었는지 알아보는 것이 목표 # 앨런케이 - 객체지향 프로그래밍에 대한 정의 "하나의 시스템을 서로 상호작용하는 객체로 이루어져 있다고 보는 것이며, 객체들끼리는 메시지로 서로 협력한다."..
/** UML 다이어그램의 종류에 대한 내용은 없습니다. */ # UML다이어그램 > UML다이어그램은 통합 모델링 언어를 사용하여 시스템 상호작용, 업무흐름, 시스템 구조, 컴포넌스 관계 등을 그린 도면이다. # 사용 이유 > 의사소통 또는 설계 논의를 위해 > 전체 시스템의 구조 및 클래스의 의존성 파악을 위해 > 유지보수를 위한 설계의 back-end 문서 제작을 위해 # 단점 UML 다이어그램에서 누가 이익을 얻는 지 항상 명확하지는 않습니다. Eiffel Software 웹 사이트에 실린 기사에 따르면 UML은 소프트웨어 개발자에게 유리하지 않습니다. 주로 소프트웨어 개발자가 그림이나 다이어그램이 아닌 코드로 작업하기 때문입니다. UML 다이어그램은 프로젝트 관리자 또는 임원이 소프트웨어 도구의..