성장하는 프로그래머

FAST IO 원리

kail — Wed, 27 Apr 2022 16:03:30 +0900

우선 fastIO란 무엇인가?

IO 버퍼크기는 2048바이트 정도로 버퍼에서 한번에 나눠서 받기 때문에 이 값 이상의 버퍼 값이 들어온다면 비효율적으로

들어올 수 있다

따라서 우리는 이런 상황에 fastIO를 사용할 수 있다

fastIO는 값을 받을 때 한번에 받아서 해당 값을 처리해준다

코드는 아래와 같다(picuhila님의 코드를 참고하였다)

unroll-roops는 최적화에 쓰이는 방법인데, 현재에서 다루는 과정은 아니기 때문에 생략한다

#pragma GCC optimize("unroll-loops")
#include<iostream>
#include<string>
#include<vector>

using namespace std;
class FastIn
{
	public:
	const static int BUFFER_MAX = 1048575;
	static char buf[BUFFER_MAX + 1];
	static int pos;
	FastIn()
	{
		clear();
	}
	static void clear()
	{
		pos = BUFFER_MAX;
	}
	static void read_buffer()
	{
		fread(buf, sizeof(char), BUFFER_MAX, stdin);
	}
	static char getchar()
	{
		if (pos == BUFFER_MAX)
		{
			read_buffer();
			pos = 0;
		}
		return buf[pos++];
	}
	static int nextint()
	{
		int res = 0;
		char c;
		do
		{
			c = getchar();
		} while (c < '0' || c>'9');
		res = c - '0';
		while (1)
		{
			c = getchar();
			if (c < '0' || c>'9')break;
			res = (res * 10) + c - '0';
		}
			return res;
		}
	};

char FastIn::buf[FastIn::BUFFER_MAX + 1];
int FastIn::pos;
int v[3000009];
int ch[3000009];
int l, ml, mk, c,x;
int main()
{
	l = FastIn::nextint(); //총 거리
	ml = FastIn::nextint(); //기관총 유효 사거리
	mk = FastIn::nextint(); //기관총 데미지
	c = FastIn::nextint(); // 거리1에 한해 무한대 데미지를 주는 수류탄 개수
	for (int i = 0; i < l; i++)
	{
		v[i] = FastIn::nextint(); //0m부터 총거리까지 좀비체력
	}
	int dam = mk;
	for (int i = 0; i < l; i++)
	{
		if (ch[i]) dam -= mk;
		if (v[i] -dam > 0)
		{
			c--;
			if (c < 0)
			{
				cout << "NO";
				return 0;
			}
		}
		else
		{
			if (i + ml < l)
			{	
				ch[i + ml] = 1;
			}
			dam += mk;
		}
	}
	cout << "YES";
	return 0;
}

우선 fread의 코드는 아래와 같다

