Top Category

Go Conference 2024参加レポ

はじめに先日、オフラインで開催された Go Conference 2024 に参加してきました。 https://gocon.jp/2024/ Go Conference で登壇デビューできた感想と、リアタイできた発表のレポートをしていきます。発表レポ(というか感想)は、リアタイできた発表をご参照ください。(しばらくポエムになります) 発表緊張した… 当日の発表スライドはこちらです https://gocon.jp/2024/sessions/21/ まずは、発表のためにフィードバックをいただいた皆さんほんとにありがとうございました！！また、激励してくれた同僚＆元同僚にもほんとに感謝です 🙏 どうしても発表は緊張するものなのですが、スライドはみんなに見てもらって恥ずかしくないものを持ってきた、というのが心の支えになりました。おかげで、当日は気持ちよく発表することができました。会場からの反応もいただくことができて、発表後のエゴサが止まりませんでした笑こちらもありがとうございます👋 足向けて寝られないぐらいお世話になってる oapi-codegen#gocon — RADISH (@ruby_engineer) June 8, 2024 oapi-codegenの生成コードを使うと、endpointごとに個別のミドルウェアを差し込めない課題がある。わかる！そうだよそこだよ！ #gocon — 鹿 (@mizushika1) June 8, 2024 oapi-codegenメインで使ってるから助かる#gocon — パンダム/rymiyamoto (@rymiyamoto129) June 8, 2024 ちょうど oapi-codegen で chi のサーバーボイラープレートを試してたけど、パスごとのカスタムミドルウェア周り課題あるなあというのを思ってた #gocon — なかりょー / giftee エンジニア (@nakaryo79) June 8, 2024 同じような面白実装作っていた（パスベースではなくリクエストベース）https://t.co/i6QKnMimh2#gocon — k1LoW (@k1LoW) June 8, 2024 oapi-codegenもechoも今使ってる！気が合いそうだフロントでもバックエンドでもスキーマ駆動すると、OpenAPIが神様になるので良い#gocon

Tuesday, June 11, 2024 Read

2023年の振り返り

はじめに今年はここ数年でも特に怒涛の 1 年でした。公私共に変化が激しくて、心が折れそうになりながらもなんとか乗り切った感があります。いつも通り(?)需要の有無に関わらず振り返っていきたいと思います。バックナンバー 2021 年の振り返り 2022 年の振り返り 2023/01 仕事新年明けてすぐ、所属チームを異動することになりました。入社してから n 年後には、そのチームでチャレンジしたいと思っていたのですごくワクワクしました。プライベート週 1 で ROOFTOP サウナに行ってました。 #サウナ今年のサウナ初めでした。こちらに来るのは４，５回目です。２時間で4セット回しましたがあっという間でした。今日のアロマは木？の香りで、ロウリュ直後... (＠ ROOFTOP in 東京都, 杉並区) https://t.co/pavDmbYmWE — reo (@_uhzz_) January 6, 2023 2023/02 仕事チームを異動してすぐに、翌月のリリースに向けた機能開発が始まりました。都度リードエンジニアに設計方針を確認しながら、のびのび開発できました。コミット量はこんなかんじ副業前職で副業を始めました。正社員時代と同じチームに参加させていただくことができ、業務内容もバックエンド開発がメインです。大学以下の科目習得試験を受験しました。 Web アプリケーション離散数学 Web 技術基礎特に離散数学で扱うグラフ理論は、入学してから一番 Computer Science してるなと実感しました。プライベート高校からの友人に結婚のご祝儀を渡しました。祝儀袋を買って、お金を包むイベントは初めてだったので、とても感慨深かったです。 2023/03 仕事 2 月に開発していた機能をリリースしました。詳細はこの後で触れるのですが、チームを異動して初めてのリリースでした。プライベート軽井沢観光に行きました。長野出身の同僚に教えてもらって、旧軽井沢銀座通りやミカド珈琲を巡りました。

Sunday, December 24, 2023 Read

2022年の振り返り

