자바

JavaSE(Java Standrad Edition)

• 흔히 말하는 자바를 JavaSE라고 하면 기본적인 패키지(java.leng.*…)을 제공

JavaEE(JAVA Enterprice Edition)

• JavaSE를 확장한 에디션으로 SE기능을 포함한 sevelet, EJB, JSP 등.. 을 포함한 에디션, 무겁다는 단점이 있음

EJB(Enterprice Java Bean), 프로그래밍

• 기업환경의 시스템을 구현하기 위한 서버측 컴포넌트 모델이다. 즉 애플리케이션의 업무 로직을 가지고 있는 서버 애플리케이션이다.
• JSP는화면 로직을 처리하고, EJB는 업무로직을 처리하는 역활을 한다.(Enterprice Bean, Container, EJB server, Client Application)
• 불필요할만큼 과도한 엔지니어링으로 실패한 대표적인 케이스 1%의 기능을 위해 99% 기능까지 무거운 기능을 사용해야함

POJO(Plain Old Java Object), 프로그래밍

• 무거운 EJB와는 반대로 경량의 자바 객체를 강조하며 특정 규약에 종속되지 않고 특정 환경에 종속되지 않고 객체지향원리에 충실해야 한다.
• Java Bean : POJO의 대표적인 예로 기본 생성자와 맴버 필드에 접근할 수 있는 Getter/setter 메소드를 가진 단순 자바 오브젝트
• POJO 프레임워크 : 하이버네이트, 스프링
• 진정한 POJO란 객체지향적인원리를 충실하며서, 환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 말한다.

Java 프로그램의 종류

• Java 어플리케이션
  • Java 어플리케이션은 JVM이 설치되어 있으면 웹부라우저 밖에있어도 독립적으로 실행 가능한 프로그램이다.
  • Applet이 웹브라우져안에서 실행되는 반면에 Java 어라플리케이션은 웹브라우져 밖에서도 독립적으로 실행이 가능하다.
• Applet
  • 서버에서 클라이언트로 클래스파일이 전송된 후 실행되는 작은 프로그램으로 웹브라우저 안에서만 작동이 되며 보통 멀티미디어 효과(애니메이션, 시계, 달력 등)를 내기위해서 사용된다
  • Servlet이 서버쪽에서 실행하고 클라이언트에서 보내주는 반면에 Applet은 클라이언트에서 실행을 하고 실행할때마다 서버에서 다운을 받아 실행시킨다.
• Servlet
  • 자바기반으로 만드는 웹 어플리케이션 프로그래밍 기술로 Server와 Applet의 합쳐진 의미로 CGI프로그램과 같이 웹 서버 프로그램의 기능을 확장하기 위한 프로그램이다.
  • URL요청이 오면 컨테이너가 HttpServletResponse와 HttpServletRequest 객체를 생성한다. 그 후 URL을 분석 후 어떤 서블릿을 요청한지 확인하고 그 다음에 서블릿 스레드를 생성해 Request, Response 참조를 넘긴다.
  • servlet컨테이너로 관리가 되며 servlet을 실행하고 관리하는 역활을 해주기 때문에 url요청이 오면 servlet컨테이너를 통해서 service() 호출되어 동작된다.
  • Applet은 브라우저에서 돌아가는 작은 프로그램이라고 하면 Servlet은 서버에서 돌아가는 프로그램을 의미한다.
• Stream 과 Writer
  • Stream은 자료의 입출력을 도와주는 중간매개체로 입력과 출력이 관련된 곳이면 어디든 동작합니다
  • Stream은 크게 두가지 나누어 지는데 바이트 단위(InputStream, OutputStream)와 문자 단위(Reader,Writer) 입니다.
• JSP 로부터 만들어진 Servlet 소스 분석
  • JSP의 page지시자는 response객체의 setContentType 메소드로 contentType을 설정, HTML로 작성한 코드들은 jsp객체들이 자동으로 생성(request, response, pageContext, session, application, out, config , page ) 되고 out 출력스트림을 통해 write 함수를 호출해서 응답할 HTML 텍스트를 전달하는 구조로 되어있다.

• request : 요청을 처리하는 객체

• response : 응답을 처리하는객체

• pageContext : jsp페이지와 관련 컨텍스트 정보를 담고 있는객체

• session : 세션관리를 위한 객체

• application : 컨텍스트의 범위의 공유되는 데이터를 담고 있는 객체

• out : 브라우져로의 출력 스트림을 담당하는 객체