fread로 우리는 static으로 이미 값을 받고 해당 값을 char 배열에 넣고 시작한다
그 다음 null이라는 중간 공백으로 구분을 한다
fastio를 쓰는 예시는 아래와 같다
https://www.acmicpc.net/problem/19644
이제 여기서 나는 io값은 최대 얼마인가?
처음에는 7글자이다(3*10^6은 6글자로 표현가능 + 공백 한글자)
그 다음에는 7+(3*10^6)*4이다 (기관총 범위 3*(10^6)만큼 입력하고(총 6글자+공백 한글자), 해당 입력범위에서 각각의 거리에 대한 데미지가 최대 100까지 설정하므로 (각각 3글자+공백한글자)
그 다음에는 7글자 (3*10^6) 만큼 입력된다
그러면 왜 100만에 가까운 수부터 1mb까지가 효과적이었는가?
간단하다 입력이 최악인 경우 10^6이 아니라 10^6에 가까운 값만큼 L에 입력되었기 때문이다 그래서 1mb에 못미치는 값이 입력되었기 때문에 입력받을 떄 크기가 1mb보다 약간 작아도 잘 작동했다
이제 생기는 의문은 왜 1MB보다 큰 값에서는 오히려 시간이 오래걸리냐인데, 여기서 백준에서는 반도체 관련 기술자분들이라고 해서 이게 뭔 말이지 싶었는데
https://ljhblog.tistory.com/59
메모리 연산은 리얼모드에서 최대 1MB로 8086프로세서와 교환 가능하다
여기서 8086 프로세서가 무엇이냐하면
간단히 말하면 어셈 배울 때 Thumb Instruction이라고 해서 우리가 잘아는 명령어인 EQ(동일), GE(크거나 같다),LE(작거나 같다) 등 이거 관련 명령어를 가지고 있는 친구가(스프링 타임리프쪽에서 아마 본 적이 있을 것 같다)

https://namu.wiki/w/%EC%9D%B8%ED%85%94%208086?from=8086

8086프로세서(16비트 컴퓨터)이후에도 계속 새로운 프로세서(32비트 컴퓨터,64비트 컴퓨터)가 나왔는데

위에서 최대의 메모리를 다룰 수 있는 1MB 처리를 다루는 리얼모드는 동일한 것 같다

따라서 1MB연산이 가장 최적화되어있는 상태라고 말 할 수 있다.

아래 쪽에 관심있으면 플래그 레지스터(flag register)라고 해서 어셈에서 다루는 거라고 하니까 찾아보면 좋을 것같다

타임리프 정리

kail — Wed, 30 Mar 2022 17:38:12 +0900

https://www.thymeleaf.org/doc/tutorials/3.0/usingthymeleaf.html#the-template-engine

Tutorial: Using Thymeleaf

1 Introducing Thymeleaf 1.1 What is Thymeleaf? Thymeleaf is a modern server-side Java template engine for both web and standalone environments, capable of processing HTML, XML, JavaScript, CSS and even plain text. The main goal of Thymeleaf is to provide a

www.thymeleaf.org

여기서 타임리프에 관한 설명을 읽으며 모르는 단어는 번역기 돌려 보고 문장도 모르겠으면 통째로 번역해서 다시 번역해보고

잘 모르겠거나 정리용으로 블로그 글 들을 뒤져보곤 하는데,

아무도 ITemplateResolver가 TemplateResolver로 구현되어있는데,

왜 ServletContextTemplateResolver의 객체로만 보이는지에 대한 자세한 설명이 없다.

이에 대해 의문이 들어 자바/스프링 단톡방에도 질문하였으나, 평일 오후라 그런지 다들 답변이 없으셨다.

스택오버플로우에도 딱히 관련된 사항이 없는 것 같아 한번 간단히 정리하였다.(결론적으로 내 예상이 맞았다..)

2번의 The tymleaf Resolver에 관한 내용을 읽어보면

Template Resolvers are objects that implement an interface from the Thymeleaf API called org.thymeleaf.templateresolver.ITemplateResolver:

라는 설명이 있다.

번역하자면, Template Resolvers는 Thymleaf API에서 요청한 인터페이스의 ITemplateResolver를 구현한 객체라는 말이다.

자 그러면 코드를 보자.

ServletContextTemplateResolver templateResolver = 
        new ServletContextTemplateResolver(servletContext);

여기서 templateResolver는 ServletContextTemplateResolver class를 참조하는 것 같다

(당연하지만 추상 class나 interface면, new로 인스턴스화 작업이 일어나지 않는다

추상 class에서 default 함수만 쓸 경우 그냥 class를 쓰는 것이 낫기 때문에 쓸 필요가 없다)

그러면 여기서, templateResolver는 ITemplateResolver를 구현한 객체인데, 왜 templateResolver는 ServletContextTemplateResolver를 참조한다고 할까?

그러면 당연히 ServletContextTemplateResolver의 부모 class나 인터페이스가 ITemplateResolver라고 생각할 수 있다.

나도 여기까지는 예상했다.

그런데 다시 의문이 생긴다.

그러면, TemplateResolver라는 네이밍으로

구현하면되는 걸, 왜 네이밍할때 ServletContextTemplateResolver로 구현했는가에 대한 의문이 생긴다.

다시말해 ITemplateResolver랑 ServletContextTemplateResolver가 네이밍으로 봤을 때

서로가 1차적으로 연결된 관계가 아니란 점은 도출해 볼 수 있다는 말이다.

2시간동안 찾아보니 상속 관계는 위와 같고(링크: https://www.thymeleaf.org/apidocs/thymeleaf/3.0.0.BETA03/org/thymeleaf/templateresolver/ServletContextTemplateResolver.html)

Object
- org.thymeleaf.templateresolver.AbstractTemplateResolver
  - org.thymeleaf.templateresolver.AbstractConfigurableTemplateResolver
    - org.thymeleaf.templateresolver.ServletContextTemplateResolver

구현의 관계는 위와 같다

ITemplateResolver
- org.thymeleaf.templateresolver.AbstractTemplateResolver

즉 AbstractTemplateResolver가 ItemplateResolver를 구현하고,

AbstractConfigurableTemplateResolver , DefaultTemplateResolver , StringTemplateResolver 라는 자식 class가 존재한다

org.thymeleaf.templateresolver.AbstractConfigurableTemplateResolver는 ClassLoaderTemplateResolver, FileTemplateResolver, ServletContextTemplateResolver, UrlTemplateResolver 라는 자식 class가 존재한다

AbstractTemplateResolver라는 추상 class는

protected boolean computeResolvable 함수로 resolver가 적용가능한지 체크하고,

protected abstract TemplateMode

enum으로 templateResolver.templateMode = TemplateMode.HTML여기서 쓰는 것처럼

HTML,CSS 형식으로 setting 하는 것이 가능하고,

protected abstract ICacheEntryValidity

템플릿이 캐시에 들어가는 게 가능한지나, 템플릿이 여전히 유효한 지 검사할 수 있고,

boolean getCheckExistence()

템플릿이 리턴하기 전에 존재하는 지 검사할 수 있고,

String getName()

템플릿 확인자 이름을 반환하는 것이나

등등을 알 수 있다.

AbstractConfigurableTemplateResolver 라는 class에서는

여기서 prefix랑 suffix를 set으로 설정하는 것을 알 수 있다.

templateResolver.setPrefix("/WEB-INF/templates/");
templateResolver.setSuffix(".html");

이걸로 타임리프를 사용할 떄 접두사 접미어로 (상위폴더,하위이름) 실제 파일의 이름을 쉽게 찾아서 사용한다

여기서 이제, controller에서 view resolver로 보내줄 때

return "thymleafpractice1";

이렇게 보내주는데 이러면, (또는 thymeleafpractice1.html로 보내주기도 하는데, 이렇게 해도 아마 .html이 접미어랑 중복되면 자동으로 접미어만 빼거나 하는식으로 해주지않을까 싶다)

servletContext.getResourceAsStream("/WEB-INF/templates/thymleafpractice1.html")

그러면 내부적으로 함수를 호출해 다음과 같이 처리해준다는 얘기인 것 같다

그리고, 캐시라는 말이 애매하게 보여서 찾아보니 https://countryxide.tistory.com/8 에서

캐싱하는 것이 임시저장소에서 바로 등록했던 걸 가져오고 하는 시간인 것 같다.

그래서,

templateResolver.setCacheTTLMs(3600000L);

이렇게 작성하면 대략 1시간 정도 내가 코드를 바꿔도 임시저장소에서 있던 걸 그대로 보내주는 시간을 정해주는 작업인것같다

60*60*1000ms(1s)

templateEngine = new TemplateEngine();
templateEngine.setTemplateResolver(templateResolver);

결과적으로 , 템플릿 엔진에서는 이렇게 만든 템플릿리졸버를 값으로 받는데 이 과정은 CGVT 엔진에서 동작한다

public class GTVGApplication {
  
    
    ...
    private final TemplateEngine templateEngine;
    ...
    
    
    public GTVGApplication(final ServletContext servletContext) {

        super();

        ServletContextTemplateResolver templateResolver = 
                new ServletContextTemplateResolver(servletContext);
        
        // HTML is the default mode, but we set it anyway for better understanding of code
        templateResolver.setTemplateMode(TemplateMode.HTML);
        // This will convert "home" to "/WEB-INF/templates/home.html"
        templateResolver.setPrefix("/WEB-INF/templates/");
        templateResolver.setSuffix(".html");
        // Template cache TTL=1h. If not set, entries would be cached until expelled
        templateResolver.setCacheTTLMs(Long.valueOf(3600000L));
        
        // Cache is set to true by default. Set to false if you want templates to
        // be automatically updated when modified.
        templateResolver.setCacheable(true);
        
        this.templateEngine = new TemplateEngine();
        this.templateEngine.setTemplateResolver(templateResolver);
        
        ...

    }

}

디자인 패턴 정리(2)

kail — Tue, 22 Mar 2022 15:00:35 +0900

팩토리 메소드 패턴 vs 프록시 패턴

팩토리 메소드 패턴은 "객체의 생성"을 서브 class에 위임하는 것

프록시 패턴

프록시 패턴은 class끼리 직접 참조하지 않고 간접적으로 서브 class를 통해 참조해서 값을 출력하거나 getter로 받거나 하는 것

프록시 패턴 vs 중재자 패턴

프록시 패턴은 서브 class를 통해서 값을 바꿀 수 없지만

중재자 패턴은 서브 class를 통해서 값을 바꿀 수도 있다

더 쉽게 설명해주겠다.

interface DeliveryFood{
    public void setPrice(int price);
    public int getPrice();
}
class Pizza implements DeliveryFood {
    private int price=0;
    public Pizza(int price) {
        this.price=price;
    }
    public int getPrice() {
        return this.price;
    }
    public void setPrice(int price) {
        this.price=price;
    }
}

class Chicken implements DeliveryFood{
    private Chicken chicken() {

    }
    private int price=0;
    private Chicken(int price) {
        this.price=price;
    }
    public int getPrice() {
        return price;
    }
    public void setPrice(int price) {
        this.price = price;
    }
}
// pizza로도 확장 가능성이 존재하고
// 치킨이랑 pizza가 존재한다면..
// 또한 피자는 따로 배달이 안된다면..

class FlyWeight{
    public Chicken chicken;
    public Chicken getChicken() {
        return chicken;
    }
    public Chicken getChicken(int price) {
        chicken.setPrice(price);
        return chicken;
    }
}

class Proxy{
    private Chicken chicken;
    public int chickenPrice() {
        return chicken.getPrice();
    }
}

class ChickenService{
    private Proxy proxy;
    private final int chickenPrice;
    private int deliveryPrice;
    public ChickenService() {
        this.chickenPrice=proxy.chickenPrice();
    }
    public void chickenPrice(){

        if(chickenPrice>=30000) {
            deliveryPrice=0;
        }
        else {
            deliveryPrice=3000;
        }
    }
}

public class java46 {
    public static void main(String[] args) {
        FlyWeight flyWeight=new FlyWeight();
        Chicken chicken=flyWeight.getChicken();
        Pizza pizza=new Pizza(10000);
        // 관심사 분리를 한번 더 생각해서, Chicken chicken=new Chicken();
        // 이렇게 하고 싱글톤으로 하나의 객체로 관리하는 방식이 스프링에서 쓰는 방법이다
        // 이건 new로 새로 생성하지 않고
        // 하나의 객체를 참조하기 때문에 
        // 플라이웨이트를 이용한 프록시라고 할 수 있다.
    }
}

여기서, 프록시 패턴은

치킨이랑 피자를 의도적으로 숨기는 용도로 쓰이는 경우로 사용한 것은 아니다.

(프록시는 처음공부할 떄 프록시를 생각하면 보안이 생각나서

숨기는 용도로 사용한다고 생각했지만,

실제로 proxy는 대리자. 대리자의 패턴을 의미한다)

여기서 굳이 서브 class로 분리한 이유는 관심사의 분리.

더 쉽게 말하면 하나의 class가 감당할 것이 너무 많아져서 분리하거나,

중복된 목적이나 코드들을 따로 처리하기 위해,

확장 가능성이 존재할 때 이를 쉽게 확장하기 위해서 사용한다

저기서, chickenService만 따로 둔 이유는 피자는 배달이 안된다고 생각했을 때를

가정했기 때문에 Service를 따로 만들지 않았다

여기서, 프록시 패턴은 실제로 값을 set으로 바꿀 수 없다.

오직, 기존에 있는 값을 참고할 뿐이다..

여기 뒤부터는 사실 중요한 내용은 아니다.(바로 프록시 패턴을 참고해도 좋을 것 같다)

또한 왜 싱글톤을 이용한 프록시/ 플라이웨이트를 이용한 프록시로 나누냐면

호출 규약을 어떻게 하느냐에 따라 플라이웨이트로 짜려다가

싱글톤에 있는 코드를 비슷하게 생각없이 그대로 호출해서 new 로 접근한적이 있어서

새로운 객체가 참조된 적이 있어서 올렸다

위의 코드에서 Proxy라는 class가

싱글톤처럼 확실히 막아놓으려고 생성자를 막고 간접적으로 참조하도록

플라이웨이트 패턴을 사용했다

(근데 다음날 수정할 때 생성자를 혹시 몰라서 막아주는 걸 안해놓고 new()로 참조하니까

아 내가 실수했네 이렇게 생각했는데, (생성자는 확실히 막는데, 플라이웨이트는 거기서 자유롭게

짜는 형식이기 때문에 싱글톤처럼 private 생성자를 쓰면 얼마든지 막을 수 있다)

)

차이점은 얘를 이용하면 static으로 사전에 정의를 하지않아도 잘 작동하고,

좀 더 기능을 분리하지만 class가 하나 더 증가한다는 특성이 있겠다

class가 하나 더 늘면, 코드 자체는 너무 길어져 버린다는 단점을 생각해볼 수 있다

장점은 static 키워드는 multi-thread 환경에서 문제가 생기고,

multi-thread 접근을 방지하기 위한 방법으로는 synchronized의 사용이 있다.

https://yeonyeon.tistory.com/113

[Java] static과 synchronized

흔히 static 키워드는 multi-thread 환경에서 문제가 생기고, multi-thread 접근을 방지하기 위한 방법으로는 synchronized의 사용이 있다. static만 쓰거나, synchronized만 쓰거나, 둘 다 쓰거나... 이런 경우가..

yeonyeon.tistory.com

(쉽게 얘기하면 static으로 사전에 정의하는데 그걸 한꺼번에 돌리니 한꺼번에 늘어날 가능성이 존재하고,

synchronized로 돌아가는 환경을 고정시켜버리면 성능저하가 일어난다 위의 해결 방법으로는

현재 싱글톤으로 lazyHolder 방식이 있는 것 같은데,

이 방법은 static이어도 multi-thread에 안전하고 synchronized를 사용하지 않는다)

또한, 하나의 class에 너무 많은 기능을 부여하는 것을 관심사의 분리작업으로 분리가 된다

Chicken,Pizza,dakbal,galbi 등 이렇게 여러 곳에서 값을 간접적으로 참조한다면 다른 class에서 그냥

각각의 class에 메소드를 부여해서 참조할 목적이라면 이 부분은 그냥 구분하는 게 낫다

(사실 이 부분에 대해서는 그냥 각각의 class가 부담하는 게 적으면

관심사 분리가 중요한가 싶었는데,

코드 설계 단위에서 부담할 게 많아지면

그 때부터 함수로 분리하는 코드를 제작한다면

사실 코드 자체가 너무 많아서 이렇게 분리했구나 라고 이해는 되겠지만,

하나의 class가 감당하는 게 너무 많으니

그 이후부터의 코드만을 따로 구분하기 때문에, 이런 코드는 왜 같이 해놓고, 이 코드는 왜 따로 처리했을 까 하며

고의로 코드를 짤 때 해당 목적을 강조하는 듯한 느낌과 하나의 class안에 여러가지 기능이 있는데

한 class가 너무 많은 것을 내포하고 있어서 그 이후부터, 목적을 따로 구분하기 때문에

이질적인 느낌도 드는 것 같다)

따라서 같은 메모리주소를 참조한다면 한 메소드에 넣지말고, 이런 코드는 관심사의 분리 용도로

처음부터 구분하는 것이 맞는 것 같다.는 결론이 나왔다)

위에 대한 내용은 스프링 김영한 강사님의 기초강의에서 관심사 분리를 듣고, 의문이 들어서 생각해본 결론이다.

(참고로 스프링 컨테이너에서는 싱글톤에서 관리를 한다

이걸 작성하는 동안에는 그냥 플라이웨이트를 써도 되지 않았을까?

싶었는데 기본을 싱글톤에서 관리하되, 다른 객체를 생성해야하면,

프로토타입 스코프로 Provider를 이용하면 알아서 처리를 다 해주기 떄문에

Config를 수동 생성 할 때도, 굳이 플라이웨이트 패턴을 쓸 필요가 없다)

이제 중재자 패턴이란 무엇인가?


class Client {
    private Mediator mediator;
    public void findID() {
        mediator.findID();    
    }
    public void setID(String id) {
        mediator.setID(id);
    }
    public void setPassword(String password) {
        mediator.setPassword(password);
    }
}

class Mediator{
    private String userID;
    private String userPassword;
    public void findID() {
        System.out.println(userID);
    }
    public void setID(String id) {
        this.userID=id;
    }
    public void setPassword(String password) {
        this.userPassword=password;
    }
    
}

class Server {
    private Mediator mediator;
    public void findID() {
        mediator.findID();
    }
    public void setID(String id) {
        mediator.setID(id);
    }
    public void setPassword(String password) {
        mediator.setPassword(password);
    }

}

public class java46 {
    public static void main(String[] args) {
        
    }
}

Server 쪽이랑 Client 각 단에서

서로가 서로의 값을 바꾸려고 시도해서 접근해도 실제로는 mediator가 관리한다

class NonMember {
    private Mediator mediator;
    public void setEmail(String email) {
        mediator.setEmail(email);
    }
    public void setID(String id) {
        mediator.setID(id);
    }
    public void setPassword(String password) {
        mediator.setPassword(password);
    }
}

class Member{
    Mediator mediator;
    
    public void findID(String id) {
        mediator.findID(id);
    }
    public void findPassword(String Password) {
        mediator.findPassword();
    }
}
class Mediator{
    private String email;
    private String userID;
    private String userPassword;
    public void setEmail(String email) {
        this.email=email;
    }
    public void findID() {
        System.out.println(userID);
    }
    public void findID(String email) {
        if(email==null) {
            System.out.println("어떠한 이메일도 등록되지않았습니다");
        }
        if(email!=this.email) {
            System.out.println("등록된 이메일이 바꼈거나 다른 이메일입니다");
        }
        System.out.println(userID);
    }
    public void findPassword() {
        System.out.println(userPassword);
    }
    public void setID(String id) {
        this.userID=id;
    }
    public void setPassword(String password) {
        this.userPassword=password;
    }
    
}

class Server {
    private Mediator mediator;
    public void findID() {
        mediator.findID();
    }
    public void setID(String id) {
        mediator.setID(id);
    }
    public void setPassword(String password) {
        mediator.setPassword(password);
    }

}



public class java46 {
    public static void main(String[] args) {
        
    }
}

원래는 db같은 곳에 넣던가 (작게 테스트를 할꺼면) 임시로 동적 배열에 추가하면서 이메일,id,password로 정해야하지만

그것까진 생각안하고 오직 하나의 계정에 대해서만 만들고 조회하도록 했다

만약 저기서 Mediator를 쓰지 않았다면

NONMEMBER<-> MEMBER MEMBER<->SERVER SERVER<->NONMEMBER 이런식으로 서로가 서로의 데이터에

접근하게 짜야되서 코드가 더 복잡해보일 것이다

따라서, 이렇게 전부 다 Mediator에 접근해서 실제 코드로는 Mediator가 접근하도록 할 수 있다

그리고, 관련 자료를 오지게 뒤졌는데, Mediator를 cpp에서는 locate같이 직접 class로 접근해서 하는 경우도 있는데

java 블로그들은 다 interface로 접근했지만, 어차피 위와 같은 mediator는 다른 mediator를 만들어야 할 확장성이 있는 것도 아니고,

기능과 역할(interface와 class)에 대해서 굳이 비교할 필요없이 굳이 중간에 값 전달및 세팅만 하는 친구이고,

전달 및 중간에 값 수정만 하는 거라서 큰 기능을 하는 것도 아니다.

그리고, 최근에 김영한 강사님의 스프링을 공부하는데 강사님께서도 interface로 연결안하고, 바로 class를 사용하시는 게 좀 컸다

따라서 위 코드에서는 Mediator interface를 따로 두지않고, class로 바로 연동시켰다

그 자료가 어디있냐면

스프링 핵심 원리 기본편의 AppConfig 리팩토링 쪽을 보길 권한다

보면 알겠지만 Public class로 구현하셨다

(실제 스프링 환경에서 수동 빈등록도 사용하신다고 하셨고, 위 기초 강의를 보면 알겠지만, 그 윗부분은 쭉 인터페이스와 class로 기능과 구현을 분리하는 걸 강조하시는데, 위 부분에서 interface로 두지 않는 것만 봐도 어느정도 의미가 있지 않나 싶다)

디자인 패턴에 대한 정리(1)

kail — Sat, 19 Mar 2022 16:27:03 +0900

디자인 패턴 한번씩 보면 가질 수 있는 의문들(1)

1. 추상팩토리패턴: abstract구조로 메소드를 한 곳에 모아서 보호하는 구조
장점: 한 곳에 모아서 보호하기 때문에, 결합력이 높다
단점: 확장성을 위해서는 오버라이딩과 자체함수를 강제하거나, 추상클래스라 하더라도 하나의 클래스에 너무 많은 기능을 부여한다
추가: 디자인패턴과는 상관없는데 abstract로 코딩했기때문에, 다중상속 불가능(즉 하나의 추상class에 하나의 기능을 부여해서 상속하는 관점이라면 위와같은 코딩이 어려움
물론 하나의 기능을 잡는 관점이 케이크를 보고 먹는 class라면 케이스를 먹는다는 인터페이스 대신
케이크같이 크게 잡으면 될 부분이기 때문에 중요한 요소는 아님
애초에 여러개의 인터페이스의 기능을 상속받기보다는
케이크를 보고 먹는다는 그냥 메소드 단위로 묶으면 되고, 케이크를 보는게 어떠한 많은 제약이나 상황에 따른 조건이 존재하는 게 크다면
그 또한 케이크를 보는 class단위로 잡고 상속대신 케이크에서 케이크를 보는 클래스의 객체를 케이크라는 class를 접근하는게 오히려 일반적임
위와 같은 방식으로, 감당할 요소가 너무 커진다면 그걸 abstract class로 잘 설계해서 코딩하면 되니까 역량에 따라선 얼마든지 인터페이스 대신 대체가 가능하다고 생각함
근데, 이건 혼자 작업할 떄 그런것이고, 기획자가 확장안해도 되요 라고 말했는데, 아... 확장안해도 된다고 했는데 확장해주세요 이러고 있으면 인터페이스가 훨씬 좋음)
(물론 abstract로 혹시 몰라서 확장할 수도 있으니 class로 짜야지 이렇게 하면 되는데, 이렇게 abstract로 짜면 설계할 떄 머리에 힘을 좀 넣고 해야될듯)
굳이 abstract로 쓰는 이유는 protected를 사용할 수 있다는 점이 다른 패키지에서 마음대로 접근 못하게 막는다는게 무지막지하게 좋음... 넘사
interface로도 물론 짤 수 있음 블로그에 올려놨는데, 마음대로 생각해서 고르면 될듯)
2. 빌더패턴: 얘도 위에 친구랑 조금 비슷한데, 생성자를 통해서 받아야 한다면, 더 쉽게 말하면 setter를 안 써도 될 상황이면 생성자로 받을 때
그거 다 기억해야 되니까 함수로 정의하면 좀 쉽게 기억해서 짤 수 있으니까 쓰는 기능임
장점: 이클립스는 db로 값 받을 때처럼 자바로 db값 안 바꾸고 그냥 객체 넘기기같은 거만 할꺼면 안에 5개 값 이상이 들어오면 여러개 값 받을 때 처럼 setter 안 쓸꺼면 써라. 급인듯 근데 단점도 조금 있긴함
단점: 생성자를 이용하면 값을 강제할 수 있음 근데 이렇게 짜면
null 값이 들어올 수 있는건 함수를 빼먹으면 ㅈ되는듯? 그래서 필자는
if문 같이 만약 들어올 값이 null이면 예외를 throws로 넘길 것을 주장함(이렇게 짜면 setter처럼 null로 보낼 위험이 없음)
예외처리에 대한 클래스를 따로 두냐에 대한 내용은 다음 블로그에 올림
단점2: 인텔리제이는 생성자 안의 매개변수 값이 자동으로 보여주기 떄문에, 딱히 위와 같이 짤 필요가 없음 컴파일러가 ㅈ사기라는 말이기도 함...
3. 팩토리메소드패턴: 생성할 떄 서브 class로 위임하는 패턴
생성할 때 객체를 직접 생성해줘도 되는데, 얘는 Factory같은 다른 class가 생성을 해줌 AppConfig 만들 때 위 패턴을 사용함
장점: DI 의존성 주입을 시켜주니 그냥 닥치고 무조건 써라.. 라고 밖에 할 말이 없음 시간 없어서 무지성 setter/getter 하드 코딩 하는 수준아니면 시간되면 그냥 무조건 하셈
단점: 딱히 없음. 굳이 있다면 시간 없을 떄는 설계해서 분리하고 같은 시간이 없으니, 원래라면 A <-> B랑 B<->C C<->A 라는 구조가 있으면 미디에이터 패턴으로 A<->D B<->D C<->D로 편하게 짜겠지만
시간이 없으니 public으로 각 데이터 바로 접근 수정해서 짜면 좀 더 빠르다는 거(안 썼을 때 좀 빠르니까 이거의 이익이 상황에 따라선 나을 수 있다는 점?)
4. 프로토타입 패턴: 이건 진짜 아무것도 없음. 깊은 참조 사용하는 패턴임
진짜 얘는 clonable 문법 코딩하는 느낌이라서 그냥 쓰지 않겠음
첨언하면 깊은 참조를 사용하면 주소가 아니라 각 변수랑 메소드까지 하나하나 다 복사하고, 얕은 참조는 그냥 같은 주소 갖다 붙혀라 이런 느낌이라서 얕은 참조임
장점: 깊은 참조라 하나하나 다 복사하기 때문에, 여기서 그냥 값 복사하고 나중에 객체 값 비교하는 설계가 필요하다면 사용하면 좋음(얕은 참조는 복사가 어려움)
단점: 얕은 참조는 그냥 같은 주소 갖다붙히라는 느낌인데 얘는 새로 객체 생성해야되니 시간이 느려짐
5.싱글턴: 얘는 생성하고 이후 이 메모리 사용할 떄 같은 메모리주소를 참조하도록 강제하는 느낌임 우회법도 있긴한데, 하는 사람이 설마 있을 까 싶어서 그냥 말 안함(그런거 우회할 수준이면
이미 기존의 코드대로 짤듯)
장점: 하나의 객체를 사용하기 떄문에 빠름
단점: 내부 코드를 테스트하기 어렵고, 유연성이 떨어진다(물론 알고리즘은 싱글스레드를 기준으로 해서 조금 다른 얘기일 수도 있지만, 암튼 알고리즘할 떄 어렵고 빠르게 짜는 것보다 어느정도
알기 쉽게 짜려고 하는 걸 생각하면 좋은 것 같다. 비슷하게 db도 분리안하고 짜면 더 빠르다는 얘기도 있던데, 분리해서 하면 그 대신 db단이랑 분리가 더 잘되서 분리한다는 얘기를 들어 본 적이 있고,
빠르면 c++을 위주로 하면 되는데, java단은 좀 더 보기 편한 걸 위주로 아는 성향이 있다
그래서 cpp쪽은 좀 더 저렇게 사용하는 걸 지향하겠지만, java단은 저런 걸 짠다면 주변 사람들이 어렵더라도 얼마나 잘 사용하는지 "보편성에 대한" 생각을 해봐야될 것 같긴하다
그런점에서 자체 난이도 보다는 알고리즘단처럼 좀 보기 어려우면, 굳이 이걸 이렇게 짜나 라는 생각이 주변 환경에서 많다면 줄이고,
싱글톤처럼 좀 어려울 수 있어도, 많이 처리를 한다라는 얘기가 나오는 코드면 지향하는 게 내 생각에서 java를 효율적으로 짜는 것이 아닌가 싶다)
6. 어댑터: 두 개의 일정한 상황에서만 가능하게 정의 된 인터페이스들이 이미 있다면 이걸 유지보수할 떄 중간에 이을 수 있도록 인터페이스랑 구현체를 하나 만들어서 잇는 방식
(인터페이스 유무는 그냥 확장성 생각해서, 혹시 모른다 싶으면 추가하고, 어차피 그냥 연결하는건데 이건 이거대로 연결하고 다른 것중에 연결되어있는 것도 있고
어차피 별로 일치할 만한 게 없어보이니 그건 그거대로 다른 어댑터 패턴을 만들자 싶으면 만들고 알아서 하면 될 것 같다)
7. 브릿지 패턴: 그냥 인터페이스랑 구현체를 분리하는 패턴
장점: 확장하거나 교체할 수 있는거 인터페이스랑 구현체 따로만들어서 분리하면 확장성 증가
단점: 확장 할 필요없는거는 굳이 늘릴 필요는 없는 것 같아, 불필요하다. 그러니까 치킨먹는class랑 피자먹는 class가 있는데, 여기서 그냥 각 class마다 먹는 게 공통적이라면
먹는 함수만 오버라이딩 하고 void eat(){sout(치킨먹기)sout (피자먹기)}
이러면 되는데, 굳이 치킨이랑 피자를 음식이라는 인터페이스의 구현체로 늘릴 필요는 없다
(그러니까 치킨먹는 class,피자먹는 class에 음식interface(안에 아무것도 없음),음식먹는class를 굳이 할 필요는 없다)
8.컴퍼지트 패턴
트리 구조를 객체끼리 연결하게 하는 패턴
장점: 연결리스트를 탐색할 때 (이터레이터 패턴을 사용할 때)는 중간부터 탐색을 한다면 다 탐색을 해야한다면 불편한데, 이 친구는 중간 부터 탐색할 수 있도록 설계하기 편하다
단점: 객체 연결할 떄 이터레이터 패턴은 간단하게 add함수 만들어서 자동으로 다음 객체 전달하도록 연결하면 되는데, 이 친구는 연결할 떄 수동으로 File1.add(File2)이딴식으로 연결해야한다
9. 데커레이터 패턴
동적으로 함수를 추가할 때 사용하는 패턴
장점: 동적으로 함수를 오버라이딩 해서 넘겨주니까, 시간이 없어서 하드코딩으로 빠르고 유지보수 편하게 짜고 싶은 게 조건이면 이게 맞을 수도 있다
단점: 저런 상황이 나올 수 있는지 사실 잘 모르겠다. 유지보수 편하게 짜려고 값 넘기는 게 익숙해지면 솔직히 저게 나을 수도 있다
장점만 보면 많아보이지만 사실 그렇게 많이 필요할 것 같지는 않다
예를 들어 커피를 판매하는데 원재료인 우유라는 class가 ml당 가격이랑 이런거 상황에 맞게 선택해야 되고 커피콩도 class라g당 가격 재료 얼마나 필요한지 각 재료 사용량이 어느정돈지
해당 재료에 안 좋은 뉴스가 있는지
이런거 상황에 맞게 어느제품을 구매할지 선택해야되고
점원이 가격을 올린다던가 이벤트 한다던가 하는 서비스까지 따로 좀 있으면 class 우유 class 커피콩 이렇게 따로 둬야하고,
가령, 커피를 판매하면 커피콩가격이 오르거나, 우유가격이 올라가면 여기서 그냥 커피{} class 우유{if(우유 사기위한 조건==true) {return true;} 우유 함수(){return 우유 가격;}}
class설탕 {if(설탕 사기위한 조건==true) 설탕함수(){return 설탕 가격;}}
머 이런 조건이 다 맞아야 한다
만약, 우유원재료 가격만 따로 추가해도 되면 그냥 커피class에 우유 원재료가격이랑 이걸 다 커피안에선언해서 자체 서비스값이랑 더하고
같은 정적 class형식으로 하는게 더 빠르고 위의 경우는 확장성 고려할 필요는 없기 떄문이다
만약, 시간이 남는다면 동적으로 넘길 생각보다는 따로 사기위한 조건을 단위로 class를 둬서 거기에서 처리하도록 하는 것이 훨씬 잘 짜여진 설계이기 때문이다
10. 퍼사드 패턴
복잡하거나 반복적인 과정을 간단하게 사용하게 하는 패턴
그냥 계산기 있으면 34+3을 할 떄 내부적으로 0과1어떻게 컴퓨터에서 처리하는지 코딩안하고 return 34+3; 이런식으로 간단하게 코딩하는 것처럼
함수 만들 때 반복호출해야되거나 복잡한 걸 그냥 하나의 함수에 묶어서 그거 쉽게 하나의 class 만들어서 그냥 거기서 간단한 함수로 처리하게 해주는 것(하나의 함수로 해도 되는데 디자인패턴은
oop 패턴방식인거 생각)
11. 플라이웨이트 패턴
그냥 메모리주소참조할 떄 같은 메모리주소를 참조할 수도 있게끔 만들어주는 패턴
장점: 싱글톤처럼 하나의 같은 메모리 사용을 하기 때문에 좋다
단점: 단점은 잘 모르겠고, 싱글톤은 마음대로 다루는 것을 엄격하게 막아주지만, 이 친구는 호출할 때 좀 풀어주는 느낌이다
12. 프록시 패턴
장점: 객체에 있는 값을 직접 안바꾸고 프록시(서브 클래스)로 바꾸기 떄문에 하나의 클래스에서 너무 많은 처리를 한다면 이를 분리해줄 수 있다
단점: 얘도 잘 쓰면 좋은 것 같다 시간이 없어서 하드코딩해야되면 얘는 따로 분리해야되니 시간이 필요해서 시간이 없다면 후순위로 해야되는 게 낫다.
13. 책임 연쇄 패턴
장점: 자신의 패턴에서 처리가 안된다면 넘겨주면서 분리하니까 하나의 클래스에 너무 많은 역할을 담당한다면 분리해줄 수 있다(다른 class라 넘기는 방법을 말하고 있다)
단점: 프록시랑 비숫허개 하드 코딩해야되면 따로 분리해야되니 시간이 없다면 후순위로 하는게 낫다
유지보수 할 때 기존의 코드를 안보고 따로 처리해서 늘려주면 되니까 위 패턴은 기존의 코드가 잘 짜여있는데 어떠한 조건에서만 안된다면 위 방식을 차용하는 것을 추천한다
프록시는 객체에 있는 값 다른 class로 쉽게 수정하려고 쓰는 용도. 책임 연쇄 패턴은 A안되면 B로 B안되면 C로 처리하는 용도
14. 인터프리터 패턴
코딩 언어 만들면, 문법 같은 걸 class단위로 묶는 패턴
장점: 간단한건 그냥 이렇게 만들면 된다
단점: 언어에서 실행시킬 용도라면 복잡한건 언어에서 언어를 만드는 것이기 때문에, 고대언어에서 만들고 그걸 java같은 언어에서 프로그램만 실행시키도록 하는 방법을 추천한다
15. 이터레이터 패턴
장점: 이터레이터 만들어서 class에 자동으로 연결된 것들에 한꺼번에 먼가를 더하던가 또는 추가하던가 같은 걸 자동으로 할 수 있다
단점: 전에 이터레이터 패턴으로 엄청 복잡한 걸 추천해준 적이 있는데, 그런 경우는 컴파지트 패턴으로 구현하면 수동적으로 하나하나 add로 직접 늘려줘야되서 컴파짓도 되지만 이터레이터 패턴으로 짜는게 맞다
16. 미디에이터 패턴
장점: 위에서도 말했는데 A<->B B<->C C<->A 이렇게 각각이 각각을 참조하는 구조라면 A<->D B<->D C<->D 이런식으로 짜는게 훨씬 보기 편하다
단점: 위 패턴으로 만드는데 걸리는 시간
17. 메멘토 패턴
각각의 메모리를 저장해놓고 나중에 다시 그것으로 되돌리거나 할 수 있는 패턴
장점: 사실 이 친구도 프로토타입 패턴과 다른 방식으로 비슷한 퍼포먼스를 낼 수 있는데 A기억하고 B로 A를 추가해서 B쓰다가 A클래스로 다시 참조하거나 하면 되는데,
clonable쓰면 되고, A,B,C,D,E,F 각각 저장하려고 하면 clonable로 B,C,D,E,F를 계속만들어야되니까 그럴 땐 메멘토 패턴으로 미리 백업처럼 저장해 두는 게 맞는 것 같다(stack으로 넣어서 쉽게
가져다 쓸 수 있음)
단점: 2개 비교하고 끝낼 때 스택으로 메모리 저장해도 되기는 할 것 같은데, clonable이 좀 더 직관적이라고 생각한다 물론 메모리 측면에서는 이 쪽이 조금 더 좋은 것 같긴하다
(깊은 복사하려면 다 만들어야되는 반면, 이 친구는 스택만 만들면 된다)
18.옵서버 패턴
클래스에서 인자를 받을 때 인터페이스로 받아서 구현체의 기능을 쉽게 이용할 수 있도록 사용하는 패턴
좀 더 풀어서 설명하면
A라는 class랑 B라는 class가 있다면 여기서 B에서 A라는 class를 사용하려면 생성자에서 A라는 class를 인자로 받으면 되는데,
이런 경우 생기는 단점은 A라는 class에 있는 변수를 막 접근할 수도 있다. 그리고 만약 A대신 service의 같은 기능을 하는C라는 class로 사용을 바꾸고 싶다면
A대신 C로 인자를 바꾸고, 값을 보낼 때도 A로 보내지 말고 C로 보내게 짜야해서 비효율적이다
근데, 이걸 service의 기능을 인터페이스로 만들고 A랑 C를 인터페이스의 구현체로 만들면
인터페이스로 보내면 인터페이스의 구혀A대신 C로 보내는 것만 바꾸면 바로 작동하므로 효과적이게 작동한다
이렇게 인터페이스로 인자를 보내는 방식을 옵서버 패턴이라고 한다
파사드 패턴이랑 잘못 설명한적이 있었는데, 파사드 패턴은 복잡하거나 반복작업을 함수한번 호출로 간단하게 하도록 하는 것
옵저버 패턴은 쉽게 가져다 쓸 수 있도록 "인터페이스로 값을 보내주는 방법"이다
스테이트 패턴: 각 객체마다 동적으로 객체 상태가 A면 A 형태로 B면 B형태로 자주 바뀌면 효과적인 방법이다
장점: 예를 들어 A라는 사람이 한 게임 내에서 검으로 공격도 되고, 활로도 공격이 되는데 무기를 계속 이거 썼다가 저거썼다가 하면 스트레티지(전략패턴)은 attack()메소드를 오버라이딩 해서
A를 객체로 생성했다가 B를 객체로 생성했다가 이걸 계속 호출하면서 계속 바꿔야된다
근데, 스트레티지 패턴은 그 조건을 시간에 따라서 검공격 활공격 하는 걸 계속 바꿔지게 하거나, 아니면 검썼다 활썼다 이걸 계속 바꾸려고한다면 change.sword() change.bow()만 호출해서
객체만 바꾸면 되니 효과적이다
단점: 검으로 공격했다 활로 공격했다 이런게 한번 호출하고 말것이면, 굳이 바꾸는 걸 메소드로 하기 보단 무기라는 인터페이스에 각 무기를 구현체로 사용하는 게 맞다
예를 들면, 게임 캐릭터 고를 떄 무기선택해서 듀얼소드 캐릭터고르면 듀얼소드검만 써야한다면 이 경우는 다른 캐릭터로 바꾸기전까지 평생 유지되므로 스트레티지(전략 패턴)이 더 효과적이다
템플릿 메소드 패턴:
나중에 함수를 오버라이딩 할 때, 기존의 부모 class에 있는 것과 자식class에 있는 메소드를

