Skip to content

Latest commit

 

History

History
248 lines (219 loc) · 19.5 KB

ex4.md

File metadata and controls

248 lines (219 loc) · 19.5 KB
Raw

演習4: 迷路を散策してゴールを目指すプログラムを作ってみよう（IntelliJ + GitHub経由でペアプロ + クラス設計演習）

＜目次＞

ペア・プログラミングの目的とやり方

  • 目的
    • 課題解決に関するノウハウの共有。
      • 「早く解くこと」ではない。
  • やり方
    • 問題文が理解できない場合にはすぐに質問すること。（ここで悩むのは時間の無駄）
    • driverとobserverを決める。（10~15分程度で交代しよう）
      • driver
        • 実際に作業する（手を動かす）人。それ以外の人は直接作業してはいけない。
        • driverは作業する際に考えていることを説明しながら作業すること。分からないなら相談すること。
        • 例
          • 「まず問題読んでみよっか。〜〜（問題文）〜〜。ん、どういうことだろう？」
      • observer
        • driverの作業を眺め、気づいたこと・分からないことを質問すること。作業を中断させて構わない。
        • driverのやり方よりも良い方法があると感じたら、その旨を話すこと。

達成目標

  • Gitによるバージョン管理と、GitHubを通したリモートリポジトリの利用に慣れよう。
  • クラス設計を検討できるようになろう。（良し悪しは問わないが、設計理由を説明できるようになろう）
  • 設計したクラスを基に実装できるようになろう。
  • 考えてることを説明できるようになろう。
  • 分からない時には作業を止めて質問できるようになろう。

演習4_0: ペアプロ用リポジトリの新規作成

  • 誰か代表一人決め、GitHubにログインし、ペアプロ用リポジトリを新規作成しよう。
    • リポジトリ名: prog2-ex4
    • publicにすること。
    • Settingsをクリックし、「Collaborators」をクリック。
    • パスワードを要求されるので、入力。
    • Add collaboratorの欄に、パートナーのGitHubのusernameを入力し、Add collaboratorをクリック。
      • 3人チームの場合は、パートナー2名とも入力しよう。
      • 正しく入力できていれば、「xxx has invited you to collaborate on the yyy/prog2-ex4 repository」といったタイトルのメールが、パートナー側に届いているはず。
        • パートナーは、該当メールを開き、「View invitation」をクリック。
          • 続けて、「Accept invitaion」をクリック。
          • これで、複数人でcommit&pushできる、共用リポジトリを準備できたはず。
  • 最初のコミット
    • IntelliJにて「ex4」という名前の新規プロジェクトを作成し、プロジェクト内に、「README.md」というテキストファイルを作成せよ。
    • README.mdを編集し、以下の点を記述せよ。
      • プログラミング2の演習4をやるためのリポジトリであること。
      • 作業者2名の学科アカウント。
    • 記入し終えたら、今の状態を add, commit, push しよう。
      • README.mdをaddすること。
    • pushし終えたら、ブラウザでGitHubリポジトリを再読込し、更新されていることを確認しよう。
  • 報告内容
    • 共用リポジトリの Git URL を、google共有フォルダに報告すること。

driverを交換する際の補足（演習4_0を終了し、別の学生が演習4_1を担当するための前準備）

  • 現在の状況
    • 学生A、学生Bでペアプロをしているとする。（3人の場合は適宜読み替えて下さい）
    • 演習4_0を学生Aがdriver担当し、演習4_1を学生Bがdriver担当する場合、GitHubリポジトリの所有者は学生Aである。学生Bは共有利用している立場である。
    • GitHubリポジトリの中身は、学生AのIntelliJプロジェクトからpushした状態になっている。一方で、学生BはまだIntelliJプロジェクトが無い状態である。
  • 学生B側の準備
    • IntelliJを起動し、「Check out from Version Control」を選択。
    • Gitを選択し、Git URLをコピペ。
    • Cloneを選択して、IntelliJプロジェクトを複製する。
  • 上記のように、「他人のリポジトリをベースに作業を開始する」場合には、リポジトリのクローンを作成してから作業することになる。