• config : 서블릿이 초기화 하는 동안 참조해야 할 정보를전달해주는 객체

• page : this, 서블릿 자신의 객체

• 컨텍스트 : 같은 웹 응용 프로그램에 소속된 서블릿과 JSP 프로그램들은 실행환경을 서로 공유하며 이러한 환경을 컨텍스트라고함, 이런 컨텍스트를 통해 서블릿과 JSP는 데이터 공유가 가능함
• 브라우저는 Tomcat 에게 http Get또는 Post 방식으로 요청을 보내면 해당 객체를 서블릿 컨테이너에서 찾고 없을경우 JSP 파일을 서블릿 파일로 변환, 서블릿 파일을 클래스 파일로 컴파일 하여 서블릿 컨테이너에 로딩하여 브라우저로 응답함

멤버변수

• 선언한 위치가 클래스 영역
• 클래스변수
  • 변수 타입 앞에 static이 붙는다 모든 객체에 적용
  • 서버 종료시 메모리에서 해제된다.
• 인스턴스 변수
  • 입력값에 따라 수정이 가능
  • 해당 객체에 참조가 없는경우 GC의해 해제된다.

지역변수

• 선언한 위치가 메소드나 생성자 위치
• 메소드 내에서만 사용이 가능하며 메소드가 종료되면 자동으로 소멸된다.

.equals와 == 차이

• equals는 다른 인스턴스 값이(내용) 같으면 true를 반환 == 같은 인스턴스인지를 검사.

.equals에서 두객체가 같은지 여부는 어떻게 확인할까

• 내부적으로 hashCOde 메소드를 기반으로 두객체가 같은지 판단한다.
• String의 경우 hashCode 함수가 주소 값이 아닌 문자열을 해싱한 값을 리턴한다.

hashCode

• 두 객체가 같은 객체인지 확인하는 메소드

원시 타입(primitive type)

• 8가지의 기본형 타입을 미리 정의하여 제공
• 실제 값을 저장하는 공간으로 Stack 메모리에 저장된다.
• boolean, byte, short, int, long, float, double, char
• 기본값이 있기 때문에 null이 존재하지 않음 래퍼 클래스를 활용(??)

참초형 타입(reperence type)

• 기본형 타입을 제외한 타이들이 모두 참조형 타입
• 빈 객체를 의미하는 null이 존재함
• 값이 저장되어 있는곳의 주소값을 지정하는 공간으로 힙 메모리에 저장된다.
• 정적으로 할당된 스택의 메모리의 참조 값을 힙에 넘겨 값을 쓸 수 있게 동적으로 만들어줌

char, String 나눠진 이유

• 자바에서 char배열이 아닌 String 클래스를 이용해서 문자열을 처리하는 이유는 편의성과 연관이 있다.
• String 클래스가 char배열에 여러가지 기능을 추가하여 확장한 것으로 char[]배열을 사용하면 편의성의 많이 떨어짐

프로세스

• 운영체제로부터 자원을 할당받은 작업의 단위

스레드

• 프로세스가 할당받은 자원을 이용하는 실행단위

객체 지향

• 연관 관계
  • 객체관 연관이 있는 경우 실선으로 표현,어떤 연관관계가 있는지 표시하고 역활까지 표시 확실할땐 표시하지 않을 수 있음, 오랜 기간동안 같이 할 객체와의 관계
• 의존 관계
  • 짧은 시간 동안 이용하는 관계, 점선
  • 단방향은 화살표로 표시 하며 참조되는 객체 참조하는 객체를 전혀 몰라도 된다. 참조하는 객체에서만 연관 관계를 가져야 된다.
  • 다대다 연관 관계는 보통 일대다, 단방향으로 변환해서 사용하는데 그 전에 연관 클래스를 찾아 하나의 객체를 더 추가해서 관계를 변환 시킬 수 있다.
• 일반화 관계
  • 한 클래스가다른 클래스를 포함하는 상위의 개념일 때 두 클래스 사이에는 일반화 관계가 존재 한다. 일반화 관계가 존재할떄 자식 클래스는 부모 클래스로부터 속성과 연산을 물려 받는다. 자식 is a kind of 부모, 실선에 빈 화살표로 표현