はじめに１年経つのは早いですね。今年のサマリーとしては、通信大学へ入学したことと転職したこと、です。去年はこのブログの投稿を増やしていくと意気込んでいましたが実績は、、意気込みは大事なので来年も意気込んでいきます💪 振り返りについては需要の有無に関わらず書いていきたいと思ってる所存です。バックナンバー 2021 年の振り返り 2022/01 とくに話すトピックはありませんでした。新年一発目こそなにかあれよ！と自分でツッコミを入れたくなったので、意識的に１月にイベントつくっていきます 2022/02 コロナの感染拡大がまた出てきたころで、予定されていた開発合宿がオンラインでの開催になりました初のオンライン合宿開催！開発合宿についてご紹介！ Gatherはこのとき初めて使いましたが、会議室に入ると強制的にビデオ通話になったりホワイトボードを共有したりと Google Meet や Zoom のような使い方ができるのに加え、マップを自分たちでつくったりゴーカートができたりと、息抜き要素があったのが推しポイントです。このとき気に入って、合宿のあともオンボーディングを Gather でやってたりもしたなぁと思い返したり😌 2022/03 とくに話すことはありませんでした。 2022/04 ふらっと Kyash のイベントを見にいきました。 Kyash TechTalk #2 - Serverside のシステム構成とアーキテクチャこのとき、Kyash のサーバ構成を知れたのもそうですが、苦労話や課題に思っていることを対外的に発信しているのを見て、技術力求められそうだなというのと、中の人楽しそうに話してるなと思ったのを覚えています。このイベントのあと、メールでカジュアル面談のお誘いをもらったので、転職活動はしてなかったけど、興味本位でセッティングしてもらったのが今年の転職につながりました。またプライベートな話題としては、通信大学に入学しました【通信教育課程】帝京大学理工学部情報科学科に編入学しました入ってから８ヶ月目で思うことは、年間 12 科目の単位を働きながら取るのは絶対ムリ！ではないかもしれませんが、ギリギリを攻めている感覚と怠惰な休日の時間を取りづらくなるということです。これは勉強するリズムがついていいじゃないかという反面、興味が薄い科目に関して場当たり的な勉強をしてしまいがちなのと、休日を授業やレポートで埋めると休みが休みでなくなってしまう悲しみを少なからず感じるということです。この振り返りは、来年 2 月の区切りのいいところで改めて記事にしようと思います。 2022/05 ジムに行き始めました。きっかけはリモートワークをしていて一日座ってる時間が長いと寝つきが悪かったりするので、体を動かしてぐっすり眠りたい、と思ったからです。今も継続して週に 2 回くらいは走りに行ってます。走るマシン（トレッドミル）しか活用できてないので、来年はほかのトレーニングにも手を出したいです。 2022/06 とくに話すことはありませんでした。 2022/07 通信大学の初めての単位習得試験があり、物理的な会場での受験でした。内心なにかしら交流があるかも😌、とそわそわしていましたが、杞憂に終わりました。 2022/08 昨年から月 1 で参加していた『プログラミング言語 Go』オンライン読書会が一区切りつきました。初めて参加した社外勉強会がこの読書会だったので、個人的に印象深く、毎回新しい知見を得る場として楽しませていただきました。今は柴田先生が主催するべつの読書会に参加していますが、相変わらず聞き専になってしまっているので、恥ずかしがらずに質問していくのを来年の抱負にしようと思います笑 2022/09 今年は通信大学に入ったのを言い訳に、技術書以外の本を買ったり読んだりする機会が少なかったんですが、その中でも社会学のテキストが個人的に面白かったので、マイベストブックにノミネートしました。社会学新版 (New Liberal Arts Selection) これまでぼんやり社会学を勉強したいなと思ってたところでこの本を強制的に読むことになり、ざっと主要なトピックを俯瞰することができました。

Saturday, December 31, 2022 Read

netパッケージで非推奨のTemporaryメソッドの扱いについて

はじめにこちらはKyash Advent Calendar 2022 の 13 日目の記事です。今年の 11 月に Kyash に入社しました！サーバサイドチームのueharaです👋 今回はnet/httpパッケージの非推奨メソッドであるTemporary()について、社のメンバーから知見を共有してもらったのでその話をします。 net/http パッケージの非推奨メソッド Temporary() について Temporary()については、フューチャー社の記事にわかりやすくまとめられています。 https://future-architect.github.io/articles/20220203a/ 上記の記事を踏まえて、ここでは非推奨になった経緯と対応について言及しようと思います。サッと概要を話すと、Temporary()はnet.Errorインターフェースに定義されているメソッドで、一時的なエラーかどうか判定するために用意されています。ただし、「一時的」というのがうまく定義されていないとの理由で、こちらのメソッドは Go1.18 で非推奨になりました。 net.Error.Temporary has been deprecated. https://tip.golang.org/doc/go1.18 Temporary()が非推奨になった経緯前提として、net.Errorインターフェースは、以下のように定義されています ※ソースは Go 1.19 です // An Error represents a network error. type Error interface { error Timeout() bool // Is the error a timeout? // Deprecated: Temporary errors are not well-defined. // Most "temporary" errors are timeouts, and the few exceptions are surprising.

