============================================================================== Why Extending Through Subclassing (a framework's classes) is a Bad Idea (翻訳) ============================================================================== (フレームワーククラスの)サブクラス化による拡張はなぜ悪いアイデアか Original text is written by Ben Bangert, on October 18, 2010. :Author: Ben Bangert :Translator: Nozomu Kaneko .. note:: この文書は Ben Bangert の `blog 記事`__ の翻訳です。 原文はこの文書のソースコードに含めてあります。 __ http://be.groovie.org/post/1347858988/why-extending-through-subclassing-a-frameworks .. Ok, I'll admit it, overly ambitious blog post. So I'll refine it a .. little now, this is intended mainly as my thoughts on why as a tool .. developer (one who makes tools/frameworks that other programmers then .. use), its a bad idea to implement extensible objects via developer .. subclassing. This is actually how the web framework I wrote - Pylons - .. provides its extensibility to developers and lets them change how the .. framework functions. オーケー、認めよう。これが過度に野心的なブログポストであることを。だか らもう少し洗練した言い方をすると、これは、ツール開発者 (他のプログラマ が利用するツール / フレームワークを作る人) として、サブクラス化によって 拡張が可能なオブジェクトを実装することが、なぜ悪いアイデアなのかに関す る私の考えを主として意図している。このアイデアは実際に私が書いたウェブ フレームワーク (Pylons) で、開発者にその拡張性を提供し、フレームワーク の機能を変更させる方法である。 .. Please excuse the short and possibly incomplete description, this is .. mainly a quick post to illustrate a tweet I recently made. この説明が短く、そして恐らく不完全なことを許してほしい。これは主として 私が最近行った tweet を説明する quick post だ。 .. First, some background... 最初に背景を少し... ------------------------------ .. One of the things that Pylons 1.0 and prior is missing is a way to .. easily extend a Pylons project. While it can be done, its very ad-hoc, .. kludgy, and generally not very well thought-out. Or thought-out at all .. really. What was somewhat thought-out was how a developer was supposed .. to extend and customize the framework. Pylons 1.0 とそれ以前に欠けているものの一つは、 Pylons プロジェクトを容 易に拡張する方法だ。それは可能だが、非常に ad-hoc で kludgy (いいかげん) そして一般にあまりよく tought-out (考え抜かれる) されていない。あるいは 実際には全く thougt-out (されていない)。多少 thought-out されたことは、 フレームワークの拡張およびカスタマイズを開発者がどのように行うかという ことだった。 .. In a Pylons project, the project creates a PylonsApp WSGI object, and .. all the projects controllers subclass WSGIController. This seemed to .. work quite well, and indeed many users happily imported PylonsApp, .. subclassed it to extend/override methods they needed for .. customization, or changed how their WSGIController subclass worked to .. change how individual actions would be called. Pylons プロジェクトでは、プロジェクトは PylonsApp WSGI オブジェクトを 作成し、すべてのプロジェクトコントローラは WSGIController をサブクラス化 する。これは、とてもうまくいくように見えたし、実際、多くのユーザが カスタマイズに必要なメソッドを拡張/オーバーライドするために喜んで PylonsApp をインポートして、それをサブクラス化した。また、個別の アクションがどのように呼ばれるかを変更するために、 WSGIController サブクラスがどのように働くかを変更した。 .. Everything seemed just fine.... until... すべてはうまくいっているように見えた... あのときはまだ... .. Improving Pylons Pylons を改善する ------------------------------ .. When I had some free time a little while back, I set about looking .. into how to extend and improve Pylons to make up for where it was .. lacking, extensibility. I quickly realized that I'd need to change .. rather drastically how Pylons dispatch worked, and how controller .. methods were called to make them more easily extendable. But then with .. a certain feeling of dread, the subclassing issue nipped me. All my .. implementations of PylonsApp and WSGIController were **effectively .. frozen**. しばらく前に、少し時間があったので、私は Pylons に欠けているもの、すな わち拡張性を強化するために Pylons を拡張し改善する方法について調査に着 手した。すぐに分かったのは、Pylons ディスパッチがどのように働くか、また コントローラメソッドがどのように呼ばれるかに関して、それらをより容易 に拡張可能にするためにはかなりドラスティックな変更が必要だということだ。 しかし、次第に恐怖感とともにサブクラス化の問題が私を苦しめるようになった。 私の実装した PylonsApp と WSGIController のすべては、 *事実上凍結* され ていたのだ。 .. Since every single developer using Pylons sub-classes WSGIController, .. and to a much lesser extent, PylonsApp, any change to any of the main .. methods would result in immediate breakage of every single Pylons .. users app that happened to customize them (the very reason subclassing .. was used!). This meant that I couldn't very well change the .. implementation of the actual classes to fix their design, because that .. would just cause complete breakage. Ugh! Pylons を使用するすべての開発者は WSGIController をサブクラス化していて、 またそれよりも頻度は少ないが PylonsApp もサブクラス化されることがある。 そのため、主要なメソッドのどれかに対するどのような変更も、それらを何気 なくカスタマイズしたすべての Pylons ユーザのアプリに即座の breakage を もたらすだろう (このようなカスタマイズができることは、まさにサブクラス 化が使用された理由だ!)。これは、設計を修正するために実際のクラス実装を あまり変更することができない、ということを意味している。なぜなら、 すぐに完全な breakage を引き起こすからだ。げっ! .. So after looking into it more, I've ended up with this short list of .. the obvious bad reasons this shouldn't be done. BTW, in Pylons 2, .. controllers don't subclass anything, and customization is all with .. hooks into the framework, no subclassing in sight! それで、さらに調査した結果、これ (サブクラス化による拡張) をすべきでな い明らかに悪い理由のリストができあがった。これに対して、 Pylons 2 では コントローラは何もサブクラス化しない。また、カスタマイズはすべてフレー ムワークに対するフックにより行われる。サブクラス化はどこにもない! .. Short List of Why It's Bad それがなぜ悪いかの短いリスト ------------------------------ .. From a framework maintainers point of view... フレームワークメンテナーの観点から ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. 1. Implementations of the classes are effectively frozen, because .. **all the class methods are the API**. 1. *すべてのクラスメソッドが API* なので、クラスの実装は事実上凍結される。 .. 2. Correcting design flaws or implementation flaws are much more .. difficult if not impossible without major breakage due to point #1. 2. ポイント #1 により、設計上の欠陥あるいは実装上の欠陥の修正が大きな breakage なしでは不可能な場合、そのような修正は非常に困難である。 .. 3. Heavily sub-classed/large hierarchy classes can have performance .. penalties. 3. 重度にサブクラス化された/巨大な階層クラスにはパフォーマンス上の ペナルティを受けることがある。 .. From a developer 'extending' the classes point of view... クラスを「拡張」する開発者の観点から ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. 1. Figuring out how to unit-test is more difficult as the full .. implementation is not in your own code... its in the framework code. 1. 完全な実装が自分自身のコードの中にはないので (それはフレームワーク コードの中にある)、どうやって単体テストをすればいいのか理解することが より困難である。 .. 2. When using mix-in's and other classes that also subclassed the .. framework, strange conflicts or overrides occur that aren't at all .. obvious or easy to debug/troubleshoot. 2. フレームワークをさらにサブクラス化した mix-in や他のクラスを使用した 場合、奇妙な衝突あるいはオーバーライドが生じる。これらは全く明白では なく、デバッグ/トラブルシュートするのが簡単でない。 .. I think there were a few more reasons I came across as well, but I .. can't recall them at the moment. In short, I'm now of the rather firm .. opinion that the only classes you should ever subclass are your own .. classes. Preferably in the same package, or nearby. この結論に至るまでには、これ以外にも若干の理由があったと思うが、今はそ れらを思い出せない。手短に言えば、サブクラス化して良いのは常に自分自身 のクラスだけ (できれば同じパッケージの中で、あるいはその近くで)、という のが今の私の比較的確固とした意見である。