개발은 전투다

import java.util.regex.Matcher;
import java.util.regex.Pattern;

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

  String pwd = "aAASDF234230`~!@#$%sdsdf2134234$#^%$&*%*)^&*()-_=+{}[]\\\\|;:,.<>/?'";
  
  String ptn="^[\\p{Graph}]*$"; 
  /*
   * \\p{Lower},\\p{Upper}
   * >> \\p{Alpha}
   *    \\p{Digit}
   *    >> \\p{Alnum}
   *      \\p{Punct}
   *       >> \\p{Graph}
   */
  Pattern p = Pattern.compile(ptn);
  Matcher m = p.matcher(pwd);
  
  if(!m.matches()){
   System.out.println("p : 틀림");
  }else{
   System.out.println("p : 맞음");
  }
  
        String regex = "^[a-zA-Z0-9`~!@#$%^&*()-=_+\\[\\]{}:;',./<>?\\\\|]*$";
        Pattern p1 = Pattern.compile(regex);
        if(p1.matcher("123avcASGD#$%&'A()*+,-./:;<=>?@[\\gsf]^_`{df|2134}~").matches()){
         System.out.println("p1 : good");
        }else{
         System.out.println("p1 : bad");
        }
       
        String regex2 = "^[a-zA-Z0-9!#$%^\\p{Punct}]*$";
        Pattern p3 = Pattern.compile(regex2);
        if(p3.matcher("@##&23aGD#$%&'A()*+,-;;;'''@#$adsfasdSDFBFDB12414$^&^.?@[\\gsf]^_`{df|4}~").matches()){
         System.out.println("p3 : good");
        }else{
         System.out.println("p3 : bad");
        }
  
 }
}

 

다른 브라우저에서는 별 문제 없는데 IE에서는 스키마가 https 로 된 홈페이지에서 http로 이미지나 CSS, Javascript등의 리소스를 로딩하면 경고가 발생한다. 그래서 현재 주소에 따라 리소스의 주소를 적을때 https인지 http인지 잘 구분해서 적어줘야 한다.

사실 나는 별로 납득가지 않는데, 일반적으로 암호화 대상이 되는 데이터는 HTML에 거의 다 들어있고, 혹은 폼을 통해 전송하는 데이터에 들어있지 화면을 꾸미는 이미지, CSS, ... 등(이하 리소스 resource)에 들어있는게 아니기 때문이다. 따라서 경고를 안 내는게 맞는 것 같다.

아무튼 이런 상황에서 HTTPS인 페이지와 HTTP인 페이지별로 따로 모든 리소스의 경로를 구분해서 줘야 할까?

당연히 그럴필요 없어서 글 쓴다. 우리가 <img src="/image/something.jpg" /> 이런 형태로 도메인에 상대적인 리소스 주소를 적는 것과 마찬가지로, 스키마(http/https)에 상대적인 주소를 적는것도 가능하기 때문이다.

<img src="//some.domain.com/image/something.jpg" />

이렇게 http: 혹은 https: 같은 스키마를 제외하고 //도메인주소/경로를 적는것이 스키마에 상대적인 주소이다.
이 주소는 현재 웹 페이지의 스키마가 자동으로 붙어서 요청이 날라가게 된다.

이것은 꼼수가 아니라 표준에 명시된 것이다. 모든 브라우저가 지원한다.

조건문으로 어떨때는 http: 어떨때는 https: 붙이는 고생은 그만하고 상대 스키마를 사용해보시길.

조건: 브라우저기반 작동시에만 사용할 것. HTML 이메일에 이 방식을 사용하면 보장 못함!

객체지향 설계원칙(SOLID)

-> 변화에 유연하게 대처할수 있는 설계원칙, 사용자관점에서의 설계를 지향한다.

1. srp/isp  : 객체가 커지지 않도록 막아준다. 기능변경이 미치는 영향을 최소화한다.

2. ocp : 기능확장을 하면서 기존코드를 수정하지 않도록 한다.

3. dip : 추상화!

4. lsp : 다형성 이용. 

- SRP: Single Responsibility Principle(단일 책임의 원칙)
  클래스는 단 한가지 책임만을 가진다.
  수정할 이유가 존재하면 이것 또한 한가지 이유여야만 한다.

  위배시 절차지향적이 된다.

- OCP: Open Closed Principle (개방 폐쇄의 원칙)
  확장이 가능하고 변경은 불가능해야 한다. 확장되는 부분은 추상화하고 기능추가 되는 부분은 상속이나 다형성을 이용한다. 코드에 대한 변화요구가 발생하면 변화와 관련된 구현을 추상화해서 수정해야 한다. 새로운 요구사항에 대해서 많은 수정을 하지 않게 만들어지면 OCP를 잘 지켜 개발한 것이다.

  따라서 소프트웨어 모듈은 변경하지 않고 확장하여야 한다. 확장성을 높이기 위해 느슨한 결합원칙을준수한다.

 

- LSP: Liskov Substitution Principle (리스코프 치환 원칙)

  확장된 소스가 기존의 소스를 대체 할 수 없다. 상위타입의 객체를 하위타입의 객체로 치환해도 상위

       타입을 사용하는 프로그램은 정상적으로 동작해야 한다.

  Client가 어떤 상속관계에 있을 때 객체를 상위 클래스로 캐스팅을 할 때 문제가 발생하는지?

  is a 관계가 맞는지 확인해 본다.

 

- ISP: Interface Segregation (Interface 분리 원칙)

  클라이언트는 자신이 사용하는 메서드에만 의존해야 한다. 사용하지 않는 인터페이스에 영향을 받지

않아야 한다. 어떤 클래스가 다른 클래스에 종속될 때에는 가능한 최소한의 인터페이스만을 사용한다.

 

- DIP: Dependency Inversion Principle (의존 역전의 원리)

  고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다. 저수준 모듈이 고수준 모듈에서 정의한 추

상타입에 의존해야 한다. 추상화 기능으로 추상타입(인터페이스)를 도출하여 고수준,저수준 모듈이

추상타입에 의존하게 만든다.

  클라이언트는 사용을 할때 구체 클래스보다는 인터페이스, 추상클래스를 사용하라는 것. 인터페이스

를 바라보고 있으면 구체클래스가 바뀌더라도 클라이언트가 변경할 필요가 없다.

 

 

 

 

queryForObject

1개의 레코드를 가져온다.

1개이상 반환시 예외처리

값이 없으면 null 반환

** Map, int, String 으로만 리턴받을 수 있음

 

queryForList

1개이상의 레코드를 가져온다.

List로 받는다.

** Map, list 모두 리턴 가능함(리스트형식)

 

http://examples.javacodegeeks.com/enterprise-java/spring/beans-spring/spring-bean-scopes-example/