演習4_1: 迷路クラスを設計（not実装）してみよう

  • 背景説明
    • 後述するファイル形式にて「迷路」に関する情報が用意されるものとする。この「迷路」をオブジェクトとして見立て、クラス設計してみよう。迷路クラスではどのようなフィールド変数やメソッドが必要だろうか。
  • 迷路は次のようなテキストファイルで用意されるものとする。
    • map.txt
      • 1行目: プレイヤーの初期位置: 左上を(0,0)とする。下記の例「2 1」は「右に2マス、下に1マス」に初期位置sを設定していることを意味する。
      • 2行目: 迷路のサイズ: 下記の例「7 8」は「横に7マス、縦に8マス」の合計56マスからなる迷路であることを意味する。
      • 3行目以降: 迷路。
        • #: 壁。移動不可。
        • : 空白。移動可。
        • s: スタート地点（移動可）。
        • G: ゴール地点（移動可）。
2 1
7 8
#######
# s   #
# #####
#   #G#
# ### #
# ### #
#     #
#######
  • 検討内容
    • map.txtのように用意された迷路ファイルを読み込み、迷路情報を保持したい。どのようなフィールド変数、メソッド、コンストラクタを用意したら良いだろうか？
      • 設計の良し悪しは問わない。設計理由を説明できるようになろう。（良い設計は何度も設計＆実装を通してレビューしたり、他人のコードをレビューすることで身につくようになる）
      • e.g.,
        • プレイヤーの初期位置をどう保存したら良いか？（プレイヤーが迷路に入った際の初期位置であって、現在位置ではない。入り口と考えよう）
        • 迷路サイズをどう保存したら良いか？
        • 迷路情報をどう保存したら良いか？
        • map.txtは一例である。同じ書式で記載された他迷路であっても同様に読み込めるようにするにはどうしたら良いか？
        • アクセサ（getter/setter）は必要だろうか？
        • 他に迷路クラスが果たすべき機能はなんだろうか？
  • 考え方の例
    • まずは内部実装（クラスをどう実装するか）を無視し、外部実装（クラスをどう使うか）から考えたほうが良い。
    • 設計したクラスから生成したオブジェクトをどう使いたいか？
      • 例えば、ファイル出力の例では、オブジェクト生成時にファイル名を指定し、用意したオブジェクトに対してwriteメソッドで書き込み、closeメソッドで閉じるという流れで処理している。
    • 使い方に目処が立ったら、そのように利用するためにどのようなフィールド変数・メソッド・コンストラクタが必要か検討してみよう。
  • 報告内容
    • 仮案で構わないので、検討した迷路クラスの設計（クラス名、フィールド変数、メソッド、コンストラクタ）を報告せよ。
      • IntelliJにて「ex4」という名前の新規プロジェクトを作成し、プロジェクト内に、srcフォルダと同じ階層に「doc」フォルダを作成せよ。
      • docフォルダ内に「class-design.txt」or「class-design.md」という名前で設計内容を記述せよ。作成したファイルを add, commit, push せよ。
      • 書式は自由で構わない。
    • pushし終えたら、google共有フォルダに「演習4_1終了」ぐらいのコメントと「チェックサム」を書いておこう。

driverを交換する際の補足（演習4_1を終了し、別の学生が演習4_2を担当するための前準備）

  • 現在の状況
    • ここまでで、以下の2バージョンをpushしている状態である。
      • 演習4_0: 学生Aがpush
      • 演習4_1: 学生Bがpush（これが最新版）
    • これから演習4_2を学生Aがdriver対応したいが、IntelliJプロジェクトの中身は古いまま（演習4_0のまま）である。
  • 学生A側の準備
    • IntelliJを起動し、演習4_0で使用したプロジェクトを開く。
    • VCSメニューからGitを選び、「Pull」を選択する。
    • Pull Changesウィンドウが現れる。設定を変更せず、そのまま「Pull」を選択。
    • 正しくPullが機能すると、最新状態に更新されるはずだ。演習4_1で追加したファイルが有ることを確認しよう。
  • 上記のように、「複数人で作業している」場合には各々のローカルプロジェクトのバージョンが混在した状態になりがちである。最新状態にするためには Pull することを覚えておこう。