Tuesday, December 13, 2022 Read

Futureパターンが使われているOSSを見てみた

はじめに @uh-zzです！この記事は、Go Advent Calendar 2022の 10 日目の記事になります！今年は、個人的に色々なことに挑戦した年だったなあと振り返るとともに、去年のアドベントカレンダーからもう１年経つのか〜という気持ちですこの記事では、Go における Future パターンをご紹介できればと思います Future パターンとはあるメソッドを呼び出すとします。もしもオブジェクトが、そのメソッドを実行できる状態なら、実行します。でも、実行できない状態なら、将来実行できる状態になるまで待つようにしたいとします。その時に使えるのがこの Future パターンです。 future は「未来」という意味ですもう少し正確にお話しましょう。単にあるクラスに「実行できる状態になるまで待つ」という機能を入れるわけではありません。すでに存在しているクラスに一皮かぶせて、「実行できる状態になるまで待てるような機能を追加する」というのが Future パターンです。出典: 結城浩, Future パターン, デザインパターン紹介上記の参考記事内では、Java をつかったマルチスレッドプログラミングで Future パターンが実装されています。引用箇所の説明がほぼすべてですが、イメージ図で補足するとこんな感じになります flowchart LR 呼び出し元 --> Futureメソッド -- 実行できるようになるまで待つ --> 処理するメソッド呼び出し元と処理するメソッドの間に Future メソッドを挟むことで、Future メソッドがプロキシ的に働き、非同期的に処理するメソッドを実行できるようになっています。 Go だとこんなかんじにかけるらしい以下の記事で Future/Promiseという説明書されています https://ascii.jp/elem/000/001/486/1486902/ package main func readFile(path string) chan string { // ファイルを読み込み、その結果を返すFutureを返す promise := make(chan string) // readFile とは別のゴルーチンでファイルを読み出す go func() { content, err := os.

Saturday, December 10, 2022 Read

履修科目一覧をNotionでつくりました

ご連絡 4 月から通信大学での学習を始めて、もう少しで半年になります。節目というか、ちょっと時間ができたので、私が履修している科目一覧を Notion で管理しようと思い立ち、さくっと作ってみました。科目一覧 - Notion これから同じように学習される方の参考になれば幸いです。（私も諸先輩方のブログを見て、参考になったので恩返しできれば！）近況元気にやっています👋 備考表紙イラスト：Loose Drawing

Sunday, September 4, 2022 Read

2022年07月に読んだ記事とか本とか

はじめに読んだ記事とか本のリンクを張っておきます読んだ記事アーキテクトに求められるマインドとは / mindset for an architect 「少なくとも、最悪ではないアーキテクチャを狙う」自分の中で新しい視点だった(常に選択肢の中で(世間的に)最善とされているものがいいという思考をしてる) 「変更が容易であれば、最初から望ましいアーキテクチャを正確に設計しなければならないという、プレッシャーも少なくなる」 Re: スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている Spring で快適な DB 疎通ユニットテストライフを送りたい yaml、json、または csv などのファイルでテスト用データの事前投入や結果比較を容易にしてくれます Database RIder はテストメソッド単位で使用するデータファイルを指定できる友達に教えてもらった。テストデータをコードと別で、テスト前後の比較も簡単にしてくれるのはすごい。「“楽しくないけどお金のためにやる人”はやはり伸びない」まつもとゆきひろ氏が説く“プログラマーに向いている人” 「ノーコードによって仕事が奪われるイメージはない」まつもとゆきひろ × 高橋直大 × 楠正憲が語る、これからのプログラマーの仕事 Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service まだよんでない Domain-Driven Design Simplified. まだよんでない読んだ本自分に気づく心理学-加藤諦三(著) Lean と DevOps の科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)-Nicole Forsgren Ph.D. (著), Jez Humble (著), Gene Kim (著), 武舎広幸 (翻訳), 武舎るみ (翻訳)

