型と何が違うんでしょうね。調べた限りでは違いはなさそうでした。エラーにならず普通に保存されます。挙動について上記では制限している文字数以上の文字を入れようとするとエラーと書きましたが、例外があります。超過分の文字列が空白の場合はそれが切り詰められて格納され、エラーにはならないようです。SQL標準の仕様らしいけど変な挙動ですね...。挙動は変わっていません。有効になっていると次のようなエラーになります。内容が元になっています。英語ですが、ここで挙げた内容以外にもコードを綺麗に保つテクニックが書かれており、かつページ数も少なく読みやすいです。コードを綺麗に保つのが好きな方は一読してみることをおすすめします。始めとして、多くのやり方が存在します*1。継承せずとも利用することができます。Objects」がそのいい例ですね。かけたい場合は、モデルに直接書いてしまう人が多いのではないでしょうか。それは悲劇の始まりでもあります。例を挙げてみましょう。友達と好きな趣味を共有しあうSNSのようなサービスを考えてみます。自分自身の変更は友達に通知される趣味は必ず1つ以上持っていなければならないとします。'好きな趣味を登録してください。何の問題もないように思えます。それぞれ、具体的に何が辛いのか見ていきましょう。辛さこのサービスは、毎日の運勢を占ってくれる機能があります。カラムに格納することにします。するとどうなるでしょうか。ユーザは、友達全員の今日の運勢を通知として毎日受け取ることになってしまいますね。処理をスキップさせることは可能です。変更したいときに、毎回それを念頭に置いてコードを書くのは大変ですね。それを忘れてしまうともっと大変です。逆に、「callbackを実行したい時だけなんらかの処理をする」という仕組みにすることもできます。endendのようにして、user.use_noticicationuser.saveのようにしたときだけ通知を飛ばすような仕組みです。これは一見うまいやり方に見えます。実際、アプリケーションコードが少ない時はこれでもうまく回ると思います。その条件分岐のためのコードによりモデルが太ってきてしまいます。実行したいようなケースもありますね。実行をオンオフするための条件式を追加するのはなるべくやりたくない感じです。モデルのユニットテストを書いてみましょう。実行されるかをテストしてみます。素直に書くとこんな感じでしょうか。endendしかしこれだとうまくテストが通りません。実行されないからですね。関連付けさせれば通ります。保存するテストコード全てに、このようなコードを追加していくのは大変です。定義自体の複雑さが増して辛いことになったりします。モデルにそのまま書くことにより、それらを必要としない場合に複雑さをもたらす例を見てきました。この複雑さを解消するにはどのようにするべきでしょうか?それには継承を使います。モデルを書きなおしてみます。'好きな趣味を登録してください。継承するようにしました。使うという形で使い分けをすることができます。モデルがスリムになりました。やりましたね!...と言いたいところですが、いくつか注意事項があります。作られないことになります。利用していたとしましょう。カラムに入れたくないですね。定義箇所を次のようにするとうまく動きます。#...endちょっと見慣れない書き方ですね。作ってしまってもいいかもしれません*2。ようなメソッドを定義することになると思います。User.find(session[:user_id])endログインユーザが自分の情報を変更するケースを考えてみましょう。クラスのオブジェクトを返してきます。オブジェクトに変換します。変換用のメソッドを用意してくれています。分割し、必要なときのみ使えるようにすることができました。このテクニックを実際に仕事のコードとして使ってみましたが、想定通りに整理されたコードを作ることが出来てなかなかよい感じです。このテクニック自体はあまり認知されておらず、知らない人が見ると面食らう可能性があるのでもうちょっと普及して欲しいところです。ここで紹介したよりももっと良い方法があるのではないか?という気持ちもあります。月別アーカイブ参加グループインターネット。