• 집합 관계
  • 전체와 부분의 관계를 명확하게 명시하고자 할 때 사용한다. 집약과 합성 두 종류의 집합 관계가 존재한다.
  • 집약
    • 한 객체가 다른 객체를 포함하는 것을 나타낸다. 전체, 부분 과의 관계며 전체를 가리키는 클래스 방향에 빈 마름모로 표시한다. 전체와 부분과의 라이프타입은 독립적으로 전체가 사라져도 부분은 남아 있는다.
  • 합성
    • 전체를 가리키는 클래스 방향에 채워진 마름모로 표시되며 부분 객체가 전체 객체에 속하는 관계이다. 전체 객체가 사라지면 부분 객체도 사라지며 공유 할 수 있는 객체를 사용할 경우에는 합성이 아닌 집약을 사용한다. 이떄의 부분객체의 라이프타임은 전체 객체의 라이프 타임에 의존한다.

기본적인 자료구조 Interface 종류

• Collection
  • 목록성 데이터를 처리하는 자료구조를 말한다.
  • 간단하게 하면 데이터의 집합, 그룹을 의미하고 Set, List, Queue등이 Collection 인터페이스를 구현화 하고 있다.
• List
  • 순서가 있는 데이터의 집합으로 데이터 중복을 허용한다.
  • 배열과 List의 구조는 비슷하지만 배열은 크기가 고정되있고 List는 가변적 길이를 가진다.
• Set
  • 순서를 유지하지 않는 데이터의 집합으로 중복 데이터를 허용하지 않으며 자동으로 제거를 합니다.
• Map
  • Map은 키(Key)와 값(value)으로 이루어져 있으며 모든 데이터는 키와 값이 존재하고 키와 값중 하나라도 없다면저장을 할 수 없다.
  • Map의 경우 Collection을 상속받고 있지 않지만 Collection으로 분류됩니다.

인터페이스와 실체화

• 인터페이스
  • 인터페이스란 책임 이다. 어떤 객체의 책임이란 객체가 해야 하는 일로서 해석할 수 있고 어떤 경우에는 객체가 할 수 있는 일로도 해석할 수 있다. 즉 외부에 제공하는 서비스나 기능은 객체가 수행하는 책임으로보는 것이다.
• 일반화 관계
  • 상속체 can do this 인터페이스
• 추상화
  • 어떤 영역에서 필요로 하는 속성이나 행동을 추출하는 작업을 의미한다. 사물들의 공통된 특징, 집합을 구성하는 개체들을 일반화 하는 것으로 보편적인 것이다
• 캡슐화
  • 낮은 결합도를 유지할 수 있도록 해주는 객체지향 설계 원리이다. 정보 은닉을 통해 높은 응집도와 낮은 결합도를 갖도록 한다.
  • 정보 은닉
  • 알 필요가 없는 정보는 외부에서 접근하지 못하도록 제한하는 것이다.
  • 소프트웨어는 결합이 많을수록 문제요소가 많아진다. 정보 은닉을통해 프로스세가 작동할때 다른 객체들의 정보를 알지 못해도 동작하는데 문제가 생기지 않도록 객체의 응집도를 높히고 객체간 결합도를 낮추도록 한다.
  • 요구사항이 변경됐을때 하나의 기능이 수정돼도 각 기능별 응집도는 높고 결합도는 낮기 떄문에 해당 기능만 교체 해주면 나머지 기능들은 기존대로 작동을 할 수 있다.
  • 일반화는 또다른 캡슐화이다
• 위임
  • 일반화 관계는 is a kind of 관계가 성립되어야한다. 일반화는 모든것을 상속 받기 때문에 필요 없는 부분들이 생긴다. 그래서 일부 기능만 사용하려고 할때는 위임을 사용한다. 위임은 직접 기능을 실행하지 않고 다르클래스의 객체가 기능을 실행하도록 위임하는 것이다. 일반화는 클래스 사이의 관계지만 위임은 객체 사이의 관계이다.
  • 자식 클래스에 부모 클래스의인스턴스를 참조하는 속성을 만든다 이 속성 필드는 this로 초기화 한다.
  • 서브 클래스에 정의된 각 메서드에 1번에서 만든 위임 속성 필드를 참조하도록 변경한다.
  • 서브 클래스에서 일반화 관계 선언을 제거하고 위임 속성 필드에슈퍼 클래스의 객체를 생성해 대입한다
  • 서브 클래스에서 사용된 슈퍼 클래스의 메서드에도 위임 메서드를 추가한다.
  • 컴파일하고 잘 동작하는지 확인한다.
  • 정리
    • 상속을 받지 않고 전역 변수로 선언 후 해당 전역변수에서 필요한 기능들만 사용 전역변수에 기능을 위임해서 사용한다.