演習4_2: プレイヤークラスを設計（not実装）してみよう

  • 検討内容
    • 演習4_1の迷路クラスのように用意された時、その迷路内を移動するプレイヤークラスを設計してみよう。この際、歩いた歩数（移動したマス数）を計測できるようにしよう。どのようなフィールド変数、メソッド、コンストラクタを用意したら良いだろうか？
    • この時点では「上に移動する、下に移動する」のように1歩移動する機能が用意されていれば十分とする。（ゴールを目指すアルゴリズムは不要）
      • e.g.,
        • プレイヤーの現在位置をどう保存したら良いか？
        • 歩数をどう保存したら良いか？
        • 迷路内を移動するにはどのような機能が必要だろうか？
        • アクセサ（getter/setter）は必要だろうか？
        • 他にプレイヤークラスが果たすべき機能はなんだろうか？
  • 報告内容
    • 仮案で構わないので、検討したプレイヤークラスの設計（クラス名、フィールド変数、メソッド、コンストラクタ）を報告せよ。
      • docフォルダ内の「class-design.txt」or「class-design.md」というファイルに追記する形で設計内容を記述せよ。作成したファイルを add, commit, push せよ。
        • pushし終えたら、google共有フォルダに「演習4_2終了」ぐらいのコメントと「チェックサム」を書いておこう。
      • 設計の良し悪しは問わない。設計理由を説明できるようになろう。（良い設計は何度も設計＆実装を通してレビューしたり、他人のコードをレビューすることで身につくようになる）

演習4_3: 迷路クラスとプレヤークラスのインスタンスを生成し、テスト移動するMainクラス（mainメソッド）を実装してみよう。

  • 検討内容
    • 現時点では迷路クラスとプレイヤークラスはどちらも未実装である。ここでは実装できたと仮定して、どのようにインスタンスを生成するのか、生成したインスタンスをどう利用するのかを検討しよう。
    • 実現させたい内容
      • map.txtを読み込んだ迷路インスタンスを生成。
      • map.txtの初期位置にプレイヤーインスタンスを生成。
      • 現状（プレイヤー現在位置を含んだ迷路）を表示。
      • プレイヤーインスタンスを左に移動。
      • 現状表示。
      • プレイヤーインスタンスを下に移動。
      • 現状表示。
      • プレイヤーインスタンスを右に移動しようとしてその場に留まる。（壁で移動できない）
      • 現状表示（前回と同じ場所であることを目視確認）
    • 繰り返しになるが、この時点ではまだ迷路クラス・プレイヤークラスが未実装のため、Main.javaはコンパイル自体できないため、動作確認もできない。まだ、「こう実装したいな」という思いを明文化している段階ですので、動かなくて良いです。
    • 上記の「実現させたい内容」を踏まえて、設計した迷路クラスとプレイヤークラスに不十分な点があれば、アップデートしよう。
      • クラス設計を記述しているファイルを編集すること。
  • 報告内容
    • Mainクラスのmainメソッド。
      • src/main/(パッケージ名)/Main.java を作成し、そこに記述せよ。作成したファイルを add, commit, push せよ。
        • パッケージとして jp.ac.uryukyu.ie.ex2.pair00 を指定するものとする。（ペア番号は適宜修正すること）
        • pushし終えたら、google共有フォルダに「演習4_3終了」ぐらいのコメントと「チェックサム」を書いておこう。
    • クラス設計をアップデートしたのであれば、更新内容とその理由。