오버라이딩 해서 이용하는 패턴이다

(전에 자료를 찾다가 잘못 알려준 것 같은 느낌이 들어 위와 같이 수정하였다.)

비지터 패턴
행위자랑 행동을 구분하는 패턴
그냥 행위자랑 행동에 초점을 맞춰서 짜는 패턴 방식이라 행위자랑 행동에 관한 것이 많으면 거기에 따라 다른 class로 구분하는 패턴이다
장점: 예를 들어 캐릭터 커스터마이징 할 때 A라는 사람이랑 B라는 댄스 동작이 있다면
3D 캐주얼 같은 게임을 A라는 사람 B라는 사람 C라는 사람이라는 사람틀이랑 3d 사람 인체에 나사만 끼워서 거기에 맞춰 동작을 수행한다
그러니까 목을 흔드는 댄스 라면 A라는 사람 B라는 사람 C라는 사람 틀만 만들고 목흔드는 댄스의 class를 만들어서, 거기서 각 행위자 class의 목을 흔드는 동작을 취하는 함수를 만들면 된다
단점: class는 너무 많아지면 역으로 불필요하다. 그래서, 위와 같이 행위자랑 행동을 구분해야하는 확장성이 필요하다면 그거에 맞게 분리하면 될 뿐이라고 생각한다