• 다향성
  • 서로 다른 클래스의 객체가 같은 메시지를 받았을 때 각자의 방식으로 동작하는 능력이다. 다향성은 일반화 관계와 함께 자식 클래스를 개별적으로 다룰 필요 없이 한 번에 처리할 수 있게 한다. 추상 메소드를 각각 상송받은 클래스가 자신에 맞게 정의함

피터 코드의 상속 규칙

• 자식 클래스와 부모 클래스 사이는 역활 수행 관계가 아니어야 한다.
  • ex) 사람(부모), 운전자, 회사원 : 역활중 하나를 표현하기 때문에 X
• 한 클래스의 인스턴스는 다른서브 클래스의 객체로 변환할 필요가 절대 없어야 한다.
  • ex) 사람(부모), 운전자, 회사워 : 출근할땐 운전자였다가 회사에 도착하면 회사원이 될수 있기 때문에 X
• 자식 클래스가 부모 클래스의 책임을 무시하거나 재정의하지 않고 확장만 수행해야 한다.
  • ex) 사람(부모), 운전자, 회사워 : 어떤 속성과 연산이 정의되었는지 정보가 없기 때문에 점검할수 없음
• 자식 클래스가 단지 일부 기능을 재사용할 목적으로 유틸리티 역할을 수행하는 클래스를 상속하지 않아야 한다.
  • ex) 사람(부모), 운전자, 회사워 : 기능만을 재사용할 목적이 아니므로 적합
• 자식 클래스가 역할, 트랜잭션, 디바이스 등을 특수화 해야 한다.
  • ex) 사람(부모), 운전자, 회사워 : 슈퍼 클래스가 역할, 트랜잭션, 디바이스를 표현하지 않았기 때문에 X
  • ex) 사람(부모), 운전자, 회사워 : 집약 혹은 연관 관계를 사용해 클래스 사이의 관계를 표현하는 편이 좋다.

SOLID 원칙

• 단일책임 원칙(SRP,Single Responsibility Principle)
  • 소프트웨어 설계 첫 번째 원칙으로 단 하나의 책임만을 가져야 한다.
  • 책임의 기본 단위는 객체를 지칭한다. 즉 객체는 단 하나의 책임만 가져야 한다.
  • 책임은 해야 하는 것, 할 수 있는 것으로 간주되고 객체에 책임을 할당할땐 어떤 객체보다도 작업을 잘 할수 있는 객체어야 한다.
  • 객체는 책임에 수반되는 모든 일을 자신만이 수행 할 수 있어야 한다.
  • 잘 설계 되어 있는지 확인할떈 언제 변경되어야 하는지를 물어보는 것이 좋다.
    • 책임 = 변경 이유
    • DB 스키마가 변경되었을때 변경되어야 하는가?? ~기능이 추가되었을떄 영향을 받는가?? 등..
    • 해당 객체는 고유의 역활만 수행하게끔 변경하고 저장 및 읽어드리는 역활은 분리한다. ex) DAO
  • AOP 사용
• 개방-폐쇄 원칙(OCP,Open-Closed Principle)
  • 기존의 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계가 되어야 한다는 뜻이다.
    • 기존의 클래스가 영향을 받지 않게 하려면 특정한 클래스가 개별적으로 처리하지 않게 하고 인터페이스를 사용함으로써 구체적인 출력 매체를 캡슐화해서 사용한다.
  • 클래스를 변경하지 않고도(closed) 대상 클래스의 환경을 변경할 수 있는(open) 설계가 되어야 한다.
  • 인터페이스를 활용하여 기존 기능을 유지한 상태로 기능을 추가한다.
• 리스코프 치환 원칙(LSP,Liskov Substitution Principle)
  • 일반화 관계에 대한이야기며 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다는 뜻이다.
  • LSP를 만족하면 프로그램에서 부모 클래스의 인스턴스 대신에 자식 클래스의 인스턴스로대체해도 프로그램의 의미는 변화되지 않는다.
  • 부모 클래스와 자식클래스 사이는 행위가 일관되어야 한다.
  • LSP를 만족시키는 간단한 방법은 재정의 하지 않는 것이다.