演習4_4: 迷路クラスを実装してみよう。

  • 最終的な迷路クラス設計に基づき、実際に実装しよう。
    • 実装途中で設計に不備があることに気づいたのなら、設計ファイルを編集した上で実装にも反映しよう。
  • 報告内容
    • src/main/(パッケージ名)/迷路クラス.java を作成し、そこに記述せよ。作成したファイルを add, commit, push せよ。
      • pushし終えたら、google共有フォルダに「演習4_4終了」ぐらいのコメントと「チェックサム」を書いておこう。
    • 「迷路クラス.java」は適切なファイル名にすること。

演習4_5: プレイヤークラスを実装してみよう。

  • 最終的なプレイヤークラス設計に基づき、実際に実装しよう。
    • 実装途中で設計に不備があることに気づいたのなら、設計ファイルを編集した上で実装にも反映しよう。
  • 報告内容
    • ソースコード
      • src/main/(パッケージ名)/プレイヤークラス.java を作成し、そこに記述せよ。作成したファイルを add, commit, push せよ。
        • 「プレイヤークラス.java」は適切なファイル名にすること。
        • pushし終えたら、google共有フォルダに「演習4_5終了」ぐらいのコメントと「チェックサム」を書いておこう。
  • 実行結果
    • 演習4_5を終えた時点で、迷路クラス、プレイヤークラス、Main.javaはコンパイルが通り、mainメソッドを実行できるはずである。その実行結果を示そう。

演習4_6: ゴールを目指す散策プレイヤーのアルゴリズムを検討してみよう。

  • 検討内容
    • プレイヤークラスは、自身でどのように散策するかの機能を保持していない。プレイヤーオブジェクトが自身で考え、迷路内を移動してゴールを目指すアルゴリズムを検討しよう。ただし「ずっと乱数で移動先を選び、運が良ければゴールに辿り着く」のはNGとする。
  • 報告内容
    • 検討したアルゴリズムを報告せよ。docフォルダ内に「walk-algorithm.txt」or「walk-algorithm.md」という名前でアルゴリズムを記述せよ。作成したファイルを add, commit, pushせよ。
      • pushし終えたら、google共有フォルダに「演習4_6終了」ぐらいのコメントと「チェックサム」を書いておこう。

演習4_7: プレイヤークラスを継承し、検討したアルゴリズムで行動する散策プレイヤークラスを設計（not実装）してみよう。

  • 検討内容
    • プレイヤークラスの継承を前提とし、検討したアルゴリズムをどのように実装したら良いか、検討せよ。どのようなフィールド変数、メソッド、コンストラクタを用意したら良いだろうか？
  • 報告内容
    • 仮案でかまわないので、検討した散策プレイヤークラスの設計（クラス名、フィールド変数、メソッド、コンストラクタ）を報告せよ。
      • docフォルダ内のclass-design.txt or class-design.md に追記すること。記述し終えたら add, commit, push すること。
        • pushし終えたら、google共有フォルダに「演習4_7終了」ぐらいのコメントと「チェックサム」を書いておこう。

演習4_8: 散策プレイヤークラスを実装してみよう。

  • 最終的な散策プレイヤー設計に基づき、実際に実装してみよう。
    • 実装途中で設計に不備があることに気づいたのなら、設計ファイルを編集した上で実装にも反映しよう。
    • 実装した散策プレイヤーが、想定通りに動くことを確認できるようにMain.javaを修正しよう。
    • 作成＆編集したファイルを add, commit, push せよ。
      • pushし終えたら、google共有フォルダに「演習4_8終了」ぐらいのコメントと「チェックサム」を書いておこう。
  • 報告内容
    • ソースコード
      • src/main/(パッケージ名)/散策プレイヤークラス.java を作成し、そこに記述せよ。
        • 「散策プレイヤークラス.java」は適切なファイル名にすること。
      • 同様に、Main.javaを編集せよ。
    • 実行結果