팩토리 메소드를 interface로 구현해보기

kail — Sun, 27 Feb 2022 02:19:46 +0900

https://www.youtube.com/watch?v=qr7I18Lhsl8&list=PLsoscMhnRc7pPsRHmgN4M8tqUdWZzkpxY&index=2

위 영상과 4강 팩토리 메소드를 보고, 의문이 들었다.

(따라서 소스예제는 3강에 있는 abstract단만 건들여봤다)

interface 자체는 protected같은 코드가 오기 어렵다

이런 경우 protected가 의도적으로 함수를 숨기기 위해서 사용되는 장점을 잃는 댓가가 따른다.

따라서, 자바에서는 위의 경우를 사용할 때 전체 코드에서 abstract를 지원해서, 기능을 확장하며, 사용하는걸 (컴파일러가) 권고한다..

우선 abstract 대신 interface로 저것도 대체 가능하지 않을까? 라는 의문이 들었고 이를 실제로 코드로 작성했다.

(네이밍은 이해바란다..)

우선 내가 interface로 시도하려고 했다가, 위와 같이 작성한 이유가 있는데, 그것 까지 코드 보여주면 너무 길어지기 때문에

간단히 말로 설명한다....

1. 큰 public class함수에 protected 인터페이스를 작성하고, 그 안을 public으로 작성(c++과는 다르기 때문에 인터페이스 안의 메소드는 제어 확장자가 정해져있기 때문에 이렇게 작성하게 된다...)

