緒論

次の位置に接続します.
リンク

機能リストの実装を再確認

前の記事でも述べたように,開発初期にはクラス設計,メソッド設計など,機能リストをあまり具体化しないほうがよい.いつでも変わる可能性があるからだ.例外やコーナーボックスなどの例外の処理も少なくなります.
例は以下のとおりです.

ユーザーが入力した名前をカンマで区切る

ユーザー名が5文字未満であることを確認

自動車はランダム値が4より大きい時に

前進する.

4未満の場合、

に戻る.

台以上の自動車の中で最大の位置値

を実現した.

...

ハードコーディング禁止

文字列、数値値をハードコーディングしないでください.定数値が必要な場合は、名前を付けてロールを表示することが望ましいです.Java定数のようなキーワードで検索すると定数に関する良い情報がたくさんあります.確認する

APIを積極的に利用する

直接方法を実施する前に、言語で提供されるapiを特定してから提供してください.では、積極的に使用しましょう.

String result = String.join(",", winners) // List<String> winners

配列ではなく集合を利用する

これは上記に関連する提案です.集合については、Javaが提供するAPIが非常に多いため、通常、機能固有の方法を実装するために配列を使用する必要はありません.

オブジェクトへのメッセージの送信

ステータスデータを持つオブジェクトからデータを取得してモデルを取得するのではなく、オブジェクトにメッセージを送信する必要があります.

// bad
private boolean isMaxPosition(Car car) 

// good
car.isMaxPosition(maxDistance) // Car 는 기본 Class

Instance Valueの削減

フィールドの多くは、オブジェクトの複雑さを増し、エラーの可能性を高めます.
重複または不要なフィールドがあるかどうかを確認し、フィールドの数を最小限に抑えます.そうしないと、クラスの作成後に依存関係を確立することが望ましいです.

//bad
public class Winner {
	private List<Car> cars;
    private List<String> winnerList;
    private int maxDistance;
}

//good
public class Winner {
	private List<Car> cars;
    
    private int getMaxDistance() { ... }
    
    public List<String> getWinners() { ... }
}

ビジネスロジックとUIロジックを分離

1つのクラスがビジネスロジックとUIロジックを担当することを回避します.
われわれは常に単一責任の原則を銘記しなければならない.

public class Car {
	private int position;
    
    public void move(int randomValue) { ... }
    
    // bad
    private void print(int position) { ... }

}

現在のオブジェクトのステータスを表示するログ・メッセージの性質が強い場合は、toString()によって実現されます.ビューで使用するデータの場合は、getterメソッドでデータを渡します.

関数行の条件

15行程度に減らします.少なくともディスプレイ画面に1つの方法が見えるのが一番です.
この基準はmain関数にも適用されます.注記はできるだけ関数の外、またはコードの右側に表示します.

発生する可能性のある例外を考えてみましょう。

通常の状況を実現するよりも、例外をプログラミングに考慮するのは難しい.例外をよく考慮するプログラミング習慣を養う.これは符号化テストにおいても大きな助けとなる.コーナーボックス...コーナーボックス...

コメントが必要な場合は、

gitで管理するリソースも考慮します。

すなわち.gitignoreを覚えておいて、アップロードする必要のない部分は断固として外部管理から排除します.自動生成ファイル...あるいは、依存パッケージのみがインストールしやすい部分です...これらは敢えて抹消する.
参考までに.zipファイルは知らず知らずのうちに提出され、重くなりすぎて提出できなくなり、最終的にフィルタリングの経験がある私はそれが非常に重要であることに気づいた.