일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- Kubernetes Engine
- Cloud Bigtable
- 리버스 프록시
- AWS Solution Architect
- Cloud SQL
- 앤서블
- AWS Database
- AWS Certificate
- kubernetes
- Cloud Spanner
- AWS
- Cloud Storage
- Amazon Web Service
- Google Cloud Platform
- playbook
- gcp
- Solution Architect
- GKE
- ansible
- container
- Google Cloud Platrofm
- 아마존웹서비스
- Solution Architect Certificate
- AWS 자격증
- Cloud Datastore
- Reverse Proxy
- Compute Engine
- Google Cloud
- Google Cloud Platorm
- VPC
- Today
- Total
목록development (42)
sungwony
Chain of responsibility 책임 연쇄(Chain of responsibility) 패턴이란 무엇입니까?- 명령 객체와 일련의 처리 객체를 포함하는 디자인 패턴- 각각의 처리 객체는 명령 객체를 처리할 수 있는 연산의 집합이고, 체인 안의 처리 객체가 핸들할 수 없는 명령은 다음 처리 객체로 넘겨진다. Chain-of-responsibility pattern의 클래스 다이어그램 예시 소스보기 Advanced* 요구하는 사람과 요구를 처리하는 사람을 유연하게 연결한다* 동적으로 사슬의 형태를 바꾼다* 자신의 일에 집중할 수 있다* 떠넘기기로 처리가 지연될 가능성은?
Visitor Pattern 방문자 패턴(Visitor Pattern)이란 무엇입니까?- 방문자 패턴에서는 데이터의 구조와 처리를 분리합니다. 데이터 구조 안을 돌아다니는 주체인 '방문자'를 별도의 클래스로 준비해서 그 클래스에게 처리를 위임합니다. Visitor Pattern의 클래스 다이어그램 예시 소스보기 Advanced* 더블 디스패치(double dispatch) * 처리를 데이터 구조에서 분리* OCP(Open-closed Principle)* ConcreteVisitor 역할의 추가는 간단하다* ConcreteElement 역할의 추가는 곤란하다
Decorator Pattern 장식 패턴(Decorator Pattern)이란 무엇입니까?- 주어진 상황 및 용도에 따라 어떤 객체에 책임을 덧붙이는 패턴- 기능 확장이 필요할 때 서브클래싱 대신 쓸 수 있는 유연한 대안이 될 수 있다 Decotrator Pattern 클래스 다이어그램 예시 소스보기 Advanced* 투과적인 인터페이스(API)* 내용물을 바꾸지 않고 기능을 추가한다.* 동적인 기능을 추가한다* 단순한 장식이라도 다양한 기능을 추가할 수 있다. (참고 : http://gdtbgl93.tistory.com/9)* java.io 패키지와 Decorator 패턴* 작은 클래스가 증가한다.
Template Method 패턴 - 템플릿(형판)의 기능을 가진 패턴 - 템플릿에 해당하는 메소드가 정의되어 있고, 그 메소드의 정의 안에는 추상 메소드가 사용된다. - 상위 클래스의 관점에서 추상 메소드를 어떻게 호출하는지 알 수 있지만 어떤 처리가 이뤄지는지는 알 수 없다. - 하위 클래스에서 추상 메소드를 구현하고 상위 클래스의 템플릿에 의해 호출이 이루어진다. 이름 해설 AbstractDisplay 메소드 display만 구현되고 있는 추상 클래스 CharDisplay 메소드 open, print, close를 구현하고 있는 클래스 StringDisplay 메소드 open, print, close를 구현하고 있는 클래스 Main 동작 테스트용 클래스 package TemplateMethod; p..
디자인 패턴이란? - 소프트웨어를 설계할 때 특정 맥락에서 자주 발생하는 고질적인 문제들이 발생했을 때 재사용할 수 있는 훌륭한 솔루션- '콘텍스트(context)', '문제(problem)', '해결(solution)' 이라는 3개의 필수 요소로 구성된다- 콘텍스트 : 문제가 발생하는 여러 상황. 즉, 패턴이 적용될 수 있는 상황을 나타낸다.- 문제 : 패턴이 적용되어 해결될 필요가 있는 여러 디자인 이슈들. 제약 사항과 영향력도 문제 해결을 위해 고려해야 한다.- 해결 : 문제를 해결하도록 설계를 구성하는 요소들과 요소들 사이의 관계, 책임, 협력 관계를 기술한다.- 디자인 패턴은 서로의 의사소통을 원활하게 할 수 있다. ex) 클래스 객체를 하나만 생성하면 좋겠는데 public을 private이나 ..
1. OOP&UML 2. SOLID 원칙 3. 디자인패턴 4. Iterator - 순서대로 지정해서 처리하기 5. Adapter - 바꿔서 재이용하기 6. Template Method - 하위 클래스에서 구체적으로 처리하기 7. Factory Method - 하위 클래스에서 인스턴스 만들기 8. Singleton - 인스턴스를 한 개만 만들기 9. Prototype - 복사해서 인스턴스 만들기 10. Builder - 복잡한 인스턴스 만들기 11. Abstract Factory - 관련 부품을 조합해서 제품 만들기 12. Bridge - 기능 계층과 구현 계층 분리하기 13. Strategy - 알고리즘을 모두 바꾸기 14. Composite - 그릇과 내용물을 동일시하기 15. Decorator - 장..
Adapter 패턴 - 이미 제공되어 있는 것을 그대로 사용할 수 없는 경우 '이미 제공되어 있는 것'과 '필요한 것' 사이의 간격을 메우는 디자인 패턴- Wrapper 패턴으로도 불린다 전원의 비유 예제 프로그램 제공되고 있는 것 교류 100 볼트 Banner 클래스(showWithParen, showWithAster) 교환장치 어댑터 PrintBanner 클래스 필요한 것 직류 12볼트 Print 인터페이스(printWeek, printStrong) 상속(inheritage)을 이용한 Adapter패턴 Banner 클래스 public class Banner { private String string; public Banner(String string){ this.string = string; } pu..
Iterator 패턴 Aggregate 인터페이스 public interface Aggregate { public abstract Iterator iterator(); } Iterator 인터페이스 public interface Iterator { public abstract boolean hasNext(); public abstract Object next(); } Book 클래스public class Book { private String name; public Book(String name){ this.name = name; } public String getName() { return name; } } BookShelf 클래스public class BookShelf implements Aggreg..
객체지향 모델링 - 객체지향에 기반한 소프트웨어의 모델을 객체지향 모델이라고 하고, 모델을 만드는 과정을 모델링이라고 한다- 소프트웨어 시스템 또는 앞으로 개발할 소프트웨어의 원하는 모습을 가시화하는데 도움을 준다.- 소프트웨어 개발시 모델을 통해 서로의 해석을 공유해 합의에 이루거나 해석의 타당성을 검토할 수 있다.- 모델링은 추상화에 바탕을 두어야 한다.(필요한 부분과 불필요한 부분을 관점에 따라 구분) 객체지향 원리 - 추상화 : 사물의 공통된 특징, 추상적 특징을 파악해 인식의 대상으로 삼는 행위- 캡슐화 : 정보은닉을 통해 높은 응집도와 낮은 결합도를 갖도록 하는 행위- 일반화(generalization) : 객체지향 프로그래밍의 상속 관계(is a kind of) 일반적으로 속성이나 기능의 재..
객체지향 프로그래밍에서, 부가적인 기능들을 각각 독립적인 클래스로 작성할 수 있지만 그렇게 구현된 기능들을 호출하고 사용할 때는 결국 비지니스 로직이 담긴 핵심 모듈 안에 이런 부가적인 기능을 호출하는 코드들이 포함될 수 밖에 없다. 예를들어 로그와 관련된 코드가 각 메소드의 시작 부분에 작성되고, 전체적으로 수백개의 메소드에 모두 해당 호출부가 들어있다면 호출방식의 변경이 이뤄졌을 경우 모든 메소드의 호출부분을 수정해야 한다. 이에 따른 문제점들을 정리하면 다음과 같다. 1. 코드가 중복됨- COPY&PASTE2. 코드가 지저분해짐- 핵심기능과 부가적인 기능이 혼재3. 생산성이 저하됨- 소스의 양이 늘어나고 개발의 집중도가 분산4. 재활용성이 저하됨5. 변화가 어려움- 서로 다른 모듈간의 결합도가 높아..