この記事はGMOペパボ Advent Calendar 2017の13日目の記事です。 最近まで取り組んでいたこととして、10年以上ペパボを支えてきたサービスの一部Webアプリケーションにおいて、PEAR::DBの使用をやめて、PDOの使用に変更するというものがありました。 この記事では、取り組みの動機や、どのようなアプローチを採ったのか、また、そこから得られた知見などを紹介します。おそらく、相応に老舗であるPHPアプリケーションでしか、PEAR::DBと向き合う機会はないと思われますので、万人向けの記事ではないことを予めお断りしておきます。 動機と背景 まずはじめに、PEAR::DBとPDOについて、簡単に触れたうえで、今回の取り組みの動機と背景について整理します。 PEAR::DBとは PEAR::DBとは、PEARで提供されているデータベース抽象化のためのライブラリです。PEARのサ
class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.active? hogehoge.histories.last.update(state: :cancel) return error_message end case hogehoge.kind when "type_a" # ... when "type_b" # ... end ActiveRecord::Base.transaction do history.save! history.create_foobars end end end 何が酷いって、機能が何なのか
24. よくない設計 ! ／￣￣＼ ／ _ノ ＼ | （ ●）（●） | （__人__） | ｀ ⌒´ﾉ | } ヽ } ヽ､.,＿＿ __ノ _, ､ -― ''"::l:::::::＼ｰ-..,ノ,､.ﾞ,i ､ /;;;;;;::ﾞ:':､::::::::::::|＿:::;､>､_ l|||||ﾞ!:ﾞ､-､_ 丿;;;;;;;;;;;:::::i::::::::::::::／:::::::＼ﾞ'' ﾞ||i l＼>::::ﾞ'ｰ､ . i;;;;;;;;;;;;;;;;;;;;;;|::::::::::::::＼::::::::::＼ .||||i|::::ヽ::::::|:::! 年齢は？ 店員（売る人） ! ／￣￣＼ ／ _ノ ＼ | （ ●）（●） | （__人__） | ｀ ⌒´ﾉ |
あとでもうちょい詳しく書きます。
OO の方面から、「静的型とか別に役に立つとは思えない、静的型の人は頭おかしい」 とか関数型の方面から、「静的型が役に立たないなんてはずない OO の人は頭おかしい」 とか良く聞こえてくるんですが、ダックタイピング心理学 とかいう真に頭おかしい意見を無視できるとすると（無視できない量あるんですが）、まあ私にはどっちもわからんでもない、という話です。 型をゴミ箱に捨てておいてから、後でゴミ箱を漁るなら、型なんかいらない オブジェクトの静的型システムを大雑把にいうとまず upcast と downcast があります。 upcast はオブジェクトの静的型をそれが属するクラスからそのスーパークラスにを変えちまうこと、downcast はその逆、オブジェクトの静的型をそれが属するクラスから子クラスに変えちまうことです。サブクラスの物はスーパークラスとしても通用するはずですから upcast は失
紹介 - Introduction どうやって Tiny CLOS を使うか - How to Use Tiny CLOS CLOS vs. 他のOOPのアプローチ - CLOS vs. other approaches to OOP CLOS のクラスとオブジェクト - Classes and Objects in CLOSインスタンスの生成 - Creating instances クラスの作成 - Creating classesインスタンス変数 - Instance Variables 総称関数とメソッド - Generic functions and methods総称関数の作成 - Creating generic functions メソッドの作成と追加 - Creating and attaching methods 総称の初期化 - The initialize gene
この記事では、私がオブジェクト指向のどこを愛しどこを素晴らしいと感じていて、そのうえでなぜオブジェクト指向を使うことを避けているのかを書き留めておきます。関数型言語使いの方で、「オブジェクト指向の何がいいのかわからない」「オブジェクト指向難しすぎ・複雑すぎ」とおっしゃる方にぜひ読んでいただきたいと思っています。また、「オブジェクト指向言語完璧に理解したわ」と思っている方にも読んでいただきたく思います。 なお、ここでのオブジェクト指向の定義は、「各言語でオブジェクト指向と呼ばれているものすべて」とします。JavaやScalaやJavaScriptやSmalltalkやRubyやCommon LispやOCamlがオブジェクト指向と呼んでいるものすべての総称です。もっとまともな定義が知りたい方は以下の記事がおすすめです。 オブジェクト指向の概念の発明者は誰ですか？(改訂版) - Smallta
Object-oriented programming was supposed to unify the perspectives of the programmer and the end user in computer code: a boon both to usability and program comprehension. While objects capture structure well, they fail to capture system action. DCI is a vision to capture the end user cognitive model of roles and interactions between them. Objects are principally about people and their mental mode
http://clean-ruby.com/ The classes that we begin to define should represent data or model the behavior of the data object, but *not both* 札幌でおっさんっぽい人達がDCI、DCIって言って盛り上がってたから、最近DCIについて触れるためにClean Rubyって本をゆっくり読んでみてたんだけど、筆者がこういう主張をしてて、ナルホディウス、ナルホディウスですぞーって思ってた。どう在るかというのと、どう振舞うかというのは、それぞれ別の箇所でまとめて定義されているべきとのこと。実装としては、Userみたいなclassがデータ(=どう在るか:be)を定義していて、XXXableとかXXXerみたいなmoduleが処理(=どう振る舞うか:do)を定義していて、Us
CoffeeScript is a little language that compiles into JavaScript. Underneath that awkward Java-esque patina, JavaScript has always had a gorgeous heart. CoffeeScript is an attempt to expose the good parts of JavaScript in a simple way. The golden rule of CoffeeScript is: “It’s just JavaScript.” The code compiles one-to-one into the equivalent JS, and there is no interpretation at runtime. You can u
※ネタです。マジレスしない様に ※重ねて言いますがネタです。 ※なんどもいい(ry まずは http://b0r0nji.blogspot.com/2011/12/blog-post.html を読んでください。 この説明でオブジェクト指向わかった！ってなったらそれどうなんだろうと思ってしまったわけです。で、オブジェクト指向プログラミング - Wikipedia読んでみると、 相互にメッセージ (message) を送りあうオブジェクト (object) の集まりとしてプログラムを構成する技法である。 ほう、メッセージとな。さて、先の説明にメッセージがあったか？となるわけです。 オブジェクトとはなにか 多くのOOPをサポートしていると謳っている言語はこのメッセージの送受信(Message Passing)をメンバ呼び出しという形に置き換えて、概念的にはメッセージを送り合って通信しているよう
私は陰謀論者じゃないですし JavaScript の new 演算子が大好きなわけでも大嫌いなわけでもないです。 念のため。 本記事は Hiraku さんが書かれた下記記事への言及です。 newを封印して、JavaScriptでオブジェクト指向する(1) newを封印して、JavaScriptでオブジェクト指向する(2) newを封印するべき4つの理由 new 演算子は使うな!? 「newを封印するべき4つの理由」 でも new がいかに糞であるかが書かれていますし、その記事からも言及があるように Crockford さんが書かれた書籍 『JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス』 でも new 演算子は Bad Parts に分類されています。 new 演算子が忌避される理由はいろいろあるみたいですが、Hiraku さんの記事では n
ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 その日の午後、三浦マネージャは何かの会議から険しい顔で戻ってくるなり、全開発メンバーを招集した。たまたま平良さんは私用のため、午後になってから出勤することになっていた。 「知ってのとおり、スケジュールの遅れがかなりひどいことになっているね」三浦マネージャは私たちをにらみつけた。「正直なところ、私は君たちに失望したよ。この程度のプロジェクトもまともに進められないほどスキルが低いとはね。もう少し高い単価に見合った仕事をしてほしいものだね。オブジェクト指向なんかにこだわってるからこういうことになるんだ」 室温が一気に急降下したみたいだった。相変わらず人の神経を逆なでするのが天才的にうまい人だ。 どうせ上の人からスケジュール遅延を責められて、その責任を私たちに転嫁しようとしているに決まっ
ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 コードレビューという名の、三浦十字軍の暴走は続く。 「......それから、210行めぐらいで部品マスタからデータ引っ張ってきてるけどね、ここで、PartsMasterGetterって使ってるね。これ何？」 「部品マスタへのアクセスをまとめた共通ロジック？」富永さんは自信なさそうに答えた。 「何それ？ 私に聞いてるのかね？」 「共通ロジックです」富永さんは言い直した。 「なんでわざわざ共通ロジックにしてあるの？ コードが追いにくいでしょう」 ――いや、コードをわざわざ追わなくてもいいように、切り出してあるんだって。 富永さんは助けを求めるように平良さんを見た。つられて何人かが同じ方向を見たが、平良さんは自分の爪の状態が最重要の関心事になったらしく、右手を熱心に観察していた。 「そ
忙しい人のためのまとめ 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。（ただし簡単のため、次のうち前者から批判的に派生して生じたプロトタイプベースのオブジェクト指向はここには含めていない） アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現（オブジェクトにメッセージ送信）するアイデアに基づく「メッセージングのオブジェクト指向」と、 ビアルネ・ストラウストラップ（前後して抽象データ型を発案したリスコフ本人、オブジェクトクラスを考えたニガードらSIMULA陣営、Eiffelのメイヤーらも同様の着想を得ている）による、ユーザー定義型（抽象データ型）を SIMULA67 にあった「クラス」という言語機能を使って実現（カプセル化、継承、多態性）するアイデアに基づく「抽
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
