이전 프로젝트에서 얻은 경험과 교훈

소프트웨어 개발의 흥분되는 부분은 어느 시점에 좋은 실천이 몇 년 후에는 더욱 모호해질 수 있다는 데 있다.심지어 완전히 틀렸다.그러나, 당신은 보통 일정 시간 내에 여러 번 이렇게 해야만 그것을 실현할 수 있다.다음은 Java 프로젝트에서 얻은 경험의 요약입니다.

층포장
내가 자바 개발을 시작했을 때, 모든 프로젝트는 층별로 그들의 클래스인 컨트롤러, 서비스, DAO (저장소) 를 구성했다.일반 프로젝트의 구조는 다음과 같습니다.

ch.frankel
  ├─ controller
  │  ├─ FirstController
  │  └─ SecondController
  ├─ service
  │  ├─ FirstService
  │  └─ SecondService
  └─ dao
     ├─ FirstDao
     └─ SecondDao

이런 방법은 두 가지 주요 단점이 있다.

가시적인 측면에서 볼 때 가방 밖에서 클래스를 사용하려면 public로 표시해야 한다.FirstController 사용FirstService이므로 후자는 반드시 public이어야 한다.따라서 다른 종류는 모두 사용할 수 있지만, 나는 그것이 '제1' 과 관련된 종류에만 사용되기를 바란다.

응용 프로그램을 분리하려면 우선 의존 관계를 분석하여 하도급 간의 결합을 해야 한다.

이러한 문제를 해결하기 위해 나는 기능별로 포장하는 것이 더욱 자연스러운 선택이라는 것을 발견했다.

ch.frankel
  ├─ first
  │  ├─ FirstController
  │  ├─ FirstService
  │  └─ FirstDao
  └─  second
     ├─ SecondController
     ├─ SecondService
     └─ SecondDao

이렇게 하면 컨트롤러는 public로 기능의 입구점을 나타낸다.서비스와 DAO는'세부 사항을 실현하는 것'이다. 그들은 package의 가시성을 가지고 가방 내부에서만 접근할 수 있다.
또 다른 장점은 코드를 분리해야 한다면 가방대로 하면 된다는 것이다.

품질 도구를 맹목적으로 준수하다
오래전, 나는 Hammurapi라는 고품질 도구를 사용하고 있다는 것을 발견했다.기록된 것은 그것이 오랫동안 업데이트되지 않은 것처럼 느껴져도 여전히 하나 online presence 있다.어쨌든, 내가 코드 라이브러리에서 엔진을 실행할 때, 가장 많이 보고된 규칙 위반 행위는 공적인 방법에서 Javadoc가 부족하다는 것이다.모든 명수와 세터가 공개된 것을 감안하면 나는 많은 것을 얻었다.
한 프로그램을 통해 JavaDocs를 자동으로 추가하는 것은 매우 쉽습니다.

/**
 Get the <code>foo</code>.

 @return Current value of <code>foo</code>
*/
public Foo getFoo() {
  return foo;
}

/**
 Set the <code>foo</code>.

 @param foo New value of <code>foo</code>
*/
public void setFoo(Foo foo) {
    this.foo = foo;
}

이것은 나로 하여금 녹색 수표의 한 면을 좋아하게 하여 만족하게 한다.그러나 부가가치가 없다.
사실상 대부분의 고품질 도구의 투자 수익률은 매우 낮다.공백이 아닌 탭을 사용했기 때문에 프로젝트의 질이 급격히 떨어지는 것은 아니다.코드의 질은 정의하기 어렵고 측정하기 어려우며 자동화된 방식으로 측정하는 것도 마찬가지다.
비록 나는 고품질의 공구를 피하겠다고 말한 것은 아니지만, 그것들이 제공한 것을 조심해야 한다. metrics엔지니어와 관리자는 도량 기준을 좋아하지만, 가장 좋은 의도에서라도 팀/조직을 당신이 가고 싶지 않은 곳으로 데려갈 수 있다.

세터
클래스를 만든 후, 자바 개발자는 항상 Getter와 setter를 생성합니다.

public class Money {

    private final Currency currency;
    private BigDecimal amount;

    public Currency getCurrency() {
        return currency;
    }

    public BigDecimal getAmount() {
        return balance;
    }