1-1. 인터페이스안의 함수를 static으로 작성하고, 구현체에서 그 값을 수정할 수 있도록 하기(try-catch로 컴파일 에러 예외처리 따로)

->이 경우

예외처리만 남은 상태였는데, SOLID 원칙 중 LSP(리스코프 치환 원칙)에 어긋나는 것 같아서 보류하고 바로 수정했다.

1-2.본문에서 시도한 것처럼 인터페이스의 함수를 none-static으로 하고, try-catch로 interface타입에 null을 부여하고,

각각 대입하기

(처음에 해봤을 때 타입이 잘 안나왔는데, stack-overflow를 보니 묶을 때 기본 타입이 안전하지 않을 수 있는건 null을 써야됨)

->이 경우에도, abstract보다 단점이 존재했다..

첫번째로, 객체 참조때문에 코드가 너무 길어짐.

둘째로, 그 타입을 상속받을 경우 @Override를 쓰지 못함(즉, 오버라이드 애너테이션에 맞지 않음)

    //하위 클래스로 나눠진 메소드들을 구현한다 (Templete method는 이걸 묶어서 다 구현)
    // protected interface t{
    //     public String fssdef();
    // }
    //자바에서 interface 에 정의되는 메소드는 외부로 공개되는 메소드를 정의하는 것 입니다. 그러므로 private 나 protected 로 정의가 불가능합니다.

    abstract class AbstGameConnectHelper {
        protected abstract String doSecurity(String string);
        protected abstract boolean authentication(String id,String password);
        protected abstract int authentication(String userName);
        protected abstract String connection(String info);

        //템플릿 메소드
        public String requestConnection(String encodedInfo) throws Exception {
            //보안 작업 -> 암호화된 문자열을 디코딩
            String decodedInfo = doSecurity(encodedInfo);
            String id="aaa";
            String password="bbb";

            if(!authentication(id,password)){   //id,password불일치라면
                throw new Error("아이디 암호 불일치");
            }

            String userName=""; 
            int i=authentication(userName);
            switch(i)
            {
                case -1:
                    throw new Exception("셧다운");
                case 0: //게임 매니저
                    break;
                case 1: //유료회원
                    break;
                case 2: //무료회원
                    break;
                case 3: //권한없음
                    break;
                default:    //기타 상황
                    break;
            }


            return connection(encodedInfo);

        }
    }

    class DefaultGameConnectHelper extends AbstGameConnectHelper {

        @Override
        protected String doSecurity(String string) {
            // TODO Auto-generated method stub
            System.out.println("디코드");
            return string;
        }

        @Override
        protected boolean authentication(String id, String password) {
            // TODO Auto-generated method stub
            System.out.println("아이디/암호 확인 과정");
            return true;
        }

        @Override
        protected int authentication(String userName) {
            // TODO Auto-generated method stub
            System.out.println("권한 확인");
            return 0;
        }

        @Override
        protected String connection(String info) {
            // TODO Auto-generated method stub
            System.out.println("마지막 접속단계!");
            return info;
        }

    }

