- 運営しているクリエイター
記事一覧
【Java+Junit5】例外を期待するテストをする
適切な例外が発生するかどうかをテストしたいときのやりかた。
assertThrowsを使って例外が発生することを確認するassertThrowsを使うことで、期待した例外が発生したかどうかを確認することが出来ます。
public class なんかのクラス_の_テスト{ @test public void 例外を期待するテスト(){ // Arrange Book テストデータ
【Java】StringからIntにしたりDateからStringにしたりStringをDateにしたり
テスト用に、データベースに入れる情報を用意→データベースに登録→登録した情報を取り出して比較、というロジックを作ったら、入れる用のデータはJSONで受け取る前提だから全部Stringで渡さなきゃいけなくて、出してくるデータはテーブルカラム通りの型で出てくるもんだから困ったね、ということで全部変換していくよ!
とりあえずざっくりキャストできればOK!細かいフォーマットの違いとか例外が発生する文字が入
【Java+MyBatis】データ登録系API作成時に、登録に成功したレコードの、自動採番で付与されるIDを返却する
「このデータを登録しておくれ」「はいよ、登録したよ、レコード番号〇〇番として登録できたよ」というAPIを作る際、肝心の「レコード番号〇〇番として登録できたよ」をどうやって取得しようか。というお話。
レコード番号は通常自動採番に設定するじゃないですか。いちいち最新のレコード番号取得して+1してとかしないじゃないですか。あんまり。
でも、SQLでInsertする処理は登録処理をするだけで、「今まさに
Javaで配列やリストをカンマ区切りのStringに変換する
こっちも検索履歴増えてきましたね。
String.join("区切り文字",配列)でできるString[] hoge = {"test", "string", "dayo"};String fuga = String.join(",", hoge);
出力
>test,string,dayo
Listも同じようにできるList<String> hogehoge = Arrays.asLis
Javaで配列をさっさと作ったり配列の中を検索したり
「Java 配列 あるか」での検索履歴が増えて参りました。
さっとその場でリストを作って、「ここの数値がこのリストの中身に合致するときだけ処理をする」みたいなコードをパパッと作りたい時用です。
とりあえず結論検索が必要なら配列じゃなくてArrayListを使え
【追記】さらにさっさとArrayList作れたList<String> hogeArrayList = Arrays.asList(
【Javaお勉強日記】mybatisを使って独自クラスとカラムに対して複雑なマッピングをする
必要になったのでまとめます。
0.サービスを作る// BookService.javapublic class BookService{ BookRepository bookRepository; public BookService(BookRepository bookRepository){ this.bookRepository = bookRepository;
【Javaお勉強日記】mybatisを使ってDBから情報を取得するところまで
いっこずつ整理していきましょうね。
1:サービスを作る// BookService.javapublic class BookService{ BookRepository bookRepository; public BookService(BookRepository bookRepository){ this.bookRepository = bookReposi
【Javaお勉強日記】JUnitを使ってテストを自動化する・基礎の基礎編
テストのやり方、一回確認したのに綺麗さっぱり忘れていたので覚え書きです。
前提条件・VScodeでJavaが動かせるようになっている
・ビルドツールにはGradleを使う
インストールするものVScodeのエクステンション
build.gradleに追記
testImplementation group: 'junit', name: 'junit', version: '4.4'
必
【Javaでドメイン駆動設計を実現する-7】オブジェクト指向で開発したり、勉強するコツについて
こちらの続き。このテキストに沿って勉強してきた内容のまとめ記事の、最後の記事になります。
最早表題の「Javaで~」関係ない分野に入ってきましたが、シリーズということで一応、そのまま。
オブジェクト指向的に開発するにはよーしオブジェクト指向で開発すっぞ! と思っても、今までのウォータフォール式の開発手法では、せっかくのオブジェクト指向の良さが引き出せないままに、なんとなくオブジェクト指向っぽい
【Javaでドメイン駆動設計を実現する-5】画面の設計とドメインオブジェクトの設計を揃えたい
この記事の続きです
「なんでも出来る画面」からの卒業「会員情報を変更するぞー」という画面があって、そこで名前も住所も電話番号も支払い方法も何もかも変更できるようになっている、というのはよくある設計ですが、それだと画面とバックグラウンドを繋ぐ処理のところが大わらわになってしまって、修正がしづらい画面になってしまいます。
そこで、名前なら名前、住所なら住所、と項目ひとつひとつについて変更するための
【Javaでドメイン駆動設計を実現する-4】データベースの設計とドメインオブジェクトの関係について
これのつづき。
テーブル設計をすっきりさせて変更を容易にするテーブル設計がごちゃごちゃしていると、「NULLが入ってきたらどうしよう」とか「イレギュラーな値が入っていた場合の対応は……」とか考えないといけなくて、結局プログラムもわちゃわちゃしてきてしまいます。
そこで、テーブル設計をスッキリさせて、変更を容易にしていきたいと思います。
テーブル設計をスッキリさせる、NotNull制約と一意性
【Javaでドメイン駆動設計を実現する-3】Application層を変更に強くする
SpringBoot的には@Service。
これのつづき。
サービスクラス、ごちゃごちゃしがち問題UI(Presentation/Controller)層からの要求に応じてドメインオブジェクトを返すのがApplication層(サービスクラス)の仕事。
それだけのはずなんだけど、サービスクラスは常にごちゃごちゃしがち。その原因を整理して、スッキリスリムなサービスクラスを作れるようになりたい
【Javaでドメイン駆動設計を実現する-2】三層アーキテクチャとドメインモデルの分離
これのつづき。
三層アーキテクチャって何だったっけこれ。
この例ではレイヤーが「四層」になっていてドメインが既に分離されてるけど、元々は「Presentation+Application+DataSource」の三層構造が一般的だったそうで。
ところが、三層構造で作っていくと、Application層にうぞうぞと業務ロジックが増えていって、結局変更に弱いアプリケーションになってしまう。
の
【Javaお勉強日記】ドメイン駆動設計をどうやってJavaプログラムに落とし込んでいくかをお勉強する-1
ソフトウェアを変更に強くしたいソースがごちゃごちゃしていると、ちょっとした変更がとんでもない場所に影響を及ぼしたりして大変である。
私はそれを昨日痛感しました。(VBAですが、二年前の自分が書いたコードの大幅改修が必要になり……まだやっとVBAでマクロが作れるようになったばかりの頃のコード……レイヤードアーキテクチャを意識どころか関数の切り出しすらろくに出来ていない恐ろしいコード……一箇所の変更