Tuesday, July 5, 2022 Read

【通信教育課程】帝京大学理工学部情報科学科に編入学しました

はじめに表題の通り、今年の 4 月から帝京大学理工学部情報科学科の通信教育課程に 2 年次編入しました。そもそもの経緯と入るまでの話、入って 1 ヶ月経過した後の所感をまとめておきたいと思います。きっかけ大学進学について通信制大学へ進学したいと思ったのは今年に入ってからではなく、ここ 2 年くらい検討していました。当初は理工系ではなく、社会学/哲学に興味があり、その方面の勉強がしたいと漠然と考えていました。ただ 2 年の間、大学への入学を躊躇してたのは以下の理由がありました。通信制大学の卒業が難しい、また卒業率が低いといった情報を見て腰が重かった働きながら時間が取れない、平日のフルタイムかつ出社している場合、早朝か、仕事から帰ってきて勉強時間を確保する必要が出てくるので、リモートできないと厳しいとりあえず入門書を買って積んでおけば自分で勉強できるし、進学しなくてもいいのでは？と諦めムードを出していた以上の理由から悩んでは忘れるを一人繰り返しては日々を過ごしていました。キャリアについて考えるようになったそんな中、昨年末に以下の記事を拝見しました。生涯現役のソフトウェアエンジニアでありたい。IC（Individual Contributor）のキャリアパスがあると自覚するまで 10 年の軌跡 IC(Individual Contributor)というキャリアがあるのかというのと、記事中の主張から自分のキャリアについて振り返る様になりました。これまでのキャリアは前述のようにかなり行きあたりばったりでしたが、その中にも不動となる主軸が 2 つありました。(中略) 1 つは「毎日楽しく開発したい」ということ。(中略) もう 1 つの軸は「選択肢を常に複数確保する」ことです。(中略) この「毎日楽しく開発したい」は、私がエンジニアになりたいと思った動機「楽しく(刺激的に)生きたい」に通じるものがあり、IC というキャリアないしはテクニカルスキルをあげることで自分の幸福につながるのかという気づきがありました。遠回りのような近道のような、どちらとも言えないですが、自分で出した答えの１つが大学進学、それもコンピュータに関する学位を取得するということでした。ここについては自分の中で消化しきれていない部分もあるので、別の記事で改めて振り返ることにします。帝京大学に決めたのはそこまで時間がかからなかったフルタイムで働きながらコンピュータに関する学位が取得できる通信制大学は、調べた限りだと選択肢は限られました。また、同じくエンジニアとして働きながら勉強されている方のブログが大変参考になりました。帝京大学理工学部(通信教育課程)の社会人大学生 1 年目をふりかえる帝京大学の通信教育課程の学生やってます @gkzvoice さんには twitter でブログに関して質問させていただき、またアドバイスまでいただいたので感謝です。入るまでの手続きなど詳細な手続きは募集要項にあるので、ここでは所感を述べるだけにします。調査書、成績表の発行を、所属していた専門学校に依頼する必要があるので、余裕を持って出願する志望理由を記載する必要があるので、動機と抱負は棚卸ししてたほうがスムーズかも 2 年次編入について今回 2 年次編入で出願することができました。というのも、情報系専門学校の 2 年制を卒業しているので、編入の要件を満たしていたからというのが理由です。要件を満たしていれば、専門学校での授業内容がまとめられたシラバス？を願書と一緒に提出した後、大学にて専門学校の授業内容から、関連する大学側での科目が履修済みとして、認定されます。今回は認定された科目が上限数に達していたので、晴れて編入することができたのでした。そして入学しました出願から約 2 ヶ月後、晴れて入学式を迎えることができました。

Tuesday, May 31, 2022 Read

2021年の振り返り