기존 코드

public class java32 {
    @FunctionalInterface
    protected interface faeaw{
        public String doSecurity2(String string);
    }
    @FunctionalInterface
    protected interface faeaw2{
        public boolean authentication2(String id,String password);
    }
    @FunctionalInterface
    protected interface faeaw3{
        public int authentication2(String userName);
    }
    @FunctionalInterface
    protected interface faeaw4 {
        public String connection2(String info);
    }

    public String requestConnection2(String encodedInfo) {
    try{
            // 보안 작업 -> 암호화된 문자열을 디코딩
    faeaw trySecurity=null;
    faeaw2 tryAuthentication2ToLogin=null;
    faeaw3 tryAuthentication2ToName=null;
    faeaw4 dfawef=null;
  
    String decodedInfo = trySecurity.doSecurity2(encodedInfo);
    

    String id="aaa";
    String password="bbb";
    if(!tryAuthentication2ToLogin.authentication2(id,password)){   //id,password불일치라면
        throw new Error("아이디 암호 불일치");
        }
            String userName=""; 
            int i=tryAuthentication2ToName.authentication2(userName);
            switch(i)
            {
                case -1:
                    throw new Exception("셧다운");
                case 0: //게임 매니저
                    break;
                case 1: // 유료회원
                    break;
                case 2: // 무료회원
                    break;
                case 3: // 권한없음
                    break;
                default:    // 기타 상황
                    break;
            }


            return dfawef.connection2(encodedInfo);

        }
        catch(Throwable e)
        {
            e.printStackTrace();
        }
        
        return null;
    }
}



