チェスタスクレビューの整理

異常処理の方向性

チェスタスクでは,ソースからターゲットまで所定の方向に連続して1格移動し,障害物を確認する論理がある.
file値とrank値を加算し、一定の方向を減算してセルを移動します.移動ロジックは指定した方向にboard内部の値に移動しているため、位置値がboardを超えないため、いくつかの例外処理が必要になる可能性があります.try catch文を使用して例外をキャプチャしnullを返します.しかし、これは実際の論理では使用されません.いったいどこまで例外なのか.
コードは以下の通りです.

//Position class -> 실질적으로 Position값을 direction으로 향할 때 쓰는 메서드
public Position move(final Direction direction) {
	return new Position(direction.moveFile(file), direction.moveRank(rank));
}

//File class -> 가로 방향 이동
public File move(final int distance) {
    try {
        return of((char) (value + (char) distance));
    } catch (IllegalArgumentException exception) {
        return null;
    }
}
//Rank class -> 세로 방향 이동
public Rank move(final int distance) {
    try {
        return of(value + distance);
    } catch (IllegalArgumentException exception) {
        return null;
    }
}
//MoveCheker -> Position class의 move메서드를 사용하는 메서드, 구현 로직 상으로는 Position이 Baord 밖으로 나갈 일이 없다
private boolean isBlocked(final Direction direction, final Position from, final Position to) {
    final Position next = from.move(direction);
    if (next.equals(to)) {
        return false;
    }
    if (!board.findPiece(next).equals(new EmptyPiece())) {
				return true;
    }
    return isBlocked(direction, next, to);
}

このような組織の原因は以下の通りである.
enumに一定範囲内の定数がある場合、enumを使用すると範囲外の値を減らすことができる条件文であり、その定数を検索する際に便利です.
したがって,特にFileやRank Enumは位置値であるため,Enumで作成された定数以外の値が現れると処理が必要となる.
最初に例外を投げ出すと、移動中にユーザーの意図とは異なる例外が発生する可能性があるためnullを返す必要があります.
この部分についてコメント依頼を行い,コメンテーターの回答を聞いて例外処理に対する考え方が変わった.
私の考えは以下の通りです.
ウッドコは早期に異常処理項目と機能カタログを一緒に書いたが,この過程で詳細に異常処理を行うのがうまくいったようだ.だからポケモンを捕まえるように、現れない例外さえ探したい.
例外処理は、ハードウェア上でもソフトウェア上でもコストがかかります.
例外を生成するには、個別のコードが必要であり、処理にもコードが必要です.
私たちは潜在的な例外を減らすために雇われた人かもしれません.
そのためには、良い構造を考慮して良い設計を行う必要があります.
そこで,上記のコードは過剰なプログラミングと見なすことができ,異常処理部分を削除したと結論した.

継承プロセスで使用されないメソッド

私の例では、チェス盤に置くPieceを抽象的なクラスに変え、KingやQueenのような器物を作ってPieceを継承しました.
しかしチェス盤に器物がないところがあるはずなのに、なぜかこの部分をnullに保存したくない.
そこで、空のPieceをEmptyPieceというクラスを作成し、抽象クラスpieceを継承します.
この過程で、私は評論家に評論要求を要求して、私はこの時Unsupported OperationExceptionを投げ出すことで実現できることを知っています.

テストコードの一貫性を維持

今回、テストコードを作成する際、@DisplayNameがほぼ完了しているが内容がない非常に短いテストについては、@DisplayNameを書くべきではありません.
この程度の和弦は書くべきではないという愚かな考えを、どうして評論家が知って評論したのだろうか.
コードの理解性と一貫性をテストするために.  @DisplayNameまたは削除と書いて、統一したほうがいいです.
チームに新しい開発者が協力しているとき、どこに書いてあるのか、どこにないのか、混乱します!@DisplayNameを書く時間よりも、書くべきかどうかを考える時間がかかります. 😬
アプリケーションを理解するために、まずテストコードをチェックすると理解しやすい場合があります.
私は協力の経験がほとんどありません.
だから私はいつも他の人が私のコードを見ているのが見えません.
コメンテーターのコメントを参考にすると、私は新しく来た開発者だと思って、私のコードを見る習慣は?同じものがあるはずだ!

ファイルの最後に実行

コメントを受け入れる前に、すべてのファイルの末尾に行があるはずだとは知らなかった.
アプリケーションはすぐに実行されないわけではありませんが、githubにエラーが表示されます.

その結果、CコンパイラgccはPOSIXに従って実行された.ソースコードが行単位で読み取られ(行単位)、ファイルの末尾にEOFがなければ問題が発生するからである.
このため、ファイルが終了しても文字が開いていないため、1行が終了していないと正常に動作しないという問題が発生する可能性があります.

ドメインに対する私の誤解

今回のタスクでは、ドメインの考え方を少し書きました.ドメインはビジネスロジックの場所であり、ビジネスロジックはアプリケーションを完了するために必要なロジックだと思います.
だから必要な論理でなければドメインではないと思います.
たとえば、ビューは要求を遵守するために必要な論理ではありません.したがって、ビューはドメインではありません.
問題はstateを使って慣れない状態モードを試してみることです
今、私の誤解に対して、stateはドメインではないと思っていました.stateがなくてもアプリケーションを完成できるからです.
stateがなくてもアプリが完成すると思うので、必ずしもこれを使わなくても別の部分で代用できるとは限らないし、どうせ他の部分が必要だし、考えればゲームを作るためには、これは必須のロジックだと思います!

リソースを直接閉じる場合は、try-with-resourcesではなくtry-finallyを使用します。

Daoを直接実装して使用する場合、JDBPに次のように接続するように要求します.

@Override
    public void save(final String name, final String position, final Long gameId) {
        final String sql = "insert into board (name, position, gameId) values (?,?,?)";
        try {
             final Connection connection = JdbcConnector.getConnection();
             final PreparedStatement statement = connection.prepareStatement(sql)
            statement.setString(1, name);
            statement.setString(2, position);
            statement.setLong(3, gameId);
            statement.executeUpdate();
            connection.close();
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }

この場合、try終了時にリソースを自動的に解放するtry-with-resourcesはjava 7から提供される.
try構文が終了すると、Javaはオブジェクトの close() メソッドを呼び出します.
使用方法はtry宣言でカッコを作成し、残りの内容をそのまま書き、カッコ内でcloseリソースを使用して使用します!
コメントを反映するコードは以下の通りです.

@Override
    public void save(final String name, final String position, final Long gameId) {
        final String sql = "insert into board (name, position, gameId) values (?,?,?)";
        try (final Connection connection = JdbcConnector.getConnection();
             final PreparedStatement statement = connection.prepareStatement(sql)) {// 이 부분은 안넣어도 된다!
            statement.setString(1, name);
            statement.setString(2, position);
            statement.setLong(3, gameId);
            statement.executeUpdate();
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }

Java 9では、try-with-resourcesがさらに改良されたため、元のtry文外宣言のリソースはtry文内で使用できないため、内部で再初期化する必要がある.
しかしjava 9から外部宣言のリソースも改善されtry文で使用できるようになった.

//자바 9이전엔 이렇게 사용했어야 했다.
try (final Connection connection = JdbcConnector.getConnection();) 
//자바 9부터는 아래와 같이 사용해도 된다.
final Connection connection = JdbcConnector.getConnection();
try (connection)

今回は良いコメンテーターにお会いして、学んだことは上の文章の他にも、まだ完全に把握していないものがたくさんあるので、これだけ書けばいいのです!
昨日よりもっと成长して欲しい