はじめに今年のふりかえりをするために個人ブログを数ヶ月ぶりに更新しています。しばらくぶりに拙ブログを見ていて、ぜんぜんメンテしてなかったや。。の反省を強く感じたので来年はアウトプットをもっともっと増やします！ 2021/01 とくに話すトピックはありませんでした。読んでた本改訂 2 版みんなの Go 言語 Go プログラミング実践入門　標準ライブラリでゼロから Web アプリを作る 2021/02 とくに話すトピックはありませんでした。読んでた本達人プログラマー ―熟達に向けたあなたの旅― 第 2 版 2021/03 このころから年内に引っ越しを考えはじめました。部屋に不満はありませんでしたが、ぼんやりと中央線沿い(=東京の西側)がかっこいいというイメージをもっていたので一人でちょくちょく出向いていました。主に、杉並区エリア(中野/高円寺/阿佐ヶ谷/荻窪)を中心にまわっていました。特に、荻窪にある杉並アニメーションミュージアムは、展示も楽しく見れますが、ミュージアムが入っている杉並会館の雰囲気が抜群にいいのでおすすめです。 2021/04 転職しました。社会人４年目にして３社目になります。前職と同じくサーバーサイドのポジションです。前職では、コロナ以降フルリモートでしたが、転職後は週３出社になりました。出社になってからは、ランチをメンバーと取るようになり、コミュニケーションが増えたのがメリットに感じました。仕事に関して前職では主に、Java/Go/Node.js での開発を２年ほどしていましたが、転職直後は Ruby on Rails での開発がメインになりました。はじめての Ruby と Rails ということもあり、メンバーにはだいぶお世話になりながらも、プライベートではおすすめの参考書をかたっぱしから読む生活をしていました。読んでた本プロを目指す人のための Ruby 入門言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plus シリーズ) パーフェクト Ruby on Rails 【増補改訂版】 (Perfect series) リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) 2021/05 緊急事態宣言の期間に入り、ほぼフルリモートになりました。この頃のコミットを見てみると、主に Rails プロジェクトでのバグフィックスや、小さな機能追加をしていました。

Friday, December 31, 2021 Read

達人プログラマーとは

はじめにエンジニアとしてコードを書くようになって、もうすぐ２年というタイミングに差し掛かりました心境の変化としては、がむしゃらに毎日のタスクを通して「動く」コードを書くことから、メンテナンスしやすいコードを意識することが多くなりました「達人プログラマー」は、プログラマとして次のステップを踏み出そうというときにベストな一冊となっています達人の哲学ソフトウェアのエントロピーの話は心当たりがありすぎたエントロピーとは、物理学の用語で「ある系における無秩序の度合い」のことで、時間が経つたびにエントロピーは増大していくソフトウェアも同様に、時間が経つたびに無秩序になっていくこれを割れ窓理論というメカニズムで説明していたのもわかりやすかった窓が１枚割れているのを長期間放置しておくと、それをメンテナンスする気力もなくなるマインドが植え付けられて、最終的には建物全体が破壊されていくソフトウェアではこれを、悪い設計、誤った意思決定、質の悪いコードに見立てることができて、放置しておくと潜在的なバグを生み出すことになりかねないこういった「割れた窓」を発見したと同時に速やかに修復するべきだ、そして時間がなくてもコメントを残すといった何らかのアクションをしてくださいと言った主張だった茹でガエルの話は、ある程度精神的に余裕がないと気づくことが難しいと感じたあっつあつの熱湯にカエルを放り込むとびっくりして飛び出してくるが、常温の水にカエルを入れて段々と温度をあげていくと、カエルは気づかないまま茹で上がると言った話要するに、いつもメタ認知を意識して行動しようということこれは仕事に限らずしていきたい達人のアプローチ章前半のDRY 原則については膝を叩いて同意できるといった実感があったまた、曳光弾の考え方については目からウロコだった複雑なシステムを構築していくときに、各機能を一つずつ作り込んでいくのではなく、各機能を最低限使えるようにするシンプルな箇所を探していくといった手法シンプルな箇所に最初に取り組んでその他は後回しにする（未実装）というのは初心者視点では至らないと感じた章後半のプロトタイプ、見積もりの話は現実でも問われることがあるものの、実際に見積もりが大きく外れるような難しい設計をした経験がないということもあって実感が持てなかった「言語の制約はそれを使う人の世界を制限する」 - ヴィトゲンシュタイン毎回トピックの初めに、名言があってモチベーションが上がるプログラミング言語に限らず、日常使っている日本語にも問題に対する考え方やコミュニケーションに対する考え方に影響を及ぼしているという構造主義的な話もあって興味深い基本的なツール「悩んでいる君、そしてその悩みの原因は他の誰でもない、君自身によるものだ」ということを知るのはつらいものだ - ソフォクレスデバッグの最初の心構え → 「パニクるな」妄想の達人契約プログラミング(DbC) は素晴らしい仕様を記述(契約)しておくことで、プログラマにバグになりかねないようなことをさせないプログラミングをするトラッシュ（メチャクチャ）にするのではなく、クラッシュ（停止）させる Go のif err != nilで毎回エラーチェックしてるのはこれに則っているのかなと思った。確かにcatchで新しいエラーがくるたびに分類するのは怠い気もするかな、、柳に雪折れなし列車の衝突事故を例にして依存をわかりやすく説明している１つのメソッドであまりにも多くのことをやろうとすると、連結されている全ての車両に影響が及ぶように、メソッドと属性が影響を受ける例)割引料金を算出するメソッドの中で、これらの操作を行う。顧客の注文履歴を参照する注文履歴から特定の注文オブジェクトを取得する注文オブジェクトの総額を返す総額から割引した値をオブジェクトにセットする次のような考え方がある照会せずに依頼する TDA(Tell, Don’t Ask)