• 의존 역전 원칙(DIP,Dependency Inversion Principle)
  • 객체 사이에 서로 도움을 주고 받으면 의존 관계가 발생한다. 의존 역전 원칙은 그러한 의존 관계를 맺을 때의 가이드라인에 해당한다.
  • 의존 관계를 맺을 때 변화하기 쉬운 것 또는 자주변화하는 것보다 변화하기 어려운것, 거의 변화가 없는 것에 의존하라는 원칙이다.
  • 정책, 전략과 같은 어떤 큰 흐름이나 개념 같은 추상적인 것은 변하기 어려운 것에 해당하고 구체적인 방식, 사물 등과 같은 것은변하기 쉬운 것으로 구분하면 좋다.
  • ex) 장난감을 가지고 논다 : 장난감을 가지고 논다는 변하기 어려운 것이며 장난감은 종류가 변경될 수 있으므로 변하기 쉽다.
  • 인터페이스는 변하지 않는 것, 구체 클래스(abstract)는 변하기 쉬운것
• 인터페이스 분리 원칙(ISP,Interface Segregation Principle)
  • 클라이언트 자신이 이용하지 않는 기능에는 영향을 받지 않아야 한다.
  • ex) 복합기 : 여러 기능이 있는데 하나의 기능이 변경이 되도 다른 기능엔 영향이 없음
  • 클라이언트 자신이 영향을 받지 않으려면 범용의 인터페이스보다는 클라이언트에 특화된 인터페이스를 사용해야 한다.
  • 복합기를 예로 들면 각 기능에 대한 인터페이스를 만들어 자신이 관심을 갖는 메서드들만 있는인터페이스를 제공받도록 설계해야 한다.
  • SRP를 만족하더라도 ISP를 반드시 만족한다고는 할 수 없다.

디자인 패턴

• 스트래지티 패턴
  • 전략을 쉽게 바꿀 수 있도록 해주는패턴
  • 추상 클래스의 메소드를 인터페이스로 위임해서 기능 변화에 유연하게 해줌
  • Strategy : 인터페이스나 추상 클래스로 외부에서 동일한 방식으로 알고리즘을 호출하는 방법을 명시한다.
  • ConcreteStrategy1,2,3 : 스트래티지 패턴에서 명시한 알고리즘을 실제로 구현한 클래스다.
  • Context : 스트래티지 패턴을 이용하는 역활을 수행한다. 필요에 따라 동적으로 구체적인 전략을 바꿀 수 있도록 setter 메서드를 제공한다.
• 싱글턴 패턴
  • 인스턴스가 오직 하나만 생성되는 것을 보장하고 어디서든 이 인스턴스에 접근할 수 있도록 하는 디자인 패턴이다.
  • static 클래스로 객체를 만들고 생성자는 private로 객체 내부에서만 생성되도록 함
  • static 메소드를 통해 객체가되지 않았을 경우만 생성되도록 선언함
  • 다중 쓰레드
    • 정적 변수에 인스턴스를 만들어 초기화 한다. 리턴 값은 생성된 하나의 인스터스만 리턴함
    • getMethod 에 synchronized를 붙여 메서드 동기화를 시킴
    • 카운터를 할 경우 synchronized를(this){} 를 통해 하나의 스레드만 접근을 허용함
• 스테이트 패턴
  • 특정 상태에 따라 행위를 달리하는 상황에서 자신이 직접 상태를 체크하여 상태에 따라 행위를 호출하지 않고 상태를 객체화 하여 상태가 행동할수 있도록 위임하는 패턴이다.
  • 객체의 특정 상태를 클래스로 선언하고, 클래스에서는 해당 상태에서 할수있는 행위들을 메소드로 정의한다. 그리고 이러한 각 상태 클래스들을 인터페이스로 캡슐화 하여 클라이언트에서 인터페이스르 호출하는 방식을 말한다.
  • 스트래지티 패턴과 의 차이점은 스트래지티 패턴은 상속을 대체하고 스테이트 패턴은 조건문을 대체한다.
• 스트래지티 패턴과 스테이트 패턴 차이
  • 스테이트는 스테이트에 따른 로직에 끝에 setState(new State())를 호출함으로서 상태를 변화실킬수 있다
  • 스트래지티의 경우에는 외부에서 데이터의 입력이 필요하다. 스트래지티는 어떤 Concrete Class를 할당할지 Client 혹은 사용자가 결정해야 한다
  • 스테이트 패턴은 현재 선풍기가 Off 상태이브로 강픙버튼을 누른다면 On 상태로 상태전이를 하면서 선풍기르 돌리는 것이고 On 상태에서 강풍 버튼을 누른다면 이미 On State이므로 아무런 상태 전이가 없다는 점이다.
  • 스트래지트는 행동을 소유한 객체를 실행시 선택할수 있게 하여 상황에 맞는 행동을 하게 한다
    • 공격(주먹, 발차기), 움직임(걷기, 날기)