    public void setAmount(BigDecimal amount) {
        this.amount = amount;
    }
}

public class Account {

    private Money balance;

    public Currency getBalance() {
        return balance;
    }

    public BigDecimal getBalance() {
        return balance;
    }

    public void setBalance(BigDecimal balance) {
        this.balance = balance;
    }
}

이것은 바보로프의 반사와 같다.더 심각한 것은 JavaBean 약속의 일부이기 때문에 많은 도구들이 ORM 프레임워크, 서열화 라이브러리 (예를 들어 잭슨), 맵 도구 (예를 들어 Map Struct) 등에 의존한다.
따라서 이 도구 중 하나에 의존한다면 선택의 여지가 없다.만약 네가 없다면, 너는 네가 이 길을 가고 싶은지 아닌지를 고려해야 할지도 모른다.
다음은 위 과정의 대체(간략화) 설계입니다.

class Account {

    // Field and getter
    // NO SETTER!

    public BigDecimal creditFrom(Account account, Money amount) {
        // Check that currencies are compatible
        // Do the credit
    }

    public BigDecimal debitFrom(Account account, Money amount) {
        // Check that currencies are compatible
        // Do the debit
    }
}

Getter 대체 방안은 더욱 복잡한 디자인을 실현할 수 있으나, 많은 추가적인 이익을 가져오지는 않을 것이니 주의하십시오.만약 그들이 개인 데이터를 공개하지 않는다면, 변할 수 없는 대상이든 복사본이든, 나는 그것들을 보존하고 싶다.

없는 곳이 없는 추상
내가 enterprise에서 배운 첫 번째 교훈은'우수한'개발자들은 항상 다음과 같은 세 가지 구성 요소를 둘러싸고 그들의 실현을 설계한다는 것이다.

문제는 FooImpl 유일한 Foo 구현입니다. 클래스를 명명해야 할 때 이 점이 뚜렷합니다.가장 흔히 볼 수 있는 방안은 추상류 앞에Abstract를 붙이고 구체류 뒤에Impl를 붙이는 것이다.문제를 발견하는 또 다른 방법은 어디에서 이 방법을 실현하는가이다. 추상류와 구체류 사이에 가장 좋은 위치를 정하는 간단한 방법은 없다.
추상은 결합을 낮출 수 있다.그러나 응용 프로그램의 결합은 라이브러리의 결합보다 영향이 훨씬 적다.

데이터 전송 개체
나는 DTO를 사용한 지 이미 오래되었다.내 earliest blog posts는 사실상 DTO, bean 매핑과 Dozer 라이브러리에 관한 것으로 자동화 매핑 과정에 사용된다.나는 심지어 한 건축가가 나에게 각 층을 위해 전용 유형을 설계하라고 건의한 것을 기억한다.

DAO 레이어의 솔리드

동명층의 서비스 대상

컨트롤러 레이어의 뷰 개체

또한 PK가 데이터베이스 밖으로 유출되어서는 안 되기 때문에 저희는 전용 표지 부호열을 전달할 수 있습니다.
나는 네가 공사가 과도하다고 말하는 것을 들었니?너는 아마 완전히 틀리지 않았을 것이다.
이것은 나로 하여금 DTO를 생각하게 했다.만약 보기가 기초표와 매우 다르다면, 그것들은 좋은 생각일 수도 있습니다.그러나 내가 참여한 대부분의 응용 프로그램은 그렇지 않다.그들은 데이터베이스 구조를 완벽하게 모방했다.
이런 상황에서 나는 본문previous post에 열거된 기술 중의 하나를 지지할 수 있다.

결론
이 문장에서, 나는 내가 더 이상 사용하지 않을 수 있는 다섯 가지 기교를 묘사하거나, 적어도 내가 그것들을 응용하는 상하문에서 매우 조심해야 한다.
네 뒤의 세월이 길수록 네가 범할 수 있는 실수가 많아질 것이다.이 생각은 너의 경험에 근거해서 같은 실수를 반복하는 것을 피하는 것이다.라틴어로 말했듯이 인형 교정표는 마귀다.

Quality Tools: humble servants or tyrants?

Encapsulation: I don't think it means what you think it means

Are you guilty of over-engineering?

Alternatives to DTOs

최초 발표는 2022년 3월 13일A Java Geek