社内勉強会でサービスクラスがなぜ存在するのかについて紹介しました - UUUMエンジニアブログ
設計と実装で 抑えておきたい サービスクラスと例外 from Takuya Sato nazoです。 最近はUUUMもエンジニアを含む開発チームもメンバーが増えてきました。メンバーが増えてきた時に、どうしても技術力にムラがある（単純に高い低いという話ではなく、得意な点や考え方が個人により異なるということ）という問題が生じます。 個別の細かい技術についてはその場で説明すれば良いのですが、「設計」と言うと単純に説明するのは難しく、そもそも人によって考え方にも違いがあります。とはいえここは抑えておいてほしいというところはあるので、社内で勉強会を開催して説明した内容を社内向け文書も兼ねて公開したいと思います。 今回は「サービスクラス」の作り方について紹介したいと思います。サービスクラスという概念はバックエンドに限らず、フロントエンドやその他様々なアプリケーションで応用できる概念かと思います。資料に
Big Sky :: Go のポインタの躓きやすい点
Go は最近のプログラミング言語にしては珍しくポインタを扱えるプログラミング言語。とはいってもC言語よりも簡単で、オブジェクトの初期化やメソッドの定義以外の場所ではおおよそポインタを使っている様には見えない。メソッドやフィールドへのアクセスも . で出来るし Duck Type によりインタフェースを満たしていれば実体であろうとポインタであろうとそれほど意識する必要はない。ところがこの便利さに乗っかってしまうと思わぬ所で足をすくわれてしまう。 package main type foo struct { v int } func (f foo) add(v int) { f.v = v } func main() { var a foo a.add(3) println(a.v) } このコードは 0 が表示される。メソッドを呼び出す際にはレシーバのオブジェクトを得る必要があるが、foo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
