22-09-14_jsp

main 2022. 9. 14. 18:15

아키텍쳐

build라는 단어의 의미

------

늦음

------

code assistance (호로시스 ㄴㄴ... ctrl+space)

build == 어플리케이션 전체에 전형적으로 적용할 수있는 설계

design pattern == 소규모에 적용할 수 있는

--> 어느 한 지점, 모듈에서 발새하는 문제를 해결하기 위한 설계도

architecture == 어플리케이션 전체에 발생하는 문제를 해결하기 위한 코드

-----

MessageBundleReadServlet.java에서...

model1으로 가면 시종일관 model1, model2으로 가면 시종일관 model2로 가야 함...

model 1, 2의 차이는, 하나의 명령을 처리하는데에 있어서 역할이 나뉘어져있느냐 아니냐임.

그 명령을 집중적으로 처리 / 쪼개져서 처리

https://mangkyu.tistory.com/194

[OOP] 객체지향 프로그래밍의 5가지 설계 원칙, 실무 코드로 살펴보는 SOLID

이번에는 객체 지향 프로그래밍의 5가지 핵심 원칙인 SOLID에 대해 알아보고자 합니다. 실제로 애플리케이션을 개발할 때 어떻게 적용할 수 있을지 구체적인 예시를 들어 살펴보고자 합니다. 아

mangkyu.tistory.com

- 현재 만들어진 코드가 객체지향적이냐, 아니냐는 SOLID 다섯가지 원칙에 따라서 구분할 수 있음.