Friday, March 5, 2021 Read

OAuth について

はじめにバックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。 OAuth とはひとまず、一番分かりやすい OAuth の説明で大体の感覚がつかめますのでオススメです。こちらでもざっくり説明させてもらうと、OAuth は複数のアプリを連携させるための仕組みです。例えば、ブログの記事を更新した瞬間に、ブログから更新情報をツイートしたかったりする場合に使われます。ただ、そのままツイートできるわけではなくて、ブログアプリがツイートする許可(認可)をしてあげる必要があります。そして許可されたアプリは許可証(アクセストークン)を持っていることで、Twitter を使ってツイートできるという仕組みです。メリット OAuth を使うことで、上の例であげたブログアプリは、Twitter のユーザ名とパスワードを知らなくてもツイートできるという点です。巷のアプリはこれを使うことで、Google アカウントや Twitter など SNS アカウントを持っているだけでユーザ登録できちゃいます。最初の煩わしい登録の手間が省けて良いです。 OAuth1.0 OAuth の初期バージョンです。他に 1.0a という名前のバージョンもありますが、Twitter では 1.0a を使うことができるみたいです。 (後述の 2.0 も同様に使用可) 特徴としては、認証と署名を用いて実現される仕様でありますが、実装が複雑で使用する言語が限られてしまうというデメリット?があるみたいです。(堅牢ではあると思いますが) また、1.0 は Web アプリのみ対応しているので、デスクトップ/モバイルアプリは蚊帳の外とこれまた制限されるみたいです。 (Twitter は Web アプリ以外でも使える xAuth という OAuth 拡張を開発したりしてたみたいです) さらに悲しいことに、1.0 の仕様は次の 2.0 の策定を持って廃止されたみたいです。 OAuth2.0 後継です。複雑と言われていた署名(とトークン交換)をバッサリ省いています。これによって実装しやすいものになりましたがセキュリティが気になるところです。 OAuth 1.0 のほうが OAuth 2.0 より安全なの？でも言われている通り、2.0 はクライアントアプリケーションの幅が広がった分、秘密鍵の隠蔽が難しくなるみたいです。。隠蔽できるかの違いはありますが、セキュリティレベルは両者それほど変わらないみたいです。 (2.0 は経路を TLS 化していることで、1.0 よりも提示するパラメータが少なくなっているという事実はあるそうな) まとめ実装のことを考えてこれからも 2.0 を使っていきましょうという締めです。

Tuesday, January 5, 2021 Read

システム設計-part1-

はじめにバックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。 ※現場で役立つシステム設計の原則を元に記事を作成しています。設計パターン値オブジェクト(Value Object) Java で変数を扱うとき、int や String などで型定義しがちな初心者丸出しの実装をしていた私ですが、値オブジェクトを知ったとき眼からウロコでした。値オブジェクトとは、汎用的な型(int や String)で型を定義するのではなく、専用の型(クラスやインターフェース)を定義します。範囲の広い汎用的な型を使うのではなく、業務に合わせた値で制限するというものです。値オブジェクトクラスはこんなかんじ class Quantity { static final int MIN = 1; static final int MAX = 100; int value; Quantity(int value) { if (value < MIN) { throw new IllegalArgumentException("不正" + MIN + "未満"); } if (value > MAX) { throw new IllegalArgumentException("不正" + MAX + "超"); } this.value = value; } } そして参照はこんなかんじ Quantity quantity = new Quantity(50); こうすることで Quantity 型は値の制限(0~100)付きの実装ができるので安全です。

Saturday, December 5, 2020 Read