별 찍기 알고리즘
•
필요한 개념 : 반복문
•
정사각형
n을 받으면 n * n 사이즈의 사각형을 출력
public class SquareStar {
private void printSquare(int n){ // 정사각형
for (int i = 0; i < n; i++) {
System.out.println("***");
}
}
public static void main(String[] args) {
new SquarStar().printSquare(4);
}
}
Java
복사
•
직사각형
public class SquareStar {
private void printRectangle(int x, int y) { // 직사각형
for (int i = 0; i < y; i++) {
System.out.println("*".repeat(x)); // x만큼 반복하는 repeat메소드
}
}
public static void main(String[] args) {
new SquarStar().printSquare(4, 5);
}
}
Java
복사
•
재귀함수 이용한 사각형
public class recursiveStar {
public void triangl(int x, String now){
if(x==0) return;
else{
System.out.println(now); // x != 0 이면
triangl(x-1, now + "*"); // 문자열 자료형 now에 *을 붙인다.
}
}
public static void main(String[] args) {
new recursiveStar().triangl(5, "*");
}
}
Java
복사
Connection
분리하는 이유 및 주요 관심사항
•
관심사의 분리
◦
객체지향 설계가 이전 절차지향 프로그래밍에 비해 초기에 번거로운 작업을 요구한다.
◦
사실은 번거로운 작업을 요구하는 이유는 객체지향 기술 자체에는 변화에 효과적으로 대체 가능할 수 있다는 기술적 특징 때문이다.
◦
변화가 한 번에 한 가지 관심에 집중돼서 일어난다면, 우리가 준비해야 할 일은 한 가지 관심이 한 군데에 집중되게 하는 것이다.
◦
즉,
관심이 같은 것끼리는 모으고, 관심이 다른 것은 따로 떨어져 있게 하는 것이다.
•
관심사항
◦
장기간 운용되는 서버에 올라가려면 예외 상황에 적절하게 대응해서 공유 리소스를 반환하지 않는 일이 없도록 세심하게 주의해야 한다.
◦
그것과 관련된 첫번째 관심사항은 DB연결을 위한 Connection 오브젝트를 가져오는 방법이다.
◦
관심사의 분리원칙을 적용하여 독립적으로 확장 가능한 클래스를 만들고자 한다.
리팩토링
•
코드에서 중복되는 아래 부분을 모아 메소드로 묶을 수 있다
◦
리팩토링에선 이를 메소드 추출 기법이라고도 부른다
•
리팩토링이란?
◦
기존의 코드 동작방식의 변화 없이 내부 구조를 변경해서 재구성하는 작업을 말한다.
◦
코드의 이해하기가 편해지고, 변화에 효율적으로 대응할 수 있다.
◦
견고한 제품을 위해 꼭 필요한 작업이다.
•
이 아래 부분은 모두 리팩토링 과정이다.
분리 1 : 상속클래스로 분리
상속의 문법인 abstract, extends 부분을 위주로 변화를 확인할 수 있다.
UserDaoAbstract.java
LocalUserDaoExtends.java
AWSUserDaoExtends.java
분리 2 : Class로 분리
관심사가 다르고 변화의 성격이 다른 두 가지 코드를 본격적으로 독립시키면서 동시에 손쉽게 확장할 수 있는 방법이 있다.
DB 커넥션과 관련된 부분을 자식 클래스가 아닌, 아예 별도의 클래스에 담는 것이다.\
AWSConnection.java
UserDao.java
두 가지 문제가 발생한다.
1.
자유로운 확장을 위해서 openConnection() 메소드 이름을 사용했지만, UserDao 내에 있는 add()/get() 메소드의 커넥션을 가져오는 코드를 일일이 변경해야 한다.
2.
DB 커넥션을 제공하는 클래스가 어떤 것인지 UserDao가 구체적으로 알고있어야한다는 점이다.
•
UserDao에서 AWSConnection클래스의 인스턴스 변수까지 정의해놓았으므로
•
만약 Localconnection 클래스에서 구현하려면 어쩔 수 없이 UserDao의 커넥션 코드를 변경해야 한다.
ex) 사용할 메소드 이름, 어떤 클래스를 import해서 사용할지 등등.
이러한 이유로 UserDao는 DB 커넥션을 가져오는 구체적인 방법에 종속되어 버린다.
분리 3 : Interface 도입
클래스를 분리하면서도 이런 문제를 해결할 수는 없을까? 물론 있다.
가장 좋은 해결책은 두 개의 클래스가 서로 긴밀하게 연결되어 있지 않도록 중간에 추상적이고 느슨한 연결고리를 만들어주는 것이다. “implements”
인터페이스
인터페이스는 자신을 구현한 클래스에 대한 구체적인 정보는 모두 감춰버린다.
오브젝트를 만드려면 구체적인 구현체가 필요하겠지만,
인터페이스를 통해 접근하는 쪽에서는 오브젝트를 만들 구현체클래스가 무엇인지 몰라도 된다.
인터페이스 클래스 : ConnectionMaker.java
UserDao.java
인터페이스 구현체
마무리
UserDao 코드를 자세히 보면 AWSConnectionImplement() 클래스를 객체 생성 해주는 모습을 보인다.
즉 , AWSConnection클래스의 생성자를 호출해서 오브젝트를 생성하는 코드가 여전히 UserDao에 남아 있다.
여전히 UserDao 소스코드를 함께 제공해서, 필요할때마다 생성자 메소드를 직접수정하지 않고서는 자유로운 DB커넥션 확장 기능을 가진 UserDao를 제공할 수 없는 상황이다. “원점”
다음 시간에는 UserDao와 UserDao가 사용할 ConnectionMaker의 특정 구현 클래스 사이의 관계를 설정해주는 것에 대해 관심있게 다룰 것이다.
이 부분이 UserDao에서 분리되지 않으면 UserDao는 결코 독립적으로 확장 가능한 클래스가 될 수 없을 것이다.