class DefaultGameConnectHelper2 extends java32 {

        class wfnke implements faeaw { 
        @Override
            public String doSecurity2(String string) {
            // TODO Auto-generated method stub
            System.out.println("디코드");
            return string;
            }   
        }
            class wfnke2 implements faeaw2 {
            @Override
            public boolean authentication2(String id, String password) {
            // TODO Auto-generated method stub
                System.out.println("아이디/암호 확인 과정");
                return true;
            }
        }
        class wfnke3 implements faeaw3 {
            @Override
            public int authentication2(String userName) {
            // TODO Auto-generated method stub
            System.out.println("권한 확인");
            return 0;
            }
        }   

        class wfnke4 implements faeaw4 {
            @Override
            public String connection2(String info) {
            // TODO Auto-generated method stub
            System.out.println("마지막 접속단계!");
            return info;
        }
    }
}

implements로 구현한 코드

2번에 서술된 단점

class fawamewlkmf extends DefaultGameConnectHelper2{
    class Appl43te extends DefaultGameConnectHelper2.wfnke3 {
        // @Override 위의 타입에서 수정했으므로 이건 하면 안됨
    public String connection2(String info) {
        // TODO Auto-generated method stub
        System.out.println("??");
        System.out.println("마지막 접속단계!");
        return info;
        }
    }
}

