翻訳 第4章 : Object-oriented programming - Wikipedia

4 Design patterns デザインパターン

 

Challenges of object-oriented design are addressed by several methodologies. Most common is known as the design patterns codified by Gamma et al.. More broadly, the term "design patterns" can be used to refer to any general, repeatable solution to a commonly occurring problem in software design. Some of these commonly occurring problems have implications and solutions particular to object-oriented development.

いくつかの方法論によってオブジェクト指向設計の課題は対処されている。最も一般的なものはガンマらによって成文化されたデザインパターンとしてしられている。より広く言えば、「デザインパターン」という語句はソフトウェア設計にいて広く起こる問題に対するあらゆる一般的で再適用可能な解決方法をさすために使うことができる。これらの一般的に発生する問題のいくつかはオブジェクト指向開発に特有の含蓄と解決策を持つ。

4.1 Inheritance and behavioral subtyping 継承と行動のサブタイプ

It is intuitive to assume that inheritance creates a semantic "is a" relationship, and thus to infer that objects instantiated from subclasses can always be safely used instead of those instantiated from the superclass. This intuition is unfortunately false in most OOP languages, in particular in all those that allow mutable objects. Subtype polymorphism as enforced by the type checker in OOP languages (with mutable objects) cannot guarantee behavioral subtyping in any context. Behavioral subtyping is undecidable in general, so it cannot be implemented by a program (compiler). Class or object hierarchies must be carefully designed, considering possible incorrect uses that cannot be detected syntactically. This issue is known as the Liskov substitution principle.

継承が「is a」関係をつくりだすということを推測して、それゆえにサブクラスからインスタンス化されたオブジェクトがスーパークラスからインスタンス化されたオブジェクトの代わりとして常に安全に使う事ができると考えることは直感的なことだ。この直感は残念ながらほとんどのオブジェクト指向プログラミング言語、特にミュータブルなオブジェクトを許しているすべての言語では、間違っている。(ミュータブルなオブジェクトを持つ)オブジェクト指向プログラミング言語の型チェッカーが強制するサブタイプのポリモルフィズムはあらゆる状況での行動のサブタイプを保証できない。行動のサブタイプは通常は決定できないので、プログラム(コンパイラ)が実行できない。クラスやオブジェクトの階層構造は注意深く設計されなければならない。その際、文面からは検知できない起こりうる間違いを考慮する。このトピックはリスコフの置換原則としても知られている。

4.2 Gang of Four design patterns

Main article: Design pattern (computer science)

Design Patterns: Elements of Reusable Object-Oriented Software is an influential book published in 1995 by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, often referred to humorously as the "Gang of Four". Along with exploring the capabilities and pitfalls of object-oriented programming, it describes 23 common programming problems and patterns for solving them. As of April 2007, the book was in its 36th printing.

オブジェクト指向における再利用のためのデザインパターン』はErich Gamma, Richard Helm, Ralph Johnson, and John Vlissides(よくおどけて4人のギャングと言われる)によって1995年に発行され、大きな影響をもたらした本である。オブジェクト指向プログラミングの能力と落とし穴を探求したことに加えて、23個の共通するプログラミングの問題とそれらを解くためのパターンを説明している。2007年4月に36版まで出版された。

The book describes the following patterns:

この本では以下のパターンを説明している。

  • Creational patterns (5): Factory method pattern, Abstract factory pattern, Singleton pattern, Builder pattern, Prototype pattern
  • Structural patterns (7): Adapter pattern, Bridge pattern, Composite pattern, Decorator pattern, Facade pattern, Flyweight pattern, Proxy pattern
  • Behavioral patterns (11): Chain-of-responsibility pattern, Command pattern, Interpreter pattern, Iterator pattern, Mediator pattern, Memento pattern, Observer pattern, State pattern, Strategy pattern, Template method pattern, Visitor pattern

4.3 Object-orientation and databases オブジェクト指向とデータベース

Main articles: Object-relational impedance mismatch, Object-relational mapping, and Object database

Both object-oriented programming and relational database management systems (RDBMSs) are extremely common in software today. Since relational databases don't store objects directly (though some RDBMSs have object-oriented features to approximate this), there is a general need to bridge the two worlds. The problem of bridging object-oriented programming accesses and data patterns with relational databases is known as object-relational impedance mismatch. There are a number of approaches to cope with this problem, but no general solution without downsides.[28] One of the most common approaches is object-relational mapping, as found in IDE languages such as Visual FoxPro and libraries such as Java Data Objects and Ruby on Rails' ActiveRecord.

オブジェクト指向プログラミングと関係データベース管理システムの両方が今日のソフトウェアで極度に共通している。関係データベースはオブジェクトを直接保存せず、(ただ、いくつかのRDBMSではこれに近いオブジェクト指向の機能を提供している)一般的には2つの世界の間の橋が必要だ。オブジェクト指向プログラミングのアクセスとデータのパターンと関係データベースとの橋をかけることの問題はインピーダンスミスマッチとして知られる。この問題へ対処は数多くあるが、欠点のない一般的な方法はない。最も一般的な手法の一つはオブジェクト関係マッピングであり、これはVisual FoxProなどのIDE言語やJava Data Objects 、 Ruby on Rails' ActiveRecordといったライブで使われる。