SRP(Single Responsibility Principle, 단일책임원칙)
SRP에서 시작되는 O,L,I,D도 SRP에서 파생. model2도 SRP에서 시작.
OCP(개방 폐쇄 원칙, Open-Closed Principle)
상속이라는 구조에는 개방적으로 대하고, 코드 자체를 뜯어고치는건 폐쇄적으로 대하라는 원칙 - 가장 오래된 코딩 원칙 : 한번 만든 코드는 어떤 변경사항이 있더라도 뜯어고치지 않도록 한다. 그만큼 유연하게 설계해야 함. . 객체지향 언어의 특징 중, 상속성 ==> 원래 코드를 바꾸지 말고, 상속받아서 쓰기.
LSP (리스코프 치환 원칙, Liscov Substitution Principle )
: 객체지향 언어의 다형성을 의미
ISP (인터페이스 분리의 원칙, Interface Sergregation Principle)
: dao, service는 그냥 만들지 않고, interface를 먼저 만들고 사용방법을 만들어서 만듦 - 왜 인터페이스를 통해서 실제 객체를 생성하는가?, 인터페이스는 왜 필요한가? 인터페이스의 필요 이유 (사용시 장점) 1) 협업 2) 실행코드의 표준화 (캡슐화)
DIP or DRP ( DRP, 중복 제거의 원칙(Duplication remove Principle) / DIP (Dependency Inversion Principle, 의존 역전 원칙)
절차지향 언어가 먼저 나오고, 이 단점을 해결하기 위해 함수지향언어, 객체지향언어가 나옴 - procedure... 비슷한 코드 반복해서 들어가고.. .이런 중복을 제거 위해 객체지향, 함수지향 언어들이 나오기 시작한 것. DRP면 그 중복을 어떻게 없애냐 하는 원칙을 이야기 하는 거고, DIP면(의존 역전 원칙) 의존성이 뭔지를 먼저 알아야 함. 컨트롤러, 서비스,... 서비스가 완성되기 전에는 controller 못 만듦. 의존성... A객체가 B객체를 사용할 수 있도록 의존성을 설정할 떄, servlet, 생성 위해 가장 위에 service 생성하는 코드가 있음. service객체도 생성 위해서 가장 위에 dao를 생성하는 코드가 있음. --> 내가 써야하는게 있더라도 ... 내가 안만들겠다. == 의존 역전 원칙 -> 외부에 있는 누군가 만들어 준 거를 가져다 쓰겠다.

controller가 많아지는건, 책임을 분리를 잘 못시켜서...

---

최종적으로 오늘 Layered architecture를 적용해보자.

여기서 제일 중요한 건 SRP임...단일책임 원칙.

model1, model2, MVC, Layered Architecture를 적용하면서 책임을 어떻게 둘거냐.

우리가 해결할 문제는 다 복합문제임. 그러면 그 문제 안에 단계를 쪼개는 게 첫 번째 해야 할 일임.

holy..

중프때 왜 ..나눴는가...

---

나라는 client가 노예1(controller)에게 명령을 내림

그러면 노예1이 노예2(service)에게 라면땅을 만들라고 지시함

노예2가 노예3에게 라면가져오라 함. 근데 라면이 없음

그러면 노예 3(dao)이 라면사오라고 함. file-properties

shival...ㅜㅜ

금액 : 변수

사온다는 행위 : method

controller 역할은 client가 명령을 보낼 떄, 그 명령을 받고, line headerm body가 적절한지 검증하는 역할

'순차적'으로 모든 과정을 거쳐야 response data가 나와서 이 구조를 layered architecture라고 함.

어쩃든 순서대로 저걸 다 겪는다고 해서 layered라고 함

====

package kr.or.ddit.props.vo;

/**
 * 
 * Property 한쌍의 정보를 관리하기 위한 Domain Layer
 *
 */
public class PropertyVO {
	//여기의 VO하나를 통해서 data도 information도 담기 위함.
	private String propertyName;
	private String propertyValue;
	
	private String description;
	
	

}

ClassPathResource 말고 FileSystemResource형태로 가지고 놀자. 그래야 서버가 꺼져도 파일이 안날아가

------

JTestCase unit...Ctrl+N 해서 만들기..dao가 잘 작동하는지 test하고싶거든..

Contains test Source 체크하면 Yes 되고 test용으로 어두워짐

근데 이거 어렵고 불편함. mayven이라는 tool을 그래서 씀. 걔는 처음부터 main과 test를 나눠서 씀

단위테스트의 단위는 method 하나를 의미람..

TDD (Test-Driven Development)
:인터페이스 먼저 설계하고, 구현체 완성되지 않은 상태에서 Test를 먼저 함. 이후에 Test성공하도록 해 나가는 것

메모리에서 작업한 데이터가 남으려면 파일로 저장이 되어야 함....

Alt+Shift+J : 주석

원래의 sevice 인터페이스의 시그니쳐(메서드)를 변경하고 싶지 않아 ==> RuntimeException사용

==> 실제로 ReuntimeException으로 많이 관리해서 사용함

결합력은 낮추고 응집력은 높여라

HCLC ( HighCohesionLooseCoupling)

결합력 높을수록 다른걸 반드시 고쳐야 함. 예를들면 dao를고치면 service를고치듯이

응집력???

private PropertyDAO dao = new FileSystemPropertyDAOImpl();

구현체에 종속되는 코드. 결합력이 높음

	private PropertyDAO dao;

	public void setDao(PropertyDAO dao) {
		this.dao = dao;
	}

코드 결합력이 떨어짐. 더 좋음

@Test

: mark annotation

@Test()

EDD (Event driven Development)

<%@ page language="java" contentType="text/html; charset=UTF-8"
    pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Insert title here</title>
<jsp:include page="/includee/preScript.jsp" />
</head>
<body>
<select id="propSel" size="10"></select>
<table>
	<thead>
		<tr>
			<th>프로퍼티명</th>
			<th>프로퍼티값</th>
			<th>비고</th>
		</tr>
	</thead>
	<tbody id="dataArea">
	
	</tbody>
</table>
<form>
	<input type="text" name="propertyName" placeholder="포르퍼티명"/>
	<input type="text" name="propertyValue" placeholder="포르퍼티값"/>
	<input type="submit" value="새 프로퍼티 추가" />
</form>
<div id="errArea"></div>
<script type="text/javascript">
// 	다음의 모든 요청은 비동기 처리를 기반으로 함.
// 	1. 현재 페이지가 랜더링된 후 전체 프로퍼티 정보를 조회하여 select option 을 완성함. line : /properties (GET)
// 	2. 선택 option이 변경될때마다 해당 프로퍼티의 정보를 조회하여 dataArea 에 랜더링함. line : /property?name=prop1 (GET)
// 	3. 하단 form 을 비동기로 전송하여 새 프로퍼티를 추가하고, 기존의 option들의 앞메 추가함. line : /property (POST)
// 	4. 모든 message(content)는 "json" 형식으로 교환됨.
// 	5. 요청 처리에 실패한 경우, 해당 상태코드와 응답 메시지를 errArea 에 랜더링함.
</script>
</body>
</html>

*과제..

비동기......UI 없이 순수 데이터로만 구성이 되어야 함....

럼바우의 객동기?

architecture diagram... 도식화....

네 그렇습니다..... 이건 뭔소린지 조금 알겠네요... 이 과정을 순차적으로 다 겪어야지 response가 나가서, layerd architecture라고 합니당

내일 수업예고...

controller가 view로 이동할 때 model, information을 전달하는데 그 때 setAttribute의 형태로 전달하는데...

Scope? 우리가 4가지 쓸 수 있어서...

이 단계에서 information을 전달할 수 있는 방식이 몇가지고.......??????? 를 배울거다...

Scope라는걸 알려면 '기본객체'라는 걸 알아야 함...가능하면 공부하고 오기...

'main' 카테고리의 다른 글

22-09-15_jsp (4)	2022.09.15
22-09-15_python (0)	2022.09.15
22-09-14_python (1)	2022.09.14
22-09-13_jsp(2) (0)	2022.09.13
22-09-13_python (0)	2022.09.13

ABOUT ME

fight with code wrote myself fight with code wrote myself

'main' 카테고리의 다른 글

티스토리툴바

ABOUT ME

'main' 카테고리의 다른 글

관련글 관련글 더보기

티스토리툴바