• 커맨드 패턴
  • 이벤트가 발생했을 떄 실행될 기능이 다양하면서도 변경이 필요한 경우에 이벤트를 발생시키는 클래스를 변경하지 않고 재사용하고자 할 떄 유용하다.
  • 커맨드 인터페이스를 만들어 어떤 기능이 추가 되었을떄 커맨드 인터페이스를 상속받은 상속체를 통해 기능을 실행하도록 함.
  • Command : 실행될 기능에 대한 인터페이스, 실행될 긴능을 execute 메서드로 선언함. ex) 인터페이스
  • ConcreteCommand : 실제로실행되는 기능을 구현, 즉 Command라는 인터페이스를 구현하는 구현체, ex) 인터페이스 구현체
  • Invoker : 기능의실행을 요청하는 호출자 클래스, ex) 버튼
  • Receiver : ConcreteCommand에서 excute 메서드를 구현할 때 필요한 클래스, 즉 ConcreteCommand의 기능을 실행하기 위해 사용하는 수신자 클래스, ex) 램프, 경적 등.. 기능을 가지고 있는 클래스

템플릿 메서드 패턴

• 전체적으로는 동일하면서 부분적으로는 다른 구문으로 구성된 메서드의 코드 중복을 최소화 할때 유용하다
• 동일한 기능을 상위 클래스에서 정의하면서 확장/변화가 필요한 부분만 서브 클래스에서 구현할수 있도록 한다.
• 동일한 기능을 구현하면서 각 하위 클래스에서 구체적으로 정의할 필요가 있는 부분의 메서드 부분만 하위 클래스에서 오버라이드 되로록한다 부모 요소의 동일 기능이 있는 메서드를 템플릿 메서드라고 부르고 오버라이드될 필요가 있는 메서드(템플릿 메서드 안에서 호출되는 메서드)를 primitive, hook 메서드라고 부른다.

팩토리 메서드 패턴과

• 객체 생성을 캡슐화 하는 패턴으로, 객체 생성 코드를 별도의 클래스/메소드로 분리함으로써 객체 생성의 변화에 대비하는데 유용하다.
• Create의 서브클래스에 팩토리 메소드를 정의하여, 팩토리 메소드 호출로 적절한 ConcreteProduct 인스턴스를 반환하게 한다.
• Product
  • 팩토리 메서드로 생성될 객체의 공통 인터페이스
• ConcreteProduct
  • 구체적으로 객체가 생성되는 클래스
• Creator
  • 팩토리 메서드를 갖는 클래스
• ConcreteCreator
  • 팩토리 메서드를 구현하는 클래스로 ConcreteProduct 객체를 사용
• 팩토리 클래스(추상 클래스)를 상속받는 팩토리(클래스)를 만들어 인자값으로 넘어온 객체를 생성한다.
• ex)
  • Robot : 로봇 객체 추상 클래스
  • superRobot : 로봇 객체를 상속 받는 로봇 객체가
  • RobotFactory : 기본 팩토리 클래스로 로봇 객체를 생성해준다 추상클래스
  • superRobotFactory : 기본 팩토리 클래스를 상속 받아 실제 로직을 구현한 팩토리
  • 해당 흐름이 중요 큰틀은 변하지 않고 세부 내용들은 변화함
  • 팩토리라는 공장을 만들어 객체들을 생생한다고 생각하면 된다. 업무에 활용한다면 휴가를 쓸때 활용이 가능해 보임 휴가를 추가할때 List로 항상 가지고 있으며 쓸때마다 추가

추상 팩토리 패턴

• 서로 관련이 있는 객체들을 통째로 묶어서 팩토리클래스로 만들고 이들 팩토리를 조건에 따라 생성하도록 다시 팩토리를 만들어서 객체화 한다.
• 팩토리를 두번 사용한다고 생각하면 된다.
• 컴퓨터가 삼성, LG 두가지가 있을경우 삼성 컴퓨터의 각 요소들을 만들어주는 팩토리를 만들고 컴퓨터를 만드어주는 팩토리를 하나 더 만들어주면된다.
• ex)
• ComputerFactory : 컴퓨터를 만들어주는 팩토리
• MouseFactory : 컴퓨터 부품의 마우스를 만들어주는 팩토리
• KeyboardFactory : 키보드를 만들어주는 팩토리