There are also object databases that can be used to replace RDBMSs, but these have not been as technically and commercially successful as RDBMSs.

RDBMSを置き換えうるオブジェクトデータベースもあるが、これらはRDBMSほど技術的にも商業的にも成功しているとは言えない。

4.4 Real-world modeling and relationships

OOP can be used to associate real-world objects and processes with digital counterparts. However, not everyone agrees that OOP facilitates direct real-world mapping (see Criticism section) or that real-world mapping is even a worthy goal; Bertrand Meyer argues in Object-Oriented Software Construction[29] that a program is not a model of the world but a model of some part of the world; "Reality is a cousin twice removed". At the same time, some principal limitations of OOP have been noted.[30] For example, the circle-ellipse problem is difficult to handle using OOP's concept of inheritance.

オブジェクト指向プログラミングは現実世界の物体や処理をデジタル世界のそれと関連付けるために使う事ができる。しかしながら、オブジェクト指向プログラミングの機能が直接現実世界にマッピングできるとか、現実世界のマッピングは悪い結果すら起こすと、全員が同意しているわけでない。Bertand MeyerはObject-Oriented Software Constructionでプログラムは世界のモデルでなく世界の一部のモデルであると主張している。「リアリティーは2度取り除かれたいとこである。」同時に、オブジェクト指向プログラミングのいくつかの原理的な制限が述べられている。例えば、円と楕円問題はオブジェクト指向プログラミングの継承といった概念を使って処理することは難しい。

However, Niklaus Wirth (who popularized the adage now known as Wirth's law: "Software is getting slower more rapidly than hardware becomes faster") said of OOP in his paper, "Good Ideas through the Looking Glass", "This paradigm closely reflects the structure of systems 'in the real world', and it is therefore well suited to model complex systems with complex behaviours"[31] (contrast KISS principle).

しかしながら、Niklaus Wirth(Wirthの法則「ソフトウェアは、ハードウェアが高速化するより急速に低速化する」としてしられる格言で有名になった)は彼の論文の中で、「ガラスを見ることを通したよい考え」、「このパラダイムは【現実世界における】システムの構造を強く反映しているし、それゆえ複雑なふるまいをする複雑なシステムをモデル化することによく適している」と述べている。

Steve Yegge and others noted that natural languages lack the OOP approach of strictly prioritizing things (objects/nouns) before actions (methods/verbs).[32] This problem may cause OOP to suffer more convoluted solutions than procedural programming.[33]

Steve Yaggeや他の人は自然言語は動き(メソッド・動詞)の前にもの(オブジェクト・名詞)を厳格に優先させるオブジェクト指向のアプローチがかけていると指摘した。この問題があるためにオブジェクト指向プログラミングは手続き言語よりも込み入った解決策を受け入れなければならないのだろう。

4.5 OOP and control flow オブジェクト指向プログラミングと制御構造

OOP was developed to increase the reusability and maintainability of source code.[34] Transparent representation of the control flow had no priority and was meant to be handled by a compiler. With the increasing relevance of parallel hardware and multithreaded coding, developing transparent control flow becomes more important, something hard to achieve with OOP.[35][36][37][38]

ソースコードの再利用性と保守性を高めるためにオブジェクト指向プログラミングは開発された。制御構造の分かりやすい表現に優先するものはなくコンパイラによって管理されることを意味した。並列ハードウェアやマルチスレッドコーディングの妥当性が増加して、分かりやすい制御構造を開発することはより重要になり、OOPで達成することは難しい。

4.6 Responsibility- vs. data-driven design 責任とデータリブン

Responsibility-driven design defines classes in terms of a contract, that is, a class should be defined around a responsibility and the information that it shares. This is contrasted by Wirfs-Brock and Wilkerson with data-driven design, where classes are defined around the data-structures that must be held. The authors hold that responsibility-driven design is preferable.

責任駆動設計は契約の語句によってクラスを定義する。つまり、クラスは共有する責任と情報の周りで定義されるべきであるということだ。これはWirfs-BrockとWilkersonによるデータ駆動設計とは対照できだ。データ駆動設計とはクラスが保有しなければならないデータ構造の周りで定義されるというものだ。著者は責任駆動設計が望ましいと述べている。

4.7 SOLID and GRASP guidelines ガイドライン

SOLID is a mnemonic invented by Michael Feathers that stands for and advocates five programming practices:

SOLIDはMichael Feathersによって発明された5つのプログラミング原則を表し擁護する記憶術である

  • Single responsibility principle
  • Open/closed principle 開放/閉鎖原則
  • Liskov substitution principle リスコフの置換原則
  • Interface segregation principle
  • Dependency inversion principle 

GRASP (General Responsibility Assignment Software Patterns) is another set of guidelines advocated by Craig Larman.

 GRASPはCraig Larmanによる別のガイドライン集である。

 

  • この記事は、コンピュータサイエンスに関する技術および英語についての正確な知識のない翻訳者が個人的な勉強を目的として、ほぼ全てを意訳によって翻訳したために、極めて多くの誤訳が含まれていると想定される決して質が高いとは言えない文章を公開しているものです。ここに掲載されている情報を使用したことによる、読者の方または第三者に生じる損害および損失について、翻訳者は一切の責任を負いません。正しい情報が必要な場合は原文を参照してください。