아래와 같이 접근할 때 어렵게 접근해야한다는 단점이 존재한다..

class Fwln extends SFe {

	@Override
	protected String fanwk() {
		// TODO Auto-generated method stub
		return null;
	}
	
}
class fnewk extends Fwln {
	@Override
	protected String fanwk() {
		// TODO Auto-generated method stub
		return null;
	}
}

반면 abstract는 한번 더 상속을 받을 때 이렇게 쉽게 접근 할 수 있다.

후기는 위와 같이 @FunctionalInterface같은 에너테이션과 SOLID 원칙(isp,Ocp)에 위반되지 않는 코드를 작성하느라 힘들었고,

static으로 할 것이냐, non-static으로 할 것이냐, 다른 방법이 있느냐, interface 접근을 어케할 것이냐

이런 경우는 어떻게 처리하면 되느냐, 등 조건이 너무 많았다...

1번을 시도 할 때, String대신 Optional<String>을 쓰다가 본문에서는 쓰지 않았는데, 기존 코드에서 id, password에 null 값이 들어올 수도 있다는 내용이 없기도 했고, 이 경우 초기 선언 값을 Null로 했기 떄문에, 중간 인터페이스 과정이 NULL 값이 접근이 되면 예외가 될 것이고, 그게 아니면 기존 코드와 동일한 효과를 내기 때문에 쓰지 않았다.

개인적으로 Optional,람다를 익힌지 얼마 안되서 짜보고 싶긴 했는데, 아직은 딱히 쓰면 좋겠다는 코드가 잘 보이지 않은 것 같다