翻訳 : Wikipedia:About - Wikipedia : 第3章、第3.1章

3 Contributing to WikipediaWikipediaに貢献する)

Main page: Wikipedia:Contributing to Wikipedia
See also: Wikipedia:Your first article and Guide to fixing vandalism

Anyone can contribute to Wikipedia by clicking on the Edit tab in an article. Before beginning to contribute, however, read some handy helping tools such as the tutorial and the policies and guidelines, as well as our welcome page. Creating an account offers many benefits. It is important to realize that in contributing to Wikipedia, users are expected to be civil and neutral, respecting all points of view, and only add verifiable and factual information rather than personal views and opinions. "The five pillars of Wikipedia" cover this approach and are recommended reading before editing. (Vandals are reported via the Administrator Notice Board and may be temporarily blocked from editing Wikipedia.)

記事にある編集タブをクリックすると誰でもWikipediaに貢献することができる。しかしながら、貢献する前には、ウェルカムページと一緒に、チュートリアルやポリシー、ガイドラインといった手助けになる簡単なツールをいくつか読むべきだ。アカウントを作ってもよいかもしれない。Wikipediaに貢献するときには、ユーザーは礼儀正しく中立的で個人的な見方や見解よりも信頼できる情報のみを追加することが期待されているということを理解することが重要である。「Wikipediaの5つの柱」ではこのアプローチがカバーされ、編集する前に読むことが推奨されている。(破壊者は管理者伝言板へ通報されて一時的にWikipediaの編集権を停止されるかもしれない。)

Most articles start as stubs, but after many contributions, they can become featured articles. Once the contributor has decided a topic of interest, they may want to request that the article be written (or they could research the issue and write it themselves). Wikipedia has on-going projects, focused on specific topic areas or tasks, which help coordinate editing.

ほとんどの記事はスタブから始まるが、多くの人が貢献することで、秀逸な記事になるかもしれない。貢献者が一度興味のあるトピックを決定すると、記事が書かれるようにリクエストするかもしれない(または、問題点を調査して自分で書くこともあるかもしれない)。Wikipediaには進行中のプロジェクトがあり、そこでは、共同編集を手助けする特定のトピック領域やタスクについて重点を置いている。

The ease of editing Wikipedia results in many people editing. That makes the updating of the encyclopedia very quick, almost as fast as news websites.

Wikipediaは簡単に編集できるので多くの人が編集している。これによって、百科事典の更新がニュースサイトとほぼ同じ速さで速やかに行われる。

3.1 Editing Wikipedia pages(Wikipediaのページを編集する)

Main pages: Help:Editing and Help:Wikitext

メインページはHelp:Editing and Help:Wikitextです。

Wikipedia uses a simple yet powerful page layout to allow editors to concentrate on adding material rather than page design. Page aspects facilitated include:

  • sections and subsections—which follow a page's lead section/introduction and (if specific conditions are met) a table of contents,
  • references,
  • images,
  • tables,
  • indentations
  • lists,
  • links,
  • ISBNs,
  • maths,
  • formatting elements and most world alphabets and common symbols, most of which have simple formats that are deliberately very easy and intuitive.

Wikipediaは単純だがパワフルなページレイアウトを用いることで編集者がページのレイアウトを気にせずにコンテンツを追加することに集中できるようにしている。ページによって、次のようなことが簡単になる。

  • セクションとサブセクション、(導入部、(もし特定の条件があえば)目次も作られる)
  • リンク、
  • 画像、
  • 表、
  • インデント、
  • 一覧記事、
  • ウィキリンク(ウィキペディアの記事同士を繋ぐ内部リンク)、
  • ISBN、
  • 数式
  • 要素のフォーマットやほとんどの世界のアルファベットや記号(とても簡単で直感的な方法なフォーマットを持っている)

Normally editing is chosen by clicking the Edit tab at the top of a Wikipedia page (or on a section-edit link). This will take you to a new page with a text box containing the editable text of the page you were viewing. In this box, you can type in the text that you want to add, using wiki markup to format the text and add other elements like images and tables. You should then press the Show preview button to review your contributions for any errors. When you have finished editing, you should write a short edit summary in the small field below the edit-box describing your changes before you press the Publish changes button. This will help others to understand the intention of your edit. To avoid accidentally leaving edit summaries blank, you can select "Prompt me when entering a blank edit summary" on the Edit tab of your personal preferences.

通常、編集はWikipediaのページのトップにある編集タブ(かセクション編集リンク)をクリックすることで行える。そうすると、表示しているページの編集可能なテキストが表示されているテキストボックスのある新しいページが表示される。このテキストボックスの中で、テキストの書式の編集や画像や表といった他のものを追加するためのウィキマークアップを使って、追加したいテキストをタイプすることができる。それから、プレビューボタンを押して、作業内容にエラーがないかプレビューをする。編集が終了すると、変更の公開ボタンを押す前に、編集ボックスの下に表示されているフィールドに、変更について説明をするための編集の要約を記入する。これは、他の人があなたの編集意図を理解するためのものだ。間違って編集の要約を空白のままにすることがないように、個人設定の編集タブから「要約が未記入だと注意する」を選ぶことができる。

Page editing is accessed through tabs that are found along the top edge of the page. These are:

  • Article. Shows the main Wikipedia article.
  • Talk. Shows a user discussion about the article's topic and possible revisions, controversies, etc.
  • Edit. This tab allows users to edit the article. Depending on the page’s susceptibility to vandalism, according to its visibility or the degree of controversy surrounding the topic, this tab may not be shown for all users. (For example, any user who is not an administrator will not be able to edit the Main Page.)
  • View history. This tab allows readers to view the editors of the article and the changes that have been made.
  • Star. ("Watch") If you are logged into your account, clicking on the star icon will cause any changes made to the article to be displayed on the watchlist. (Note: when this icon is clicked, it changes to a filled-in star.)

Wikipedia has robust version and reversion controls. This means that poor-quality edits or vandalism can quickly and easily be reversed or brought up to an appropriate standard by any other editor, so inexperienced editors cannot accidentally do permanent harm if they make a mistake in their editing. As there are many more editors intent on improving articles than not, error-ridden articles are usually corrected promptly.

ページの編集は、ページのトップのタブから行える。そこには以下のものがある。

  • 記事。Wikipediaのメイン記事を表示する。
  • トーク。記事のトピックや、場合によっては、改訂や論争などについての議論を表示する。
  • 編集。記事を編集できる。見られやすさやトピックを取り巻く環境の議論の度合いといったページの破壊されやすやによって、このタブはすべてのユーザに表示されないこともある。(例えば、管理者以外のユーザはメインページを編集できない。)
  • 履歴の閲覧。読者が記事の版と変更を見ることができる。
  • スター。ログインしていると、スターアイコンをクリックして、記事の変更をウォッチリストに表示する。(注:このアイコンをクリックすると、星の色が変わる)。

Wikipediaには頑健なバージョン管理システムがある。つまり、質の低い編集や破壊行為は速やかにそして簡単に差し戻されて他の編集者によって適切なスタンダードに合わせらる。だから、未熟な編集者の編集に間違いがあったときに、半永久的に害が残ってしまうことはないのである。多くの編集者が記事を改善しようとしない人よりも改善しようと思っているので、間違いがやたらに多い記事は通常適切に修正される。

 

 

翻訳 : Wikipedia:About - Wikipedia : 第2章

2 Making the best use of Wikipedia (Wikipedia の最も良い使い方)

2.1 Exploring Wikipedia ( Wikipedia の探索)

Main page: Portal:Contents
メインページはPortal:Contentsです

Many visitors come to Wikipedia to acquire knowledge, while others come to share knowledge. At this very instant, dozens of articles are being improved, and new articles are also being created. Changes can be viewed at the Recent changes page and a random page at random articles. Over 5,000 articles have been designated by the Wikipedia community as featured articles, exemplifying the best articles in the encyclopedia. Another 28,000 articles are designated as good articles. Some information on Wikipedia is organized into lists; the best of these are designated as featured lists. Wikipedia also has portals, which organize content around topic areas; our best portals are selected as featured portals. Articles can be found using the search box on the top-right side of the screen.

多くの人々が Wikipedia で知識を獲得したり共有したりしている。 たちどころに多くの記事が改善され新しい記事が作られる。変更は「最近の更新ページ」で見ることができ「ランダムに表示」でランダムのページを見ることができる。 5000を超える記事がウィキペディアのコミュニティによって秀逸な記事として選ばれている。ウィキペディアにおける最も好ましい記事を示すもの記事のことです。それに加えて28000の記事が良質な記事として選ばれている。ウィキペディアにおける情報の中にはリストとして整備されているものがある。これらの中で最も良いものは 秀逸な一覧として選ばれている。Wikipedia にはポータルがありトピックエリアに関するコンテンツがまとめられている。最も良いポータルは秀逸なポータルとして選ばれている。記事は Screen の上部右側にある検索ボックスを使って見つけることもできる。

Wikipedia is available in languages other than English. Wikipedia has more than two hundred and eighty languages, including a Simple English version, and related projects include a dictionary, quotations, books, manuals, and scientific reference sources, and a news service (see sister projects). All of these are maintained, updated, and managed by separate communities, and often include information and articles that can be hard to find through other common sources.

Wikipedia は英語以外の言語でも利用することができる。 Wikipedia は280以上の言語がありその中には単純な英語版もある。辞書や引用文、マニュアル、科学的な情報源、ニュースサービスといった関連プロジェクトもある。(姉妹プロジェクトを見てください)。これらすべては、それぞれのコミュニティによって整備され更新され管理されている。そしてしばしばの情報や記事には他のよく見られるソースではなかなか見つけることのできないものが含まれる。

2.2 Basic navigation in Wikipedia (Wikipedia の基本的な航海方法)

Main page: Help:Navigation
メインページはHelp:Navigationです.

Wikipedia articles are all linked, or cross-referenced. When highlighted text like this is seen, it means there is a link to some relevant article or Wikipedia page with further in-depth information. Holding the mouse over the link will often show to where the link will lead. There are other links towards the ends of most articles, for other articles of interest, relevant external websites and pages, reference material, and organized categories of knowledge which can be searched and traversed in a loose hierarchy for more information. Some articles may also have links to dictionary definitions, audio-book readings, quotations, the same article in other languages, and further information available on our sister projects. Additional links can be easily made if a relevant link is missing—this is one simple way to contribute.

Wikipedia の記事は全てリンクされたり相互に参照したりされている。このようにハイライトされたテキストが写っている時には 、そこに関連する記事やより深い情報を含んでいる Wikipedia のページへのリンクがあることを意味する。リンクの上にマウスを持っていくとしばしばリンクが差している先を表示する。リンクにはページの終わりの部分をさせているものや他の面白い記事をさせているもの、関連する外部の Web サイトやページをさしているもの、マテリアルをさしているもの、そして、整理されたナレッジカテゴリーを指しているものがある。記事の中には辞書の定義、 audiobook、 引用、多言語版の記事、姉妹プロジェクトで利用できるより詳しい情報などへのリンクを含んでいるものもある。リンク切れのあった場合には簡単にリンクを追加することができる。これは一つの簡単な貢献方法である。

2.3 Using Wikipedia as a research tool (研究の道具として Wikipedia を使う)

Main pages: Wikipedia:Researching with Wikipedia and Wikipedia:Citing Wikipedia
メインページはWikipedia:Researching with Wikipedia and Wikipedia:Citing Wikipediaです。

As wiki documents, articles are never considered complete and may be continually edited and improved. Over time, this generally results in an upward trend of quality and a growing consensus over a neutral representation of information.

Wiki のドキュメントにあるように記事は決して完全なものとは考えられず継続的に編集され改善されるだろう。 その結果、時間が経つと質が向上する傾向があり、情報の中立的な表現についてのコンセンサスが育まれる。

Users should be aware that not all articles are of encyclopedic quality from the start: they may contain false or debatable information. Indeed, many articles start their lives as displaying a single viewpoint; and, after a long process of discussion, debate, and argumentation, they gradually take on a neutral point of view reached through consensus. Others may, for a while, become caught up in a heavily unbalanced viewpoint which can take some time—months or years perhaps—to achieve a better balanced coverage of their subject. In part, this is because editors often contribute content in which they have a particular interest and do not attempt to make each article that they edit comprehensive. However, eventually, additional editors expand and contribute to articles and strive to achieve balance and comprehensive coverage. In addition, Wikipedia operates a number of internal resolution processes that can assist when editors disagree on content and approach. Usually, editors eventually reach a consensus on ways to improve the article.

利用者は全ての記事が初めから百科事典のような質にあるわけではないということに気づくべきである。 記事には嘘であったり論争の余地のある情報が含まれているかもしれない。実際に多くの記事は一つの観点からの描写から始まっている。その後徐々にコンセンサスを通じて中立的な視点に到達する。テーマについてよりバランスの取れた状態に到達するまでに数ヶ月や数年といったしばらくの間かなり偏ったものもあるかもしれない 。 その一因として編集者が、興味を持っている特定のコンテンツにのみ貢献して、練習している記事のそれぞれ包括的にはしようとしていないことが挙げられる。しかしながら、結局のところ、その他の編集者が記事を拡張し貢献することでバランスが取れ包括的になる。それに加えて、 Wikipedia は編集者がコンテンツやアプローチに反対する時に手助けすることのできる内部的な解決方法をいくつも運用している。通常は、編集者は何機器を改善させる方向でコンセンサスが取れる。

The ideal Wikipedia article is well written, balanced, neutral, and encyclopedic, containing comprehensive, notable, verifiable knowledge. An increasing number of articles reach this standard over time, and many already have. Our best articles are called Featured Articles (and display a small star in the upper right corner of the article), and our second best tier of articles are designated Good Articles. However, this is a process and can take months or years to be achieved through the concerted effort of editors. Some articles contain statements which have not yet been fully cited. Others will later be augmented with new sections. Some information will be considered by later contributors to be insufficiently founded and, therefore, may be removed.
理想的な Wikipedia の記事というのは包括的で価値のあり信頼のできる知識を含んでいてバランスが取れて中立で百科事典的によく書かれているものである。記事の数が増えるにしたがって時間をかけてこのスタンダードに到達する。多くの記事は実際にそうなっている。最も良い記事は秀逸な記事と呼ばれ(そして記事の上部右側に小さなスターが表示されている)、次に良い記事は良質な記事を呼ばれている。しかしこれは進行中でありエディターの努力を通じて到達するまでに数ヶ月ないしは数年かかり得る。完全には引用されていない部分を含んでいる記事も中にはある。その他にも新しいセクションに後から論争となるものもある。より後から参加する後継者によって、情報が不十分とみなされ、それゆえ、取り除かれるかもしれないということもあるだろう。

While the overall trend is toward improvement, it is important to use Wikipedia carefully if it is intended to be used as a research source, since individual articles will, by their nature, vary in quality and maturity. Guidelines and information pages are available to help users and researchers do this effectively, as is an article that summarizes third-party studies and assessments of the reliability of Wikipedia.

全体の傾向は改善に向かっているが、もし研究のソースとして用いるつもりがあるのであるならば、個々の記事はその本質によって、質や成熟の度合いが様々であるために注意深く Wikipedia を使うことが大切である。ガイドラインや情報ページはユーザーと研究者がこれを効率的に行う手助けとして使用することができる。

2.4 Wikipedia vs paper encyclopedias(Wikipedia vs 紙の百科事典)

Main page: Wikipedia is not paper (on Wikimedia Meta-Wiki).
メインページはWikipedia is not paper (on Wikimedia Meta-Wiki)です。

Wikipedia has advantages over traditional paper encyclopedias. First, is that it is not limited in space: it can keep growing as fast as people add to it.

Wikipediaは従来の紙の百科事典に対してアドバンテージを持っている。まず1つ目は、スペースに制約がないという点がある。人々が加えるのと同じくらい速く成長し続けることができる。

Second, there are no qualifications required to be able to author its articles. Therefore, it has a very large pool of contributors: the whole world. This, and the first advantage mentioned above, have enabled Wikipedia to become the most comprehensive encyclopedia on Earth.

2つ目は、記事を編集するために資格を必要としないことである。それゆえに、非常に多くの貢献者が存在する。それも全世界に。これと上記の1つ目の利点によってWikipediaは地球上で最も包括的な辞書となった。

Third, a paper encyclopedia remains static (stays the same) and falls out of date until the next edition. But Wikipedia is dynamic: you don't have to wait for the next edition to come out (there are no editions), as Wikipedia is published on-line as it is written on-line. Articles are made available as is, regardless of what stage of development they are in. You can update Wikipedia at any instant, and people do so continually around the clock, thereby helping each other to keep abreast of the most recent events everywhere and of the latest facts in every subject.

3つ目は、紙の百科事典は静的(同じであり続ける)であり、版が変わるまで古いままであるということだ。しかしWikipediaは動的だ。オンラインでかかれたものがオンラインで発行されるため、次の版が出版されるのを待つ必要はない。記事がどの開発段階にあるのかに関わらずに記事はそのまま利用可能である。Wikipediaを瞬時に更新することが可能であり、人々は常に継続的にそうしているので、お互い協力して、あらゆる場所で最近起こったイベントや、あらゆるテーマについて最新の事実に遅れないように保たれている。

Fourth, Wikipedia has a very low "publishing" cost for adding or expanding entries, as it is on-line, with no need to buy paper or ink for distribution. This has allowed it to be made available for free, making it more accessible to everyone. This has enabled Wikipedia to be independently developed and published in many different languages at the same time, by people literate in each language. Of the 290+ different language Wikipedias, 137 of them have 10,000 or more articles.

4つ目は、Wikipediaが、オンラインであり配布するために紙やインクがいらないので、項目を追加ための「出版」コストがとても低いということだ。これによって、無料で使用できて、すべての人がよりアクセスできるようになる。そして、Wikipediaが独立して発展して、それぞれの言語を読み書きできる人によって、同時に多くの言語で発行されることができるようになる。290以上の言語のWikipediaがあり、それらの137は10,000以上の記事がある。

Fifth, Wikipedia has a low environmental impact in some respects, since it never needs to be printed, although computers have their own environmental cost.

5つ目は、コンピュータにはそれぞれの環境的な負荷があるけれども、決して印刷される必要がないので、Wikipediaはいくつかの点において環境的な影響が小さいということだ。

Sixth, Wikipedia is extra-linear (more than linear). Instead of in-line explanations, Wikipedia incorporates hypertext in the form of wikilinks. Throughout its content is a robust network of links, providing another dimension of knowledge accessibility. The encyclopedia also has correlates to tables of contents and indexes, with each entry in them hyperlinked to an article on the topic specified.

6つ目は、Wikipediaは超線形であるということだ。線形の代わりに、Wikipediaは、wikilinksの形のハイパーテキストを組み込んでいる。コンテンツを通じて強固なリンクのネットワークが出来上がり、他の知識の事件へアクセスできるようになる。百科事典はコンテンツの表とインデックスにも関連していて、それぞれの項目は特定のトピックの記事へのリンクされている。

Seventh, each Wikipedia article provides an introduction summarizing the more extensive detail of its contents.

7つ目は、Wikipediaの各記事がコンテンツのより広範な詳細を要約するイントロダクションをもっているということだ。

Eighth, being open to anyone to edit, articles on Wikipedia are subject to additions that might be erroneous or written poorly, which in turn are subject to being corrected or rewritten. It is a community effort, with most people who are involved helping to improve the work, fixing problems they encounter along the way. See more about Wikipedia's strengths and weaknesses, below...

2.5 Strengths, weaknesses, and article quality in Wikipedia(Wikipediaにおける強み、弱み、記事の質)

Wikipedia's greatest strengths, weaknesses, and differences all arise because it is open to anyone, it has a large contributor base, and its articles are written by consensus, according to editorial guidelines and policies.

Wikipediaの新しい強みや弱み、記事がいいというのは全て誰に対しても開かれていて、非常に多くの貢献者がいて、ガイドラインやポリシーに従ってコンセンサスが得られた状態で記事が書かれているということに由来する。

  • Wikipedia is open to a large contributor base, drawing a large number of editors from diverse backgrounds. This allows Wikipedia to significantly reduce regional and cultural bias found in many other publications, and makes it very difficult for any person or group to censor and impose bias. A large, diverse editor base also provides access and breadth on subject matter that is otherwise inaccessible or little documented. A large number of editors contributing at any moment also means that Wikipedia can produce encyclopedic articles and resources covering newsworthy events within hours or days of their occurrence. It also means that like any publication, Wikipedia may reflect the cultural, age, socio-economic, and other biases of its contributors. There is no systematic process to make sure that "obviously important" topics are written about, so Wikipedia may contain unexpected oversights and omissions. While most articles may be altered by anyone, in practice editing will be performed by a certain demographic (younger rather than older, male rather than female, rich enough to afford a computer rather than poor, et cetera) and may, therefore, show some bias. Some topics may not be covered well, while others may be covered in great depth.
    Wikipedia はとても多くの貢献者に対して開かれていて、様々なバックグラウンドから編集者を引き込んでいる。そのため 、Wikipedia では、他の多くの出版物に見られるような地域的なまたは文化的な偏りがかなり減らされていて、どんな人や団体に対しても検閲をすることや偏りを押し付けることが難しくなっている。とても多くの多様な編集者がいるということで、手に入れることができなかったり言及されることが少ないテーマに対して手に入りやすくしたり広がりを持たせたりしている。いつでもとても沢山の編集者が貢献しているということは、発生してから数時間や数日以内の報道価値のあるイベントをカバーしている百科事典的な記事や条件をWikipediaは生み出すことができるということを意味している。それはまた他の出版物のように、 Wikipedia は文化や時代、社会の経済、貢献者の偏見を反映するかもしれないということを意味する。明らかに重要なことが書かれているということを確認するための体系的なプロセスは存在しないのでウィキペディアには想定しない見逃しがあるかもしれない。ほとんどの記事は誰かによって編集されている一方で、実際には、特定の人口統計学的(歳をとっている人よりもむしろ若い人、女性よりも男性、貧しい人よりもコンピューターを変えるだけの余裕のある人、などなど)に行われているだろう。そして、それ故に、いくらかの偏りが見られるかもしれない。トップの中にはよくカバーされていないものがあるかもしれない。一方で、トピックによってはとても深くカバーされているものもあるかもしれない。
  • Allowing anyone to edit Wikipedia means that it is more easily vandalized or susceptible to unchecked information, which requires removal. See Wikipedia:Administrator intervention against vandalism. While blatant vandalism is usually easily spotted and rapidly corrected, Wikipedia is more subject to subtle viewpoint promotion than a typical reference work. However, bias that would be unchallenged in a traditional reference work is likely to be ultimately challenged or considered on Wikipedia. While Wikipedia articles generally attain a good standard after editing, it is important to note that fledgling articles and those monitored less well may be susceptible to vandalism and insertion of false information. Wikipedia's radical openness also means that any given article may be, at any given moment, in a bad state, such as in the middle of a large edit, or a controversial rewrite. Many contributors do not yet comply fully with key policies, or may add information without citable sources. Wikipedia's open approach tremendously increases the chances that any particular factual error or misleading statement will be relatively promptly corrected. Numerous editors at any given time are monitoring recent changes and edits to articles on their watchlists.
    誰もが Wikipedia を編集できるということは、故意に破壊されやすくなったり、取り除かれる必要のあるゲップのされていない情報に影響を受けやすくなるということを意味します。Wikipedia:Administrator intervention against vandalismをご覧ください。明らかな破壊行為は通常は簡単に停止させることができ速やかに修正されるが、 Wikipedia は典型的な引用よりも微妙な観点に影響を受けやすい。しかしながら伝統的な参考文献における問題視されていない偏見は究極的には変更されたり Wikipedia の上でよく考えられたりする可能性がある。 の上でよく考えられたりする可能性があるWikipedia の記事は徐々に練習 の記事は徐々に編集後に良い標準を獲得する一方、出来たばかりの生地屋あまり機能されていない記事は破壊行為に影響を受けやすく、間違った情報を挿入されるかもしれないということを注意することは重要である。 Wikipediaの徹底的に開放されている特徴は、編集の途上にあったり、議論の必要な書き直しといったような悪い状態に、書かれた瞬間に、記事がなってしまうかもしれないことを意味する。多くの貢献者はキーとなるポリシーに完全には従っておらず、引用可能なソースなしに情報を追加するかもしれない。 ウィキペディアの開放的な手法はどんな事実に関する間違いや誤りのある記事を比較的適切に修正するだろうという機会を劇的に増加させる。多くの編集者が記事の書かれた時にウォッチリスト上にある更新履歴を監視し記事を編集する。

  • Wikipedia is written by open and transparent consensus—an approach that has its pros and cons. Censorship or imposing "official" points of view is extremely difficult to achieve and usually fails after a time. Eventually for most articles, all notable views become fairly described and a neutral point of view reached. In reality, the process of reaching consensus may be long and drawn-out, with articles fluid or changeable for a long time while they find their "neutral approach" that all sides can agree on. Reaching neutrality is occasionally made harder by extreme-viewpoint contributors. Wikipedia operates a full editorial dispute resolution process, one that allows time for discussion and resolution in depth, but one that also permits disagreements to last for months before poor-quality or biased edits are removed. A common conclusion is that Wikipedia is a valuable resource and provides a good reference point on its subjects.
    Wikipedia は開放性と透明性を備えたコンセンサスによって書かれている。この手法にはメリットとデメリットがある。検閲や公式の見方を矯正することは、成し遂げることを極度に困難にし、結局失敗に終わることが多い。結局は、ほとんどの記事において、すべての注目に値する見方は公平に記述され、そして、中立的な見方に到達する。実際にコンセンサスに到達する過程は長く、中には、すべての側面から同意することができる中立的な手法を見つけるまで、長い間、流動的であったり、変わりやすい記事が含まれる。中立的なところまで到達するということは、時々極度の見方を保つ貢献者によって難しくなるかもしれない。 Wikipedia は全ての編集上の論じ合うことのできる完全な解決手法を運営していて、その中には深く議論し解決することができるための時間を用意しているものもあるが、一方では、質の低かったり偏っている編集が取り除かれるまでに数ヶ月かかる意見の相違を許可しているものもある。共通の結論は、ウィキペディアは価値のある情報源であり、テーマについての良い参照点を提供しているということだ。
  • That said, articles and subject areas sometimes suffer from significant omissions, and while misinformation and vandalism are usually corrected quickly, this does not always happen. (See for example this incident in which a person inserted a fake biography linking a prominent journalist to the Kennedy assassinations and Soviet Russia as a joke on a co-worker which went undetected for four months, saying afterwards he "didn’t know Wikipedia was used as a serious reference tool".)
    そうは言っても、記事やテーマ領域は時々、ひどい怠慢によって苦しむことがあり、誤報や破壊行為は通常は速やかに修正されるが、これは常に起こるとは限らない。(例えば、同僚に向けて作られた、4ヶ月の間、誰も気付かなかった、ケネディ暗殺やソビエトと有名なジャーナリストをリンクさせた偽の伝記が挿入されたインシデントをご覧ください。いわく、「Wikipediaが真面目な情報源として使われていたとは知らなかった」)
  • Wikipedia is written largely by amateurs. Those with expert credentials are given no additional weight. Wikipedia is also not subject to any peer review for scientific, medical or engineering articles. One advantage to having amateurs write in Wikipedia is that they have more free time on their hands so that they can make rapid changes in response to current events. The wider the general public interest in a topic, the more likely it is to attract contributions from non-specialists.
    Wikipediaは大部分はアマチュアによって書かれている。専門家の資格を持つ者には、それ以上の重要性はない。ウィキペディアはまた、科学的、医学的または工学的記事に関するいかなる査読の対象にもならない。アマチュアウィキペディアで書いてもらうことの1つの利点は、彼らに自由に取り組んでもらうことで、新しい出来事にすぐに対応してもらえるようにすることだ。 あるトピックに対する一般の公益が広くなればなるほど、非専門家からの貢献を引き付ける可能性が高くなる。

The MediaWiki software that runs Wikipedia retains a history of all edits and changes, thus information added to Wikipedia never "vanishes" irreversibly. Discussion pages are an important resource on contentious topics. Therefore, serious researchers can often find a wide range of vigorously or thoughtfully advocated viewpoints not present in the consensus article. As with any source, information should be checked. A 2005 editorial by a BBC technology writer comments that these debates are probably symptomatic of cultural changes that are happening across all sources of information (including search engines and the media), and may lead to "a better sense of how to evaluate information sources".[3]

ウィキペディアを実行するMediaWikiソフトウェアはすべての編集と変更の履歴を保持しているので、ウィキペディアに追加された情報が不可逆的に「消える」ことはありえない。 ディスカッションページは、議論の的になるトピックに関する重要な資料である。 そのため、真面目な研究者は、コンセンサス記事にはない、積極的または思慮深く主張された幅広い視点を見つけることができる。 他の情報源と同様に、情報をチェックする必要がある。 2005年のBBC技術作家は、これらの議論はおそらくすべての情報源(検索エンジンやメディアを含む)で起こっている文化的変化の兆候であり、「情報源の評価方法のより良い意識」につながるかもしれないとコメントしている 。

2.6 Disclaimers(免責事項)

Main page: Wikipedia:General disclaimer

メインページはWikipedia:General disclaimerです。

Wikipedia disclaimers apply to all pages on Wikipedia. However, the consensus in Wikipedia is to put all disclaimers only as links and at the end of each article. Proposals to have a warning box at the beginning have been rejected. Some do not like the way it looks or that it calls attention to possible errors in Wikipedia.

ウィキペディアの免責事項は、ウィキペディアのすべてのページに適用される。 しかし、ウィキペディアでの合意は、すべての免責事項を、リンクとして各記事の最後に置くことである。 最初に警告ボックスを表示するという提案は拒否された。 見た目やウィキペディアで起こりうるエラーに注意を向けていることを好まない人もいるからである。

Wikipedia, in common with many websites, has a disclaimer that, at times, has led to commentators citing these in order to support a view that Wikipedia is unreliable. A selection of similar disclaimers from places which are often regarded as reliable (including sources such as Encyclopædia Britannica, Associated Press, and the Oxford English Dictionary) can be read and compared at Wikipedia:Non-Wikipedia disclaimers.

ウィキペディアは、多くのウェブサイトと共通して、時には、ウィキペディアが信頼できないという見解を支持するためにこれらを引用しているコメンテーターを導くかもしれない免責事項を持っている。 信頼できると見なされることが多い場所(Encyclopaedia Britannica、Associated Press、Oxford English Dictionaryなどの情報源を含む)からの同様の免責事項の一覧は、 Wikipedia : Non-Wikipedia disclaimersで読むことができる。 

 

 

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

翻訳 : Wikipedia:About - Wikipedia : 第1章まで

注:未完です。

ウィキペディアについてのすべての概要については、Outline of Wikipedia (ウィキペディアの概要)をご覧ください。"Wikipedia:Wikipedia"はここにリダイレクトされます。他の場合は、Wikipedia:Wikipedia (disambiguation(曖昧性除去))をご覧ください。

This is a general introduction for visitors to Wikipedia. The project also has an encyclopedia article about itself, Wikipedia, and an introduction for aspiring contributors. For information on how to donate to the organization that runs Wikipedia, see Ways to Give.

これはウィキペディアの訪問者への一般的なイントロダクションです。プロジェクトは百科事典の記事、ウィキペディア、野心のある貢献者のためのイントロダクションを含みます。ウィキペディアを運営する組織に協力するための方法についての情報に関してはWays to Giveをご覧下さい。

Wikipedia (/ˌwɪkɪˈpiːdiə/ (About this soundlisten), /ˌwɪkiˈpiːdiə/ (About this soundlisten) WIK-ih-PEE-dee-ə) is a multilingual, web-based, free-content encyclopedia project supported by the Wikimedia Foundation and based on a model of openly editable content. The name "Wikipedia" is a portmanteau of the words wiki (a technology for creating collaborative websites, from the Hawaiian word wiki, meaning "quick") and encyclopedia. Wikipedia's articles provide links designed to guide the user to related pages with additional information.

ウィキペディアマルチリンガル、ウェブベース、フリーコンテンツの百科事典プロジェクトであり、ウィキペディア財団によって支えられ、開かれた編集可能なコンテンツのモデルになっている。「ウィキペディア」という名前はwikiハワイ語でquickを意味する語であるwikiから取られた、共同でウェブサイトを作成するための技術)とencyclopediaの混成語である。ウィキペディアの記事は追加の情報を持つ関連するページへユーザをガイドするためのリンクを提供する。

Wikipedia is written collaboratively by largely anonymous volunteers who write without pay. Anyone with Internet access can write and make changes to Wikipedia articles, except in limited cases where editing is restricted to prevent disruption or vandalism. Users can contribute anonymously, under a pseudonym, or, if they choose to, with their real identity. The fundamental principles by which Wikipedia operates are the five pillars. The Wikipedia community has developed many policies and guidelines to improve the encyclopedia; however, it is not a formal requirement to be familiar with them before contributing.

ウィキペディアは代金をもらわずに書いている多くの匿名のボランティアによって共同で書かれている。インターネットにアクセスできる誰もが、混乱や破壊行為が起こらないように編集が制限された場所を除いて、ウィキペディアの記事を書いたり編集したりすることができる。ユーザーは仮名を使って匿名で、または、もし選ぶのであれば、本当のアイデンティティを使って貢献する事ができる。ウィキペディアが管理している最も基本的は原理は5つの柱である。ウィキペディアコミュニティは多くのポリシーとガイドラインを発展させて百科事典を改良している。しかしながら、貢献をする前にそれらをよく知っていることは公式の要求ではない。

Since its creation in 2001, Wikipedia has grown rapidly into one of the largest reference websites, attracting 374 million unique visitors monthly as of September 2015.[1] There are about 72,000 active contributors working on more than 48,000,000 articles in 302 languages. As of today, there are 5,783,651 articles in English. Every day, hundreds of thousands of visitors from around the world collectively make tens of thousands of edits and create thousands of new articles to augment the knowledge held by the Wikipedia encyclopedia. (See the statistics page for more information.) People of all ages, cultures and backgrounds can add or edit article prose, references, images and other media here. What is contributed is more important than the expertise or qualifications of the contributor. What will remain depends upon whether the content is free of copyright restrictions and contentious material about living people, and whether it fits within Wikipedia's policies, including being verifiable against a published reliable source, thereby excluding editors' opinions and beliefs and unreviewed research. Contributions cannot damage Wikipedia because the software allows easy reversal of mistakes and many experienced editors are watching to help ensure that edits are cumulative improvements. Begin by simply clicking the Edit link at the top of any editable page!

2001年に作成されてから、ウィキペディアは最も参照される大きなウェブサイトの一つに急速に成長して、2015年9月現在、月間3億7400万人が利用している。302の言語で48,000,000以上の記事を72,000のアクティブな貢献者が作成している。今日では、英語の記事は5,783,660ある。毎日、世界中から多くの訪問者が多くの編集を行い、多くの新しい記事を作成して、ウィキペディアが保持している知識を増加させている。(より多くの情報を得るためには統計ページをご覧ください)すべての時代、文化、バックグラウンドの人が記事の本文、参考文献、画像やその他のメディアを追加したり編集できる。貢献されたものは貢献者の専門知識や質よりも重要である。 コンテンツが著作権の制限がないことや生存する人についての議論のあるものであるかどうか、出版された信頼できる情報源に対して検証可能性を含んでいるか、編集者の意見や信念や独自研究を含んでいないかといったウィキペディアのポリシーに適合しているかどうかといっそれがウィキペディアのポリシーに適合しているかどうかということである。貢献者はウィキペディアを傷つけることができない。というのは、簡単に失敗を逆戻りさせることができるソフトウェアを使用していて、また、多くの経験豊富な編集者が、徐々に改善される方向へ向かう編集であるかどうかを観察しているからである。編集可能なページをトップにある編集リンクをクリックするだけです!!

Wikipedia is a live collaboration differing from paper-based reference sources in important ways. Unlike printed encyclopedias, Wikipedia is continually created and updated, with articles on historic events appearing within minutes, rather than months or years. Because everybody can help improve it, Wikipedia has become more comprehensive than any other encyclopedia. In addition to quantity, its contributors work on improving quality as well. Wikipedia is a work-in-progress, with articles in various stages of completion. As articles develop, they tend to become more comprehensive and balanced. Quality also improves over time as misinformation and other errors are removed or repaired. However, because anyone can click "edit" at any time and add stuff in, any article may contain undetected misinformation, errors, or vandalism. Awareness of this helps the reader to obtain valid information, avoid recently added misinformation (see Wikipedia:Researching with Wikipedia), and fix the article.

ウィキペディアは活発な共同作業であり、紙ベースの情報源とは重要な点で異なる。印刷された百科事典とは異なり、ウィキペディアは継続に作成・更新される。歴史的なイベントが発生してから月や年ではなく数分間で記事が生まれる。誰もが改善の手助けをできるので、ウィキペディアは他の百科事典よりも包括的になる。貢献者は量に加えて質の改善にも取り組んでいる。ウィキペディアは進行中であり、様々な完成度の記事が含まれる。記事の発展に伴って、より包括的でバランスの取れたものになる傾向がある。誤報やほかの間違いが取り除かれたり修復されたりして時間の経過とともに質もまた改善する。しかしながら、誰もがいつでも「編集」をクッリクして内容を追加できるので、すべての記事において検出されていない誤りが含まれる可能性がある。これに気づくことは読者が正しい情報を得て、最近加えられた誤りを避け(Wikipedia:Researching with Wikipediaもご覧ください)、記事を修正することを助ける。

See also: Wikipedia:FAQ and Wikipedia:Citing Wikipedia

 Wikipedia:FAQ と Wikipedia:Citing Wikipediaもご覧ください

 

1 About Wikipedia ウィキペディアについて

1.1 Wikipedia history 歴史

 
The English edition of Wikipedia has grown to 5,783,651 articles, equivalent to over 2,000 print volumes of the Encyclopædia Britannica. Including all language editions, Wikipedia has over 38 million articles, equivalent to over 15,000 print volumes. 
ウィキペディア英語版は5,783,651記事まで成長した。これはブリタニカ百科事典の2000巻以上に匹敵する。すべての言語を含めると、3億8000万記事に到達し、これは15000巻以上に匹敵する。

Wikipedia was founded as an offshoot of Nupedia, a now-abandoned project to produce a free encyclopedia, begun by the online media company Bomis. Nupedia had an elaborate system of peer review and required highly qualified contributors, but the writing of articles was slow. During 2000, Jimmy Wales (founder of Nupedia and co-founder of Bomis), and Larry Sanger, whom Wales had employed to work on the encyclopedia project, discussed ways of supplementing Nupedia with a more open, complementary project. Multiple sources suggested that a wiki might allow members of the public to contribute material, and Nupedia's first wiki went online on January 10, 2001.

ウィキペディアは今では無料の百科事典を制作するプロジェクトが破棄されたヌーペディアの派生として設立され、オンラインメディアカンパニーのBomisによって始められた。ヌーペディアはピア・レビューの優れたシステムを有しており質の良い貢献者を獲得していたが、記事の書かれる速度は遅かった。2000年に、Jimmy Walse(ヌーペディアの出資者でありBomisの共同出資者)とLarry Sangerはヌーペディアをよりオープンする方法と補足的なプロジェクトについて議論を行った。多くの情報源がwikiによってパブリックメンバーがコンテンツに貢献できることを示し、ヌーペディアの最初のウィキは2001年1月10日にオンラインに公開された。

There was considerable resistance on the part of Nupedia's editors and reviewers to the idea of associating Nupedia with a website in the wiki format, so the new project was given the name "Wikipedia" and launched on its own domain, wikipedia.com, on January 15 (now called "Wikipedia Day" by some users). The bandwidth and server (in San Diego) were donated by Wales. Other current and past Bomis employees who have worked on the project include Tim Shell, one of the cofounders of Bomis and its current CEO, and programmer Jason Richey.

ヌーペディアをウィキ形式のWebサイトに関連付けるという考えに対して、ヌーペディアの編集者および査読者にはかなりの抵抗があったので、新しいプロジェクトは "Wikipedia"という名前を付けられ、独自のドメインwikipedia.comで1月 15日(現在一部のユーザーは "Wikipedia Day"と呼んでいる)に立ち上げられた。 帯域幅とサーバー(サンディエゴにある)はWalesから寄付されました。 このプロジェクトに携わった他の現在および過去のBomis従業員には、Bomisの共同創設者の1人であり現在のCEOであるTim Shell、およびプログラマーのJason Richeyがいる。

In May 2001, a large number of non-English Wikipedias were launched—in Catalan, Chinese, Dutch, Esperanto, French, German, Hebrew, Italian, Japanese, Portuguese, Russian, Spanish, and Swedish. These were soon joined by Arabic and Hungarian. In September,[2] Polish was added, and further commitment to the multilingual provision of Wikipedia was made. At the end of the year, Afrikaans, Norwegian, and Serbo-Croatian versions were announced.

2001年5月には、多くの英語ではないウィキペディアが始まった。ーカタロニア語、中国語、オランダ語エスペラント語、フランス語、ドイツ語、ヘブライ語、イタリア語、日本語、ポルトガル語、ロシア語、スペイン語、およびスウェーデン語である。それからまもなくアラビア語ハンガリー語が追加された。9月には、ポーランド語も加わり、多言語対応のウィキペディアをより多く追加するといった約束がなされた。年の終わりには、アフリカーンス語ノルウェー語、およびセルボクロアチア語バージョンが発表された。

The domain was eventually changed to the present wikipedia.org when the not-for-profit Wikimedia Foundation was launched, in 2003, as its new parent organization, with the ".org" top-level domain denoting its non-commercial nature. Today, there are Wikipedias in over 250 languages.

非営利的なウィキペディア財団が立ち上がった2003年にはドメインは徐々に現在のwikipedia.orgへと移った。トップレベルドメイン.orgが非営利的な性質を示すからである。今日では250を超える言語のウィキペディアがある。

1.2 Wikipedia contributors 貢献者


Anyone with Web access can edit Wikipedia, and this openness encourages inclusion of a tremendous amount of content. About 70,000 editors—from expert scholars to casual readers—regularly edit Wikipedia, and these experienced editors often help to create a consistent style throughout the encyclopedia, following our Manual of Style.

ウェブにアクセスできる誰もがウィキペディアを編集することができる。この開かれていることが多くのコンテンツを持っているという状況を作っている。約70,000の編集者ー専門的な学者からカジュアルな読者までーが定期で気にウィキペディアを編集して、これらの経験豊富な編集者が百科事典を通じて以下の我々のスタイルマニュアルに沿って、一貫したスタイルを作り出す手助けをしている。

Several mechanisms are in place to help Wikipedia members carry out the important work of crafting a high-quality resource while maintaining civility. Editors are able to watch pages and technically skilled persons can write editing programs to keep track of or rectify bad edits. Where there are disagreements on how to display facts, editors often work together to compile an article that fairly represents current expert opinion on the subject. Aspiring authors may wish to read the information on Contributing to Wikipedia before contributing to the project.

ウィキペディアのメンバーが丁寧さを維持しながらクオリティーの高いリソースを制作するという重要な仕事を遂行する手助けをするメカニズムがある。編集者はページを見ることができ、専門家が悪い編集を修正したり追跡する事ができる。事実をどのように表現するかといったことについての意見の相違があるときには、編集者はテーマに関する現在の専門的な意見を表す記事を共同で編集する。野心のある著者はプロジェクトに貢献する前にウィキペディアの貢献に関する情報を読もうとするかもしれない。

Although the Wikimedia Foundation owns the site, it is largely uninvolved in writing and daily operations.

ウィキペディア財団がサイト所有しているけれども、執筆や日々の操作の多くには関与していない。

1.3 Trademarks and copyrights 商標と著作権

 

"Wikipedia" is a registered trademark of the not-for-profit Wikimedia Foundation, which has created a family of free-content projects that are built by user contributions.

ウィキペディア」はウィキペディア財団の非営利的な商標として登録されている。ユーザの貢献によって作成されるフリーコンテンツプロジェクトの一種として作られた。

Most of Wikipedia's text and many of its images are dual-licensed under the Creative Commons Attribution-Sharealike 3.0 Unported License (CC-BY-SA) and the GNU Free Documentation License (GFDL) (unversioned, with no invariant sections, front-cover texts, or back-cover texts). Some text has been imported only under CC-BY-SA and CC-BY-SA-compatible license and cannot be reused under GFDL; such text is identified either on the page footer, in the page history or on the discussion page of the article that utilizes the text. Every image has a description page that indicates the license under which it is released or, if it is non-free, the rationale under which it is used.

ウィキペディアのテキストの大部分とイメージの多くはクリエイティブ・コモンズ 表示-継承 3.0 非移植(CC-BY-SA)とGNU フリー文書利用許諾契約書(GFDL)によってライセンスされている。CC-BY-SAやCC-BY-SA互換ライセンスのみでGFDLとして再利用できないテキストも存在する。そのようなテキストは、ページのフッター、ページの履歴、テキストを使っている記事のディスカッションページで見分けることができる。すべての画像にはどのライセンスが使われているか、非営利であればどうしてそうなのか、といったことを示す解説ページが用意されている。

Contributions remain the property of their creators, while the CC-BY-SA and GFDL licenses ensure the content is freely distributable and reproducible. (See content disclaimer for more information.)

貢献者は、CC-BY-SAやGFDLによってコンテンツが無料配布可能や複製可能であることを保証されている一方で、制作した所有権を保持し続ける。(詳しくはcontent disclaimer をご覧ください。)

1.4 Credits クレジット

 Text on Wikipedia is a collaborative work, and the efforts of individual contributors to a page are recorded in that page's history, which is publicly viewable. Information on the authorship of images and other media, such as sound files, can be found by clicking on the image itself or the nearby information icon to display the file page, which includes the author and source, where appropriate, along with other information.

ウィキペディアのテキストは共同の 制作品であり、個々のの貢献者のページに対する努力はパプリックに公開されたそれぞれのページの履歴に記録される。画像や音声ファイルなどの他のメディアの著者に関する情報は画像やその近くにあるファイルページを表示するアイコンをクリックすることで見ることができる。著者や情報源、その他の情報が含まれる。

 

 

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

翻訳 導入部 : Bicycle - Wikipedia

A bicycle, also called a cycle or bike, is a human-powered, pedal-driven, single-track vehicle, having two wheels attached to a frame, one behind the other. A bicycle rider is called a cyclist, or bicyclist.

自転車は、人力によるペダル駆動で、二つのタイヤが、片方がもう片方の後ろに取り付けられている単車である。自転車に乗る人をサイクリストという。

Bicycles were introduced in the late 19th century in Europe, and by the early 21st century, more than 1 billion have been produced worldwide.[1][2][3] These numbers far exceed the number of cars, both in total and ranked by the number of individual models produced.[4][5][6] They are the principal means of transportation in many regions. They also provide a popular form of recreation, and have been adapted for use as children's toys, general fitness, military and police applications, courier services, bicycle racing and bicycle stunts.

自転車は19世紀終わりのヨーロッパで広がり、21世紀の初頭には、世界中で1億台以上が生産された。この数は、合計台数でも個々のモデルの生産数によるランクでも、車の数をはるかに上回っている。自転車は多くの地域で主要な移動手段である。また、自転車はレクリエーションとしても人気があり、こどものおもちゃやフィットネス、軍事、警察、ガイド、自転車競技、スタントとしても使われている。

The basic shape and configuration of a typical upright or "safety bicycle", has changed little since the first chain-driven model was developed around 1885.[7][8][9] But many details have been improved, especially since the advent of modern materials and computer-aided design. These have allowed for a proliferation of specialized designs for many types of cycling.

代表的な「直立自転車」の基本的な形は1885年ごろに最初のチェーン駆動モデルが開発されてから徐々に変化している。細部の多くは近代の材料やCADができるようになってから改善している。これらによって様々な種類のサイクルに特化したデザインが急速に発展した。

The bicycle's invention has had an enormous effect on society, both in terms of culture and of advancing modern industrial methods. Several components that eventually played a key role in the development of the automobile were initially invented for use in the bicycle, including ball bearings, pneumatic tires, chain-driven sprockets and tension-spoked wheels.[10]

 自転車の発明は、文化面や近代産業の発展において、社会に大きな影響を与えた。自動車の発展に大きな役割を果たしたいくつかの要素ははじめは自転車のために開発された。ボールベアリング、空気タイヤ、チェーン駆動のスプロケット、スポークテンションホイールなどである。

 

 

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

翻訳 第6, 7章 : Software engineering - Wikipedia

6 Related fields 関連分野

Software engineering is a direct sub-field of engineering and has an overlap with computer science and management science[citation needed]. It is also considered a part of overall systems engineering.

ソフトウェア工学は工学の直接的な下位の分野でコンピュータサイエンスと経営科学と部分的に一致する。システム工学の一部を共有するとも考えられる。

6.1 Computer Science コンピュータサイエンス

In general, software engineering focuses more on techniques for the application of software development in industry,[43][44] while computer science focuses more on algorithms and theory.[45]

一般的に、ソフトウェア工学では産業へソフトウェア開発を応用するための技術に重点を置いている。一方でコンピュータサイエンスアルゴリズムと理論と重点を置いている。

7 Controversy 論争

7.1 Criticism 批判

Software engineering sees its practitioners as individuals who follow well-defined engineering approaches to problem-solving. These approaches are specified in various software engineering books and research papers, always with the connotations of predictability, precision, mitigated risk and professionalism. This perspective has led to calls for licensing, certification and codified bodies of knowledge as mechanisms for spreading the engineering knowledge and maturing the field.

ソフトウェア工学は上手に定義された問題解決への工学的なアプローチを追求した個々の集まりとして見られる。これらの方法は様々なソフトウェア工学の本、研究論文で明記され、常に予測性、正確さ、リスクの軽減、専門家の技術を含んでいる。この観点からエンジニアリングの知識を広めて分野を成熟させるメカニズムとしてのライセンス、証明書、知識体系を必要とする。

Software craftsmanship has been proposed by a body of software developers as an alternative that emphasizes the coding skills and accountability of the software developers themselves without professionalism or any prescribed curriculum leading to ad-hoc problem-solving (craftmanship) without engineering (lack of predictability, precision, missing risk mitigation, methods are informal and poorly defined). The Software Craftsmanship Manifesto extends the Agile Software Manifesto[46] and draws a metaphor between modern software development and the apprenticeship model of medieval Europe.

ソフトウェアクラフトマンシップは専門家の技術やエンジニアリングなしで(予測性、正確性の欠落、リスク軽減の失敗、非公式で十分に定義されていないメソッド)アドホックな問題解決(クラフトマンシップ)を導く定められたカリキュラムもなくコーディングスキルとソフトウェア開発者の責任性を強調する代替案としてソフトウェア開発者の大勢によって提案された。ソフトウェアクラフトマンシップアジャイルを拡張して現代的なソフトウェア開発と中世ヨーロッパの見習いモデルの間のメタファーを描いた。

Software engineering extends engineering and draws on the engineering model, i.e. engineering process, engineering project management, engineering requirements, engineering design, engineering construction, and engineering validation. The concept is so new that it is rarely understood, and it is widely misinterpreted, including in software engineering textbooks, papers, and among the communities of programmers and crafters.

ソフトウェア工学は工学を拡張して工学モデル、つまり、エンジニアリングプロセス、エンジニアリングプロジェクトマネジメント、エンジニアリング構築、エンジニアリングの確認にもとづいて作られている。新しい概念であるため滅多に理解されず、ソフトウェア工学の教科書、論文、さらにはプログラマーのコミュニティーのなかなど、広く誤解されている。

One of the core issues in software engineering is that its approaches are not empirical enough because a real-world validation of approaches is usually absent, or very limited and hence software engineering is often misinterpreted as feasible only in a "theoretical environment."

ソフトウェア工学の中心的な問題の一つはそのアプローチが現実世界で正当性があるのかは通常はぼんやりとしているか、とても限られていて、それゆえにソフトウェア工学はしばしば「理論的な環境」でのみ適すものとして誤解されるので経験的で十分ではない。

Edsger Dijkstra, the founder of many of the concepts used within software development today, refuted the idea of "software engineering" up until his death in 2002, arguing that those terms were poor analogies for what he called the "radical novelty" of computer science:

今日のソフトウェア開発で数多く使われる概念の考案者である、Edsger Dijkstraは彼が2002年までに「ソフトウェア工学」がコンピュータサイエンスの「ラディカルな新しさ」と呼ばれるものの安易なアナロジーであると主張して考えの誤りを指摘した。

A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot."[47]
これらの多くの現象が「ソフトウェア工学」の名のもとにまとめられてしまった。経済学が「不十分な科学」として知られるように、ソフトウェア工学も「不運な学問」として知られるべきだ。目標が自己矛盾しているために目標に近づくことすらできないからだ。もちろんソフトウェア工学は別の価値があると主張するがそれはでたらめだ。もしその主張を注意深く読み支持者が実際にしていることを分析すれば、ソフトウェア工学が「できないときにどうやってプログラムするか」という憲章として受け入れられていることを発見するだろう。

 

 

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

 

翻訳 第1章 : Software engineering - Wikipedia

Software Engineering is the application of engineering to the development of software in a systematic method.[1][2][3]

ソフトウェア工学は工学を体系的な手法によるソフトウェアの開発に適用することである。

1 Definitions 定義

Notable definitions of software engineering include:

ソフトウェア工学の高級な定義な次のようになる。

  • "the systematic application of scientific and technological knowledge, methods, and experience to the design, implementation, testing, and documentation of software"—The Bureau of Labor Statistics—IEEE Systems and software engineering - Vocabulary[4]
    「科学的で技術的な知識、方法、そして経験をソフトウェアの設計、実装、テスト、ドキュメントに系統的に応用すること」 - —The Bureau of Labor Statistics—IEEE Systems and software engineering - Vocabulary[4]
  • "The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software"—IEEE Standard Glossary of Software Engineering Terminology[5]
    「系統的で規則的な定量化できるアプローチをソフトウェアの開発、運用、保守に応用すること」-IEEE Standard Glossary of Software Engineering Terminology[5]
  • "an engineering discipline that is concerned with all aspects of software production"—Ian Sommerville[6]
    「ソフトウェアのプロダクトのすべての側面に関係した開発の学問」- Ian Sommerville
  • "the establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machines"—Fritz Bauer[7]
    「現実のマシンで信頼性でき効率的に機能するソフトウェアを経済的に獲得するための健全な技術原則の確立と使用」—Fritz Bauer[7]

The term has also been used less formally:

この用語は正式でないが次のように使われる。

  • as the informal contemporary term for the broad range of activities that were formerly called computer programming and systems analysis;[8]
    公式にはコンピュータプログラミングやシステム分析と呼ばれる広範囲の活動を表す非公式の現代語として
  • as the broad term for all aspects of the practice of computer programming, as opposed to the theory of computer programming, which is called computer science;[9]
    コンピュータサイエンスと呼ばれるコンピュータプログラミングの理論に対立するものとしてのコンピュータプログラミングの習慣のすべての側面を表す広い意味の用語として
  • as the term embodying the advocacy of a specific approach to computer programming, one that urges that it be treated as an engineering discipline rather than an art or a craft, and advocates the codification of recommended practices.[10]
    コンピュータプログラミングへの特定のアプローチの支持、つまり、芸術や工芸よりもむしろ工学の学問として扱う、また、推奨される経験を体系化するという主張を具体化する用語として.

 

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

 

翻訳 第1章 : Polymorphism (computer science) - Wikipedia

In programming languages and type theory, polymorphism (from Greek πολύς, polys, "many, much" and μορφή, morphē, "form, shape") is the provision of a single interface to entities of different types.[1] A polymorphic type is one whose operations can also be applied to values of some other type, or types.[2] There are several fundamentally different kinds of polymorphism:

プログラミング言語型理論では、ポリモルフィズム(ポリは「多く」、モーフは「形」を意味するギリシャ語)は異なる型のエンティティへの一つのインターフェースの提供である。ポリモルフィズム型とはその操作が他の型の値にもまた適用できるものである。ポリモルフィズムには根本的に異なるいくつかの種類がある。

  • Ad hoc polymorphism: when a function has different implementations depending on a limited range of individually specified types and combinations. Ad hoc polymorphism is supported in many languages using function overloading.
    アドホックポリモルフィズム:関数が個々の明示された型や結合の限られた範囲に依存した異なる実装。アドホックポリモルフィズムは関数のオーバーロードを使う多くの言語でサポートされている
  • Parametric polymorphism: when code is written without mention of any specific type and thus can be used transparently with any number of new types. In the object-oriented programming community, this is often known as generics or generic programming. In the functional programming community, this is often shortened to polymorphism.
    パラメトリックポリモルフィズム:コードが明示された型の言及なく書かれ、それゆえ多くの新しい型と一緒にすっきりと使われうる。オブジェクト指向プログラミングコミュニティでは、これはしばしばジェレリクスジェネリックプログラミングとして知られる。
  • Subtyping (also called subtype polymorphism or inclusion polymorphism): when a name denotes instances of many different classes related by some common superclass.[3]
    サブタイピング(サブタイプポリモルフィズムや包含ポリモルフィズムともよばれる):名前が共通のスーパークラスによって関連付けられた多くの異なるクラスのインスタンスを指す。

The interaction between parametric polymorphism and subtyping leads to the concepts of variance and bounded quantification.

パラメトリックポリモルフィズムとサブタイピングの間の相互作用に相違や束縛量化の概念が導かれる。

1 History

Ad hoc polymorphism and parametric polymorphism were originally described in Fundamental Concepts in Programming Languages, a set of lecture notes written in 1967 by British computer scientist Christopher Strachey.[4] In a 1985 paper, Peter Wegner and Luca Cardelli introduced the term inclusion polymorphism to model subtypes and inheritance.[2] However, implementations of subtyping and inheritance predate the term "inclusion polymorphism", having appeared with Simula in 1967.

アドホックポリモルフィズムパラメトリックポリモルフィズムはもともとイギリスの科学者であるChristopher Stracheyによって1967年に作られた講義資料のFundamental Concepts in Programming Languagesで説明された。1985年のペーパーで、Peter Wegner と Luca Cardelliは包含ポリモルフィズムの語句をサブタイプと継承のモデルへ導入した。しかしながら、サブタイプと継承の実装は1967年にSimulaで現れた「包含ポリモルフィズム」の前に現れた。

 

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

 

翻訳 第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による別のガイドライン集である。

 

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

Encapsulation (computer programming)

 

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

 

オブジェクト指向プログラミング言語では、カプセル化は関連しているがいかに述べる異なる2つもののうちの一つを指すために通常は使われて、時々2つの組み合わせを指する。

  • オブジェクトの構成物のいくつかへの直接的なアクセスの制限のための言語メカニズム[3][4]
  • データを操作するメソッド(や他の関数)をもったデータを束ねることを簡単にする言語の構成物[5][6]

プログラミング言語の研究者やアカデミックの人の一部は最初の意味だけかオブジェクト指向プログラミングの特徴をはっきりさせるように二つ目の意味の組み合わせで使うが、語彙クロージャーを提供するいくつかのプログラミング言語ではカプセル化オブジェクト指向と直交する言語の特徴として見られる。

2つ目の定義の同期は多くのオブジェクト指向言語コンポーネントの隠蔽が自動的に行われずまたオーバーライドされうる事実が動機にある。このように、情報隠蔽は2つ目の定義を好む人々によって別の概念として定義される。

カプセル化の特徴はほとんどのオブジェクト指向言語ではクラスをつかうことでサポートされるが、他の手段もまた存在する。

 一般的な定義

カプセル化オブジェクト指向プログラミングの基礎の一つである。これはデータとそれを操作するメソッドの集まりを指す。カプセル化はクラス内の構造化されたデータオブジェクトの値と状態を隠すこと、つまり許可されていないところからそれらに直接アクセスさせないことに使われる。publicにアクセスできるメソッドは通常はクラスの中で提供されて(いわゆるgetterとsetterによって)値にアクセスする。また他のクライエントクラスがこれらのメソッドを使ってオブジェクト内の値を取り出したり修正したりする。

この機構はオブジェクト指向プログラミング固有のものではない。モジュールのような抽象データ型の実装で似たようなカプセル化ができる。こうした類似点はどちらの考えも数学的な基礎の実存型によるということに由来する。

情報隠蔽カニズム

カプセル化はデータメンバと関数メンバを隠すために使われうる。この定義の上では、カプセル化が意味することは、オブジェクトの内部表現がオブジェクトの定義の外からみれば、一般的に隠されているということだ。一般的に、オブジェクトが所有するメソッドのみが直接オブジェクトのフィールドを検知して操作することができる。SmalltalkRubyといった一部の言語ではオブジェクトのメソッドを通じてのみアクセスすることが許されているが、ほとんどの他の言語(例えばC++, C#, Delphi, Java)では、一般的にpublicやprivateといったキーワードで隠されているものをある程度操作することをプログラマーに許可している。ISO C++ Standardではprotected, private, publicを「アクセス修飾子」としている。また、これらは「すべての情報を隠」さないとしている。情報隠蔽はヘッダーファイルが境界となるコンパイル済のソースコードを供給することで達成される。

オブジェクトの内部を隠すことはユーザーがコンポーネントの内部データを無効な/矛盾するデータを設定することを防ぐことでオブジェクトの完全性を保護する。カプセル化で得られるだろう利益としては、開発者がソフトウェアコンポーネント間の内部依存性を制限できるため、システムの複雑性を軽減して、堅牢性を向上させ、ることが挙げられる。

ほとんど常に、そのような保護をオーバーライドする方法がある。通常は、リフレクションAPI(Ruby, Java, C#など)、時々は名前修飾のようなメカニズム(Python), また、C++におけるfliedのような特別なキーワードの用法などである。

カプセル化オブジェクト指向言語でなくても可能である。例えばCでは、構造体はpublicAPI(例えばヘッダーファイル)でAPIのクライエントがアクセスできないデータメンバを含むデータのアイテムを操作する関数の集まりのために宣言されている。

クライエントはAPI関数をつかって不透明データ型のオブジェクトのアロケーションをする。このタイプのコンテンツはAPI関数の実装にのみ知られアクセルされる。クライエントはそのコンテンツに直接アクセスできない。これらの関数のソースコードはストラクチャーの実際のコンテンツを定義する。

カプセル化と継承

Design Patternsの著者は継承とカプセル化の間の緊張について長々と議論して、経験的に設計者は継承を使いすぎると主張している。危険性が次のように主張されている:

継承はサブクラスに親クラスの実装の詳細をさらすので、しばしば「継承はカプセル化を破壊する」といわれる。- Gang of Four, Design Patterns (Chapter 1)

翻訳 4章まで: "JavaScript" In Wikipedia, The Free Encyclopedia

 

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

 

JavaScript (/ˈdʒɑːvəˌskrɪpt/),[6] often abbreviated as JS, is a high-level, interpreted programming language. It is a language which is also characterized as dynamic, weakly typed, prototype-based and multi-paradigm.

JavaScriptはしばしばJSと略され、高水準インタプリタ形式のプログラミング言語だ。動的、弱い型付け、プロトタイプベース、マルチ・パラダイムといった特徴もある。

Alongside HTML and CSS, JavaScript is one of the three core technologies of the World Wide Web.[7] JavaScript enables interactive web pages and thus is an essential part of web applications. The vast majority of websites use it,[8] and all major web browsers have a dedicated JavaScript engine to execute it.

HTMLやCSSと一緒に、JavaScriptワールドワイドウェブの3つの中心的な技術の一つだ。JavaScriptインタラクティブなウェブページを可能にしてウェブアプリケーションの極めて重要な一部だ。ウェブサイトの大半で使われていて、主要なウェブブラウザーではJavaScript専用エンジンを使って処理する。

As a multi-paradigm language, JavaScript supports event-driven, functional, and imperative (including object-oriented and prototype-based) programming styles. It has an API for working with text, arrays, dates, regular expressions, and basic manipulation of the DOM, but the language itself does not include any I/O, such as networking, storage, or graphics facilities, relying for these upon the host environment in which it is embedded.

マルチ・パラダイム言語として、JavaScriptはイベント駆動型、関数型、命令型(オブジェクト指向とプロトタイプベースを含む)のプログラミングパラダイムだ。テキスト、配列、データ、正規表現、DOMの基本的操作のためのAPIがあるが、ネットワーク、ストレージ、グラフィックス機能といった入出力機能は一切なく、組み込まれたホスト環境に依存している。

Initially only implemented client-side in web browsers, JavaScript engines are now embedded in many other types of host software, including server-side in web servers and databases, and in non-web programs such as word processors and PDF software, and in runtime environments that make JavaScript available for writing mobile and desktop applications, including desktop widgets.
JavaScriptエンジンは、始めのうちはウェブブラウザーのクライアント側にのみ実装されていたが、今ではウェブサーバー、データベース、ワードプロセッサーやPDFソフトウェアのような非ウェブプログラム、JavaScripでデスクトップウィジェットを含むモバイルやデスクトップアプリケーションを記述できるようにする実行環境といったサーバー側を含む多くの他のホストソフトウェアに組み込まれている。

Although there are strong outward similarities between JavaScript and Java, including language name, syntax, and respective standard libraries, the two languages are distinct and differ greatly in design; JavaScript was influenced by programming languages such as Self and Scheme.[9]

JavaScripとJavaの間には言語の名前、文法、個々の標準ライブラリといったように表面上は強い類似点があるが、これらの言語は設計の点で全く別でかなり異なっている。JavaScripはSelfやSchemeといったようなプログラミング言語の影響を受けている。

1 History 歴史 ※割愛

1.1 Beginnings at Netscape

1.2 Server-side JavaScript

1.3 Adoption by Microsoft

1.4 Standardization

1.5 Later developments

2 Trademark 商標

"JavaScript" is a trademark of Oracle Corporation in the United States.[28] It is used under license for technology invented and implemented by Netscape Communications and current entities such as the Mozilla Foundation.[29]

「JavaScrip」は米国オラクルの商標である。Netscape CommunicationsMozilla Foundationのような現在のエンティティによって開発・実装された技術の許可を受けた。

3 Vanilla JavaScript

The terms Vanilla JavaScript and Vanilla JS refer to JavaScript not extended by any frameworks or additional libraries. Scripts written in Vanilla JS are plain JavaScript code.[30][31]

Vanilla JavaScript と Vanilla JSという言葉はフレームワークや追加のライブラリで拡張されていないJavaScripを指している。Vanilla JSで書かれたスクリプトは普通のJavaScripコードである。

4 Features 特徴

4.1 Universal support 普遍的なサポート

All modern Web browsers support JavaScript with built-in interpreters.

全てのモダンなブラウザーインタープリターを備えていてJavaScripをサポートしている。

4.2 Imperative and structured 命令と構造

JavaScript supports much of the structured programming syntax from C (e.g., if statements, while loops, switch statements, do while loops, etc.). One partial exception is scoping: JavaScript originally had only function scoping with var. ECMAScript 2015 added keywords let and const for block scoping, meaning JavaScript now has both function and block scoping. Like C, JavaScript makes a distinction between expressions and statements. One syntactic difference from C is automatic semicolon insertion, which allows the semicolons that would normally terminate statements to be omitted.[32]

JavaScripはCを由来とする構造化プログラミングの大半(例えば、if文、while文、swith文、do-while文など)をサポートする。一部の例外はスコープだ。JavaScripははじめはvarによる関数スコープのみであった。ECMAScript 2015 でブロックスコープのためのletとconstが追加されて、JavaScripは今では関数とブロックの両方のスコープがある。Cのように、JavaScripでは式と文を区別する。Cとのシンタックスの違いの一つは自動的にセミコロンが挿入されることで、それにより文の最後に置かれるセミコロンを省略することができる。

4.3 Dynamic 動的

Typing

As with most scripting languages, JavaScript is dynamically typed; a type is associated with each value, rather than just with each expression. For example, a variable that is at one time bound to a number may later be re-bound to a string.[33] JavaScript supports various ways to test the type of an object, including duck typing.[34]

ほとんどのスクリプト言語のように、JavaScripは動的型付けだ。型は単にそれぞれの式よりも、それぞれの値に関連付けられる。例えば、ある時点で数と結びついている変数はそのあと文字列に結び付けられなおされるかもしれない。JavaScripはダックタイピングを含むオブジェクトの型をテストする様々な方法をサポートしている。

Run-time evaluation 実行時評価

JavaScript includes an eval function that can execute statements provided as strings at run-time.

JavaScripには実行時に文字列として提供される文を実行できる評価関数がある。

4.4 Prototype-based (object-oriented) プロトタイプベース(オブジェクト指向

JavaScript is almost entirely object-based. In JavaScript, an object is an associative array, augmented with a prototype (see below); each string key provides the name for an object property, and there are two syntactical ways to specify such a name: dot notation (obj.x = 10) and bracket notation (obj['x'] = 10). A property may be added, rebound, or deleted at run-time. Most properties of an object (and any property that belongs to an object's prototype inheritance chain) can be enumerated using a for...in loop.

JavaScripはほとんど完全にオブジェクト指向だ。JavaScripでは、オブジェクトのプロパティは(以下で見るように)プロトタイプで増加する連想配列である。つまり、それぞれのキーはオブジェクトの名前を指し、そのような名前を指定するには二つの文法的方法がある。ドット表記(obj.x = 10)と角括弧(obj['x']=10)である。プロパティは実行時に追加、リバインド、削除できる。オブジェクト(とオブジェクトのプロトタイプチェーンに属するプロパティ)のほとんどのプロパティはfor...in loopを使って数え上げることができる。

JavaScript has a small number of built-in objects, including Function and Date.

JavaScripには関数と日付を含むビルトインオブジェクトが少ない。

Prototypes

JavaScript uses prototypes where many other object-oriented languages use classes for inheritance.[35] It is possible to simulate many class-based features with prototypes in JavaScript.[36]

JavaScripにはほかの多くのオブジェクト指向言語が継承のために使うクラスに相当するプロトタイプがあり、プロトタイプを使ってクラスベースの多くの特徴をシミュレーションできる。

Functions as object constructors オブジェクトのコンストラクタとしての関数

Functions double as object constructors, along with their typical role. Prefixing a function call with new will create an instance of a prototype, inheriting properties and methods from the constructor (including properties from the Object prototype).[37] ECMAScript 5 offers the Object.create method, allowing explicit creation of an instance without automatically inheriting from the Object prototype (older environments can assign the prototype to null).[38] The constructor's prototype property determines the object used for the new object's internal prototype. New methods can be added by modifying the prototype of the function used as a constructor. JavaScript's built-in constructors, such as Array or Object, also have prototypes that can be modified. While it is possible to modify the Object prototype, it is generally considered bad practice because most objects in JavaScript will inherit methods and properties from the Object prototype, and they may not expect the prototype to be modified.[39]

関数は本来の役割に加えて、オブジェクトのコンストラクタとしても働く。newを関数の前に付けると(オブジェクトのプロトタイプからのプロパティを含む)コンストラクタからのプロパティとメソッドを継承した、プロトタイプのインスタンスを生成する。 ECMAScript 5では、オブジェクトのプロトタイプからの自動的な継承をせずにインスタンスを明示的に作れる、オブジェクト生成メソッドが提供される(より古い環境ではプロトタイプをnullに割り当てられる)。コンストラクタのプロトタイププロパティは新しいオブジェクトの内部プロトタイプのために使われるオブジェクトを決定する。JavaScripのArrayやObjectといった内蔵コンストラクタは修正されることができるプロトタイプを備えている。オブジェクトのプロトタイプを修正することができる一方で、一般的にはJavaScripのほとんどのオブジェクトはオブジェクトのプロトタイプからメソッドとプロパティを継承するだろうし、それらは修正されたプロトタイプであることを要求しないので悪い習慣だと考えられる。

Functions as methods メソッドとしての関数

Unlike many object-oriented languages, there is no distinction between a function definition and a method definition. Rather, the distinction occurs during function calling; when a function is called as a method of an object, the function's local this keyword is bound to that object for that invocation.

多くのオブジェクト指向言語と違って、関数の定義とメソッドの定義の間区別はない。むしろ、違いは関数の呼び出しにある。オブジェクトのメソッドとして関数が呼ばれると、関数のローカルthisキーワードはそのまじないのためのオブジェクトと結び付けられる。

4.5 Functional

A function is first-class; a function is considered to be an object. As such, a function may have properties and methods, such as .call() and .bind().[40] A nested function is a function defined within another function. It is created each time the outer function is invoked. In addition, each nested function forms a lexical closure: The lexical scope of the outer function (including any constant, local variable, or argument value) becomes part of the internal state of each inner function object, even after execution of the outer function concludes.[41] JavaScript also supports anonymous functions.

関数は第一級クラスだ。関数はオブジェクトとして考えられる。そのようにして、関数は、プロパティと.call(9や.bind()のようなメソッドを持つかもしれない。ネストされた関数はとは他の関数で定義された関数である。他の関数が呼び出されるたびに作成される。加えて、それぞれのネストされた関数は辞書的なクロージャを形成する。他の関数(全ての定数、ローカル変数、引数を含む)の辞書的範囲は外の関数の終わりの実行後ですら、それぞれの内部関数のオブジェクトの内部状態の一部になる。JavaScripでは無名関数をサポートする。

4.6 Delegative 委譲

JavaScript supports implicit and explicit delegation.

JavaScripは暗示的/明示的委譲をサポートする。

Functions as roles (Traits and Mixins) 役割としての関数

JavaScript natively supports various function-based implementations of Role[42] patterns like Traits[43][44] and Mixins.[45] Such a function defines additional behavior by at least one method bound to the this keyword within its function body. A Role then has to be delegated explicitly via call or apply to objects that need to feature additional behavior that is not shared via the prototype chain.

JavaScripは元々TraitとMixinのようなRoleパターンの様々な関数ベースの実装をサポートする。そのような関数は関数のボディーでthisキーワードに結び付けられた少なくとも一つの関数によって追加できに振る舞いを定義する。Roleはそれからプロトタイプチェーンによって共有されない追加の振る舞いをフューチャーする必要のないオブジェクトを読んだり適用することで明示的に委譲されなければならない。

Object composition and inheritance オブジェクトの集約と継承

Whereas explicit function-based delegation does cover composition in JavaScript, implicit delegation already happens every time the prototype chain is walked in order to, e.g., find a method that might be related to but is not directly owned by an object. Once the method is found it gets called within this object's context. Thus inheritance in JavaScript is covered by a delegation automatism that is bound to the prototype property of constructor functions.

JavaScripでは明示的な関数ベースの委譲が集約をカバーしている一方で、暗示的な委譲はすでにプロトタイプチェーンが例えば、関連しているがオブジェクトによって直接所有されていないメソッドを見つけるためにプロパティチェーンが張られるといつも発生する。メソッドが見つかるとオブジェクトのコンテクストないで呼ばれる。このようにJavaScripでは継承はコンストラクタ関数の適切なプロパティに結びついた委譲自動でカバーされる。

4.7 Miscellaneous 多様性

Run-time environment 実行環境

JavaScript typically relies on a run-time environment (e.g., a Web browser) to provide objects and methods by which scripts can interact with the environment (e.g., a webpage DOM). It also relies on the run-time environment to provide the ability to include/import scripts (e.g., HTML <script> elements). This is not a language feature per se, but it is common in most JavaScript implementations.

JavaScripは元々スクリプトと環境と相互に作用する(例えば、ウェブページのDOM)ことによってオブジェクトやメソッドを提供するために実行環境(例えば、ウェブブラウザー)に依存する。また、スクリプト(例えば、HTMLの<script>element)を入出力する能力を提供するために実行環境に依存する。これはそれ自体は言語の特徴ではないが、ほとんどJavaScrip実装では共通だ。
JavaScript processes messages from a queue one at a time. Upon loading a new message, JavaScript calls a function associated with that message, which creates a call stack frame (the function's arguments and local variables). The call stack shrinks and grows based on the function's needs. Upon function completion, when the stack is empty, JavaScript proceeds to the next message in the queue. This is called the event loop, described as "run to completion" because each message is fully processed before the next message is considered. However, the language's concurrency model describes the event loop as non-blocking: program input/output is performed using events and callback functions. This means, for instance, that JavaScript can process a mouse click while waiting for a database query to return information.[46]

JavaScriptはキューからメッセージを1つずつ処理する。新しいメッセージをロードしている時、JavaScripはコールスタックフレーム(関数の引数とローカル変数)を生成する、メッセージに関する関数を呼び出す。コールスタックは関数の要求に応じて小さくなったり大きくなったりする。関数が終了するとき、つまり、スタックが空になったとき、JavaScripはキューのなかの次のメッセージを処理する。これはイベントループとよばれ、次のメッセージが見られる前にそれぞれのメッセージを完全に処理するために、「終了まで実行する」といわれる。しかしながら、言語の同時実行モデルはイベントループを非ブロッキング、つまり、プログラムのioがイベントとコールバック関数を使うことで行われることとして説明する。実際にはこれはJavaScripが情報を返すためにデータベースクエリーを待っている間にマウスクリックを処理することができることを意味する。

Variadic functions 可変長引数関数

An indefinite number of parameters can be passed to a function. The function can access them through formal parameters and also through the local arguments object. Variadic functions can also be created by using the bind method.

不定の引数を関数に渡すことができる。関数は仮パラメータまたはローカルargumentオブジェクトと通じてそれらにアクセスできる。可変長引数関数はbindメソッドを使うことで作ることもできる。

Array and object literals

Like many scripting languages, arrays and objects (associative arrays in other languages) can each be created with a succinct shortcut syntax. In fact, these literals form the basis of the JSON data format.

多くのスクリプト言語のように、配列とオブジェクト(ほかの言語における連想配列)はそれぞれ簡単なショートカットシンタックスで作ることができる。実際、これらのリテラルJSONのデータフォーマットの基礎をつくる。

Regular expressions 正規表現

JavaScript also supports regular expressions in a manner similar to Perl, which provide a concise and powerful syntax for text manipulation that is more sophisticated than the built-in string functions.[47]

Javascriptはまた正規表現をstring関数に内蔵されているよりも洗練されたテキスト操作のための完結で強力な文法を提供するPerlに似た方法でサポートする。

4.8 Vendor-specific extensions ベンダー固有の拡張

JavaScript is officially managed by Mozilla Foundation, and new language features are added periodically. However, only some JavaScript engines support these new features:

JavaScripはMozilla Foundationによって公式に管理され、新しい言語の特徴は定期的に追加される。しかしながら、いくつかのJavaScripエンジンだけが次の特徴をサポートする。

  • property getter and setter functions (supported by WebKit, Gecko, Opera,[48] ActionScript, and Rhino)[49]
  • conditional catch clauses
  • iterator protocol (adopted from Python)
  • shallow generators-coroutines (adopted from Python)
  • array comprehensions and generator expressions (adopted from Python)
  • proper block scope via the let keyword
  • array and object destructuring (limited form of pattern matching)
  • concise function expressions (function(args) expr)
  • ECMAScript for XML (E4X), an extension that adds native XML support to ECMAScript (unsupported in Firefox since version 21[50])

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

 

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

 

Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which may contain data, in the form of fields, often known as attributes; and code, in the form of procedures, often known as methods. A feature of objects is that an object's procedures can access and often modify the data fields of the object with which they are associated (objects have a notion of "this" or "self"). In OOP, computer programs are designed by making them out of objects that interact with one another.[1][2] There is significant diversity of OOP languages, but the most popular ones are class-based, meaning that objects are instances of classes, which typically also determine their type.

オブジェクト指向プログラミング(OOP)は、オブジェクト、つまり、しばしば属性として知られるフィールドの形でデータを保有し、しばしばメソッドとして知られるプロシージャの形でコードを保有する、「オブジェクト」の概要に基づくプログラミング・パラダイムである。オブジェクトの特徴は、オブジェクトの手順が関連するオブジェクト(オブジェクトには「これ」と「自分」の概念がある)のデータ・フィールドにアクセスして変更できるところにある。オブジェクト指向プログラミングでは、コンピュータプログラミングはほかのオブジェクトと相互に作用するオブジェクトからプログラミングを作り出すことで設計する。オブジェクト指向プログラミング言語には膨大な多様性があるが、最も一般的なものは、オブジェクトがクラス(タイプを決定するもの)のインスタンスであることを意味する、クラス・ベースである。

Many of the most widely used programming languages (such as C++, Object Pascal, Java, Python etc.) are multi-paradigm programming languages that support object-oriented programming to a greater or lesser degree, typically in combination with imperative, procedural programming. Significant object-oriented languages include Java, C++, C#, Python, PHP, Ruby, Perl, Object Pascal, Objective-C, Dart, Swift, Scala, Common Lisp, and Smalltalk.

C++, Object Pascal, Java, Pythonなどのような)最もよく使われる多くのプログラミング言語は、特に命令型プログラミングと手続き型プログラミングを組み合わせて、多かれ少なかれオブジェクト指向プログラミングをサポートするマルチ・パラダイムプログラミング言語である。重要なオブジェクト指向言語Java, C++, C#, Python, PHP, Ruby, Perl, Object Pascal, Objective-C, Dart, Swift, Scala, Common Lisp, Smalltalkである。

 

Features 特徴

Object-oriented programming uses objects, but not all of the associated techniques and structures are supported directly in languages that claim to support OOP. The features listed below are, however, common among languages considered strongly class- and object-oriented (or multi-paradigm with OOP support), with notable exceptions mentioned.[3][4][5][6]

オブジェクト指向言語はオブジェクトを使うが、関連する技術と構造が全てオブジェクト指向プログラミングをサポートとすると言っている言語において直接サポートされているわけではない。しかしながら、次に掲げる特徴は強いクラス指向、オブジェクト指向(または、オブジェクト指向プログラミングをサポートするマルチ・パラダイム)と見られる言語に共通して見られるが、明らかな例外もある。

1.1 Shared with non-OOP predecessor languages オブジェクト指向でないプログラミング言語との共通点

  • Variables that can store information formatted in a small number of built-in data types like integers and alphanumeric characters. This may include data structures like strings, lists, and hash tables that are either built-in or result from combining variables using memory pointers
    変数とは整数やアルファベットのような組込みデータ型の少しだけで作られる情報を持つもの。これは、組込みまたはポインタ変数を合わせてできる、文字列、リスト、ハッシュテーブルのようなデータ構造も含むかもしれない。
  • Procedures – also known as functions, methods, routines, or subroutines – that take input, generate output, and manipulate data. Modern languages include structured programming constructs like loops and conditionals.
    プロシージャは、関数、メソッド、ルーチン、サブルーチンとしても知られ、入出力やデータの操作をする。現代的な現代ではループや分岐のような構造化プログラミングを含む。

Modular programming support provides the ability to group procedures into files and modules for organizational purposes. Modules are namespaced so identifiers in one module will not be accidentally confused with a procedure or variable sharing the same name in another file or module.

 モジュール・プログラミングは手順を組織化するためにファイルやモジュールにまとめる能力の提出をサポートする。あるモジュールの識別子がほかのファイルやモジュール内で同じ名前になるプロシージャと偶然にも混乱させられないようにするためにモジュールは名前空間になっている。

1.2 Objects and classes オブジェクトとクラス

Languages that support object-oriented programming typically use inheritance for code reuse and extensibility in the form of either classes or prototypes. Those that use classes support two main concepts:

オブジェクト指向プログラミングをサポートしている言語は概してコード再利用とクラスとプロトタイプの拡張性ための継承が使える。クラスを使う言語は以下の二つのメインコンセプトをサポートする。

  • Classes – the definitions for the data format and available procedures for a given type or class of object; may also contain data and procedures (known as class methods) themselves, i.e. classes contain the data members and member functions
    クラス–データフォーマットと与えられた型やオブジェクトのクラスが利用できるプロシージャの定義。クラスメソッドとして知られるデータやプロシージャを持つこともある。例えばデータのメンバとメンバ・関数のあるクラス。
  • Objects – instances of classes
    オブジェクト–クラスのインスタンス

Objects sometimes correspond to things found in the real world. For example, a graphics program may have objects such as "circle", "square", "menu". An online shopping system might have objects such as "shopping cart", "customer", and "product".[7] Sometimes objects represent more abstract entities, like an object that represents an open file, or an object that provides the service of translating measurements from U.S. customary to metric.

オブジェクトはよく現実世界のものに対応する。例えば、グラフィックプログラミングでは「円」、「四角形」、「メニュー」といったオブジェクトがあるかもしれない。オンラインショッピングシステムでは「ショッピングカート」、「カスタマー」、「プロダクト」といったオブジェクトがあるかもしれない。ときどきオブジェクトは、オープンファイルをあらわすオブジェクト、もしくはアメリカの慣習的なものからメートル法に測定法を変換するサービスを提供するオブジェクトのようなより抽象的な実体を表す。

Object-oriented programming is more than just classes and objects; it's a whole programming paradigm based around objects (data structures) that contain data fields and methods. It is essential to understand this; using classes to organize a bunch of unrelated methods together is not object orientation.
オブジェクト指向プログラミングは単なるクラスとオブジェクトよりも広い概念だ。それはデータ・フィールドとメソッドを含むオブジェクト(データ構造)に基づくプログラミングパラダイム全てだ。関係のないメソッドの束をまとめるクラスを使うことはオブジェクト指向ではないということを理解することは重要だ。
Junade Ali, Mastering PHP Design Patterns[8]

Each object is said to be an instance of a particular class (for example, an object with its name field set to "Mary" might be an instance of class Employee). Procedures in object-oriented programming are known as methods; variables are also known as fields, members, attributes, or properties. This leads to the following terms:
それぞれのオブジェクトは特定のクラス(例えば、名前のフィールドが「Mary」に設定されたオブジェクトは従業員クラスのインスタンスかもしれない)のインスタンスと言われる。オブジェクト指向言語でのプロシージャはメソッドとして知られる。変数は、フィールド、メンバ、属性、プロパティとしても知られる。これらから次の語句について説明する。

  • Class variables – belong to the class as a whole; there is only one copy of each one
    クラス変数ー全体的にクラスに所属する。一つに対してコピーは一つのみである。
  • Instance variables or attributes – data that belongs to individual objects; every object has its own copy of each one
    インスタンス変数ー個々のオブジェクトに所属するデータ。全てのオブジェクトは全てオブジェクトには各変数の独自のコピーがある。
  • Member variables – refers to both the class and instance variables that are defined by a particular class
    メンバ変数ー特定のクラスによって定義されるクラスとインスタンス変数の両方を指す。
  • Class methods – belong to the class as a whole and have access only to class variables and inputs from the procedure call
    クラスメソッドー全体としてクラスに属してクラス変数にのみアクセスできてプロシージャの呼び出しで入力される
  • Instance methods – belong to individual objects, and have access to instance variables for the specific object they are called on, inputs, and class variables
    インスタンスメソッドー個々のオブジェクトに所属して、それらが呼び出される特定のオブジェクトに対するインスタンス変数、入力、クラス変数にアクセスする。

Objects are accessed somewhat like variables with complex internal structure, and in many languages are effectively pointers, serving as actual references to a single instance of said object in memory within a heap or stack. They provide a layer of abstraction which can be used to separate internal from external code. External code can use an object by calling a specific instance method with a certain set of input parameters, read an instance variable, or write to an instance variable. Objects are created by calling a special type of method in the class known as a constructor. A program may create many instances of the same class as it runs, which operate independently. This is an easy way for the same procedures to be used on different sets of data.

オブジェクトは複雑な内部構造をもつ変数のような何かにアクセスする。多くの言語では、ヒープやスタックのオブジェクトと呼ばれる一つのインスタンスに実際に参照する事実上のポインターである。オブジェクトは外部のコードから内ぷを分離するために使われうる抽象化のレイヤーを提供する。外部コードは入力引数リストで特定のインスタンスメソッドを呼び出すことでオブジェクトを使い、インスタンス変数を読み込み、または、インスタンス変数に書き込むことができる。オブジェクトはコンストラクタというクラス内の特殊なメソッドを呼び出して作られる。プログラムは動いているとき同じクラスの多くのインスタンスを作ることもある。それらは独立して動く。これは同じプロシージャが異なるデータセットで使われる簡単な方法だ。

Object-oriented programming that uses classes is sometimes called class-based programming, while prototype-based programming does not typically use classes. As a result, a significantly different yet analogous terminology is used to define the concepts of object and instance.

プロトタイプベースプログラミングは一般にクラスを用いない一方で、クラスを用いるオブジェクト指向プログラミングはときどきクラスベースプログラミングと言われる。その結果、大きく異なるが似た語句がオブジェクトとインスタンスの概念を定義するために使われる。

In some languages classes and objects can be composed using other concepts like traits and mixins.

いくつかの言語ではクラスとオブジェクトはトレイトやmixinのようなほかの概念から成り立ちうる。

1.3 Class-based vs prototype-based クラスベースとプロトタイプベースの比較

In class-based languages the classes are defined beforehand and the objects are instantiated based on the classes. If two objects apple and orange are instantiated from the class Fruit, they are inherently fruits and it is guaranteed that you may handle them in the same way; e.g. a programmer can expect the existence of the same attributes such as color or sugar content or is ripe.

クラスベース言語ではクラスはクラスは前もって定義されて、オブジェクトはクラスに基づいてインスタンス化される。二つのオブジェクト、リンゴとオレンジがフルーツクラスからインスタンス化されると、それらは本質的にフルーツであり、同じように扱うことが保証される。例えば、プログラマーは、色や糖分、または熟しているかといったような属性の存在を期待する。

In prototype-based languages the objects are the primary entities. No classes even exist. The prototype of an object is just another object to which the object is linked. Every object has one prototype link (and only one). New objects can be created based on already existing objects chosen as their prototype. You may call two different objects apple and orange a fruit, if the object fruit exists, and both apple and orange have fruit as their prototype. The idea of the fruit class doesn't exist explicitly, but as the equivalence class of the objects sharing the same prototype. The attributes and methods of the prototype are delegated to all the objects of the equivalence class defined by this prototype. The attributes and methods owned individually by the object may not be shared by other objects of the same equivalence class; e.g. the attributes sugar content may be unexpectedly not present in apple. Only single inheritance can be implemented through the prototype.

プロトタイプベース言語ではオブジェクトは初等のエンティティである。クラスすら存在しない。オブジェクトのプロトタイプはたんなるそのオブジェクトがリンクされているもう一つののオブジェクトである。全てオブジェクトが一つのプロトタイプリンクを持っている。新しいオブジェクトは、プロトタイプとして選択された既に存在するオブジェクトに基づいて作られるだろう。フルーツオブジェクトが存在していると、二つの異なるオブジェクト、リンゴとオレンジを呼び出し、リンゴとオレンジの両方はプロトタイプとしてフルーツを持っている。フルーツクラスの考え方は明らかに存在しないが、同じプロトタイプを共有するオブジェクトの同値クラスとして存在する。プログラミングの属性とメソッドはプロトタイプによって定義された同値クラスのオブジェクトに委譲される。オブジェクトが個々に所有する属性とメソッドは同じ同値クラスの他のオブジェクトが持っていないかもしれない。例えば、属性砂糖はリンゴに予期せず存在しないかもしれない。プロトタイプを通じてたった一つの継承が実装されうる。

1.4 Dynamic dispatch/message passing 動的ディスパッチとメッセージ受け渡し

It is the responsibility of the object, not any external code, to select the procedural code to execute in response to a method call, typically by looking up the method at run time in a table associated with the object. This feature is known as dynamic dispatch, and distinguishes an object from an abstract data type (or module), which has a fixed (static) implementation of the operations for all instances. If there are multiple methods that might be run for a given name, it is known as multiple dispatch.

 実行時にオブジェクトに関連した表の中のメソッドを調べることによる、メソッドコールに反応して実行するために外部コードでなく手順のコードを選ぶことは、オブジェクトの責任である。この特徴は動的ディスパッチと呼ばれ、オブジェクトを、全てのインスタンスを操作することの実装を修正する、抽象データ型(やモジュール)と区別する。与えられた名前で実行されるだろうマルチプルメソッドがあると、マルチプルディスパッチと言われる。

A method call is also known as message passing. It is conceptualized as a message (the name of the method and its input parameters) being passed to the object for dispatch.

メソッドコールはメッセージパッシングとも言われる。ディスパッチのためのオブジェクトへ送る(メソッドの名前と入力引数)メッセージとして概念化される。

1.5 Encapsulation カプセル化

Encapsulation is an object-oriented programming concept that binds together the data and functions that manipulate the data, and that keeps both safe from outside interference and misuse. Data encapsulation led to the important OOP concept of data hiding.

カプセル化はデータとデータを操作する関数を一緒にまとめて、外部のインタフェースと誤用から安全性を維持するためのオブジェクト指向プログラミングの概念である。データのカプセル化はデータ隠蔽の重要なオブジェクト指向プログラミングの概念につながる。

If a class does not allow calling code to access internal object data and permits access through methods only, this is a strong form of abstraction or information hiding known as encapsulation. Some languages (Java, for example) let classes enforce access restrictions explicitly, for example denoting internal data with the private keyword and designating methods intended for use by code outside the class with the public keyword. Methods may also be designed public, private, or intermediate levels such as protected (which allows access from the same class and its subclasses, but not objects of a different class). In other languages (like Python) this is enforced only by convention (for example, private methods may have names that start with an underscore). Encapsulation prevents external code from being concerned with the internal workings of an object. This facilitates code refactoring, for example allowing the author of the class to change how objects of that class represent their data internally without changing any external code (as long as "public" method calls work the same way). It also encourages programmers to put all the code that is concerned with a certain set of data in the same class, which organizes it for easy comprehension by other programmers. Encapsulation is a technique that encourages decoupling.

もしクラスがコードに内部のオブジェクトデータにアクセスさせず、メソッドだけを通してアクセスを許可すれば、これはカプセル化として知られる抽象化や情報隠蔽の強い形である。(Javaなどの)いくつかの言語ではクラスに明確に制限をする。例えばprivate句で内部データを表し、public句でクラス外のコードによる使用を意図するメソッドをデザインする。メソッドはpublic, private, 、protectedのような中間のレベル(同じクラスからはアクセスできるがほかのクラスのオブジェクトからはアクセスできない)がデザインできる。(Pythonのような)ほかの言語では、これはしきたりによってのみ強制される(例えば、private メソッドはアンダースコアから始まる名前)。カプセル化は外部コードがオブジェクトの内部の働きに興味を持たせないようにする。これはリファクタリングを容易にする。例えば、クラスの作者が(publicメソッドが同じ方法で呼び出す限り)外部コードを一切変えずにクラスのオブジェクトの内部データの表し方を変えてもよい。また、プログラマに対して、あるデータの集まりに関連する全てのコードを、ほかのプログラマが簡単に理解できるように作られた、同じクラスに置くことを促す。カプセル化は結合度を下げることを促す技術だ。

1.6 Composition, inheritance, and delegation 集約、継承、委譲

Objects can contain other objects in their instance variables; this is known as object composition. For example, an object in the Employee class might contain (point to) an object in the Address class, in addition to its own instance variables like "first_name" and "position". Object composition is used to represent "has-a" relationships: every employee has an address, so every Employee object has a place to store an Address object.

オブジェクトはインスタンス変数に他のオブジェクトを持つことができる。これはオブジェクト集約として知られる。例えば、従業員オブジェクトは、「名前」や「役職」といったインスタンス変数を所有することに加えて、アドレスクラスのオブジェクトを持つ(指す)だろう。オブジェクト集約は「has-a」関係を表す。つまり、全ての従業員は住所を持っているので全ての従業員クラスにはアドレスオブジェクトを持つ場所がある。

Languages that support classes almost always support inheritance. This allows classes to be arranged in a hierarchy that represents "is-a-type-of" relationships. For example, class Employee might inherit from class Person. All the data and methods available to the parent class also appear in the child class with the same names. For example, class Person might define variables "first_name" and "last_name" with method "make_full_name()". These will also be available in class Employee, which might add the variables "position" and "salary". This technique allows easy re-use of the same procedures and data definitions, in addition to potentially mirroring real-world relationships in an intuitive way. Rather than utilizing database tables and programming subroutines, the developer utilizes objects the user may be more familiar with: objects from their application domain.[9]

クラスをサポートする言語はほとんどいつも継承をサポートする。これによってクラスは「is-a-type-of」関係を表す階層構造に整えられる。例えば、従業員クラスは人クラスを継承するかもしれない。親クラスを利用できる全てのデータとメソッドは同じ名前の子クラスに表示される。例えば、人クラスはmake_full_name()メソッドと変数first_name, last_nameをを定義するかもしれない。これらは「役職」と「給料」を追加しているかもしれない従業員クラスでも利用できるだろう。この技術を使えば直感的な方法で現実世界の関係を潜在的に映し出すことに加えて、同じ手順とデータの定義を簡単に再利用できる。データベースの表を利用してサブルーチンをプログラミングするよいrも、開発者はユーザーがより親しんでいる、応用分野に由来するオブジェクトを利用する。

Subclasses can override the methods defined by superclasses. Multiple inheritance is allowed in some languages, though this can make resolving overrides complicated. Some languages have special support for mixins, though in any language with multiple inheritance, a mixin is simply a class that does not represent an is-a-type-of relationship. Mixins are typically used to add the same methods to multiple classes. For example, class UnicodeConversionMixin might provide a method unicode_to_ascii() when included in class FileReader and class WebPageScraper, which don't share a common parent.

サブクラスはスーパークラスで定義されたメソッドをオーバライドできる。多重継承は、リゾルビングオーバライドを複雑にするだろうが、いくつかの言語で利用できる。いくつかの言語では、多重継承が使える全ての言語で、mixinは「is-a-type-of」関係を表さない単純なクラスだが、mixinの特別なサポートがある。mixinはとくに多重クラスに同じメソッドを追加するために使われる。例えば、UnicodeConversionMixinクラスはunicode_to_ascii() を、親を共有しないFileReaderクラスとWebPageScraperクラスに含まれている時に、提供するかもしれない。

Abstract classes cannot be instantiated into objects; they exist only for the purpose of inheritance into other "concrete" classes which can be instantiated. In Java, the final keyword can be used to prevent a class from being subclassed.

抽象クラスはオブジェクトへとインスタンス化することができない。インスタンス化できるほかの「具象」クラスに継承させるためだけに存在する。Javaでは、final句はクラスにサブクラスを持たせないことができる。

The doctrine of composition over inheritance advocates implementing has-a relationships using composition instead of inheritance. For example, instead of inheriting from class Person, class Employee could give each Employee object an internal Person object, which it then has the opportunity to hide from external code even if class Person has many public attributes or methods. Some languages, like Go do not support inheritance at all.

継承を超えた集約のドクトリンは継承の代わりに集約をつかったhas-a関係を実装することである。例えば、人クラスから継承する代わりに従業員クラスは、もし人クラスがpublic属性やメソッドを持っているときですら外部コードから隠す機会を持っている、内部人クラスを従業員オブジェクトに与える。GOのようないくつかの言語では継承は全くサポートされていない。

The "open/closed principle" advocates that classes and functions "should be open for extension, but closed for modification".

開放/閉鎖原則はクラスと関数は「拡張に対して開いていて、修正に対して閉じているべき」というものだ。

Delegation is another language feature that can be used as an alternative to inheritance.

委譲は継承を代替することができるほかの言語特徴だ。

1.7 Polymorphism ポリモーフィズム

Subtyping, a form of polymorphism, is when calling code can be agnostic as to whether an object belongs to a parent class or one of its descendants. For example, a function might call "make_full_name()" on an object, which will work whether the object is of class Person or class Employee. This is another type of abstraction which simplifies code external to the class hierarchy and enables strong separation of concerns.

派生型は、ポリモーフィズムの形態で、呼び出すコードが親クラスまたはその子孫に属していないオブジェクトであるかどうかを知らないときにいう。例えば、関数は人クラスか従業員クラスのオブジェクトであるか考えるオブジェクトについての「make_full_name()」を呼ぶかもしれない。クラス階層の外部コードを単純化し関心の分離を強化する抽象型の一つである

1.8 Open recursion

In languages that support open recursion, object methods can call other methods on the same object (including themselves), typically using a special variable or keyword called this or self. This variable is late-bound; it allows a method defined in one class to invoke another method that is defined later, in some subclass thereof.

open recursionをサポートする言語では、オブジェクトメソッドは特に自身で呼ばれる特別な変数やキーワードを使って(自身を含む)同じオブジェクトについてのほかのメソッドを呼び出すことができる。この変数は束縛変数、つまり、あるクラスで定義されるメソッドであとから定義するほかのメソッドを呼び出すことを可能にする。

翻訳 : "Object-based language" In Wikipedia, The Free Encyclopedia

 

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

 

The term "object-based language" may be used in a technical sense to describe any programming language that uses the idea of encapsulating state and operations inside "objects". Object-based languages need not support inheritance or subtyping, but those that do are also said to be "object-oriented". Object-based languages that do not support inheritance or subtyping are usually not considered to be true object-oriented languages.
「オブジェクトベース言語」という語句は「オブジェクト」内の状態と演算をカプセル化する考えを使うあらゆる言語を説明する技術的な意味で使われるかもしれない。オブジェクトベース言語は継承や細分化をサポートする必要はないが、そういったものも「オブジェクト指向」と呼ばれる。継承や細分化をサポートしないオブジェクトベース言語は通常は真のオブジェクト指向言語と考えられない。

Examples of object-oriented languages, in rough chronological order, include Simula, Smalltalk, C++ (whose object model was based on Simula's), Objective-C (whose object model was based on Smalltalk's), Eiffel, Xojo (previously REALbasic), Python, Ruby, Java, Visual Basic .NET, C#, and Fortran 2003. Examples of a language that is object-based, but not object-oriented are early versions of Ada, Visual Basic (VB), and Fortran 90. These languages all support the definition of an object as a data structure, but lack polymorphism and inheritance.
オブジェクト指向言語の例を、おおざっぱに年代順に並べると、Simula, Smalltalk, C++ (Simulaのオブジェクトモデルを拡張), Objective-C (Smalltalkのオブジェクトモデルを拡張), Eiffel, Xojo (以前はREALbasic), Python, Ruby, Java, Visual Basic .NET, C#, and Fortran 2003となる。オブジェクトベースだがオブジェクト指向でない言語は、初期のAda, Visual Basic (VB), and Fortran 90である。これらの言語は全てデータ構造としてオブジェクトの定義をサポートしているが、ポリモーフィズムと継承はサポートしていない。

In practice, the term "object-based" is usually applied to those object-based languages that are not also object-oriented, although all object-oriented languages are also object-based, by definition. Instead, the terms "object-based" and "object-oriented" are normally used as mutually exclusive alternatives, rather than as categories that overlap.
実際には、「オブジェクトベース」という語句は通常オブジェクト指向でないオブジェクトベース言語で使われる。しかし、定義上は全てのオブジェクト指向言語もまたオブジェクトベースである。代わりに、「オブジェクトベース」と「オブジェクト指向」の語句は通常、重複するカテゴリーよりは、相互に排他的な選択として使われる。

Sometimes, the term "object-based" is applied to prototype-based languages, true object-oriented languages that do not have classes, but in which objects instead inherit their code and data directly from other "template" objects. An example of a commonly used prototype-based scripting language is JavaScript.
時々、「オブジェクトベース」という語句はプロトタイプベース言語だったり、クラスを持たない真のオブジェクト指向言語に使われるが、オブジェクトは代わりにほかの「テンプレート」オブジェクトから直接コードとデータを継承する。一般的に使われるプロトタイプベーススクリプト言語の例はJavaScriptである。

Both object-based and object-oriented languages (whether class-based or prototype-based) may be statically type-checked. Statically checking prototype-based languages can be difficult, because these languages often allow objects to be dynamically extended with new behavior, and even to have their parent object (from which they inherit) changed, at run time.[1][2]
オブジェクトベース言語と(クラスベースであろうとプロトタイプベースであろうと)オブジェクト指向言語のどちらも静的に型検査されるだろう。プロトタイプベース言語の静的検査は、新しい振る舞いで動的に拡張することや、実行時に(継承している)親のオブジェクトを変えることすら、オブジェクトに認めているために、難しいだろう。

Difference between Object-oriented and Object-based languages(オブジェクト指向言語とオブジェクトベース言語の違い)

Object-oriented language
オブジェクト指向言語

Object-based language
オブジェクトベース言語

Object-oriented language supports all the features of OOPs (Abstraction, Encapsulation, Inheritance, Polymorphism).

オブジェクト指向言語は(抽象、カプセル化、継承、ポリモーフィズムといった)すべてのOOPの特徴を持っている。

Object-based languages don't support all the features of OOPs like polymorphism or inheritance.
オブジェクトベース言語はポリモーフィズムや継承といったOOPのすべての特徴を持っているわけではない。

Examples: C++, C#, Java etc.

Examples: VB (pre-.NET) etc.

 

References

  1. Wegner, Peter (December 1987). Meyrowitz, Norman, ed. "Dimensions of Object-Based Language Design". OOPSLA'87 Conference Proceedings. 22 (12): 168––182. 
  2. Barbey, S; M. Kempe; A. Strohmeier (1993). "Object-Oriented Programming with Ada 9X". Draft Technical Report. Swiss Federal Institute of Technology in Lausanne Software Engineering Laboratory. Retrieved 15 December 2013. Ada 83 itself is generally not considered to be object-oriented; rather, according to the terminology of Wegner [Weg 87], it is said to be object-based, since it provides only a restricted form of inheritance and it lacks polymorphism.

翻訳 : "Object" In Wikipedia, The Free Encyclopedia

 

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

 CSにおいて、オブジェクトとは、変数、データ構造、関係、メソッドなどでありうる。値を持つメモリー内にあり、識別子で参照される。

クラスベースのオブジェクト指向プログラミングのパラダイムでは、「オブジェクト」はオブジェクトが変数、関数、データ構造の集まりでありうるクラスの特定のインスタンスを指し示す。

リレーショナルデータベースのマネジメントでは、オブジェクトはテーブルないしはカラムであったり、データと(特定の人に年齢を関連付けるような)データベースのエンティティの間の関連でありうる。

 オブジェクト・ベースの言語

プログラミング言語における重要な特徴はオブジェクト指向言語とオブジェクト・ベース言語の間の違いである。言語は通常、オブジェクト・ベースでポリモーフィズムと継承ができれば、オブジェクト指向言語と考えられる。ポリモーフィズムは、どのオブジェクトが渡されるかによって、多数の振る舞いをする関数の名前をオーバーロードする能力を指す。因習的なメッセージ渡しでは、最初のオブジェクトだけで区別して、オブジェクトに対して「メッセージを送った」と考える。しかしながら、Flavors、CLOMのようないくつかのOOP言語では、関数の最初のパラメータ以上をもとに区別できる。継承は、存在しているクラスのサブクラスとなる新しいクラスを作り、親の全てのデータ拘束と振る舞いを受け継くが、一つまたは複数のの新しいまたは(かつ)変更を追加する能力のことだ。

オブジェクト指向プログラミング

オブジェクト指向プログラミングは、モジュールを再利用できるソフトウェアシステムの設計方法である。オブジェクト指向の方法はコンピュータプログラミングの最初期にまで遡ることができる素晴らしいデザインの習慣の進化である。オブジェクト指向は構造化プログラミングや抽象データ型のようなより古い技術の単純な延長線上にある。オブジェクトはポリモーフィズムと継承が加わった抽象データ型である。

オブジェクト指向のシステムは、コードとデータとしてプログラムを構成するのではなく、「オブジェクト」の概要を使った二つを統合する。オブジェクトは状態(データ)と振る舞い(コード)を持つ。オブジェクトは現実世界のものと対応することもある。だから例えば、グラフィックプログラミングでは、円、四角形、メニューなどがオブジェクトとしてあるだろう。オンラインショッピングシステムでは、ショッピングカート、顧客、製品といったオブジェクトがあるだろう。ショッピングシステムには、注文、支払い、割引などの振る舞いがあるだろう。オブジェクトは階層的なクラスとして設計される。だからショッピングシステムの例では、電化製品、キッチン用品、本などの高水準のクラスがありうる。電化製品としてのさらに洗練された例としてCDプレイヤーやDVDプレイヤーなどがあるかもしれない。これらのクラスとサブクラスは数学の論理学における集合や部分集合と対応している。

特殊なオブジェクト

オブジェクトにとっての重要な概念はデザイン・パターンだ。デザイン・パターンとは共通する問題に対処するため再利用できるテンプレートである。以下にオブジェクトは、オブジェクトについての最も一般的なデザイン・パターンの例の一部を示す。

  • Function object: an object with a single method (in C++, this method would be the function operator, "operator()") that acts much like a function (like a C/C++ pointer to a function).
  • Immutable object: an object set up with a fixed state at creation time and which does not change afterward.
  • First-class object: an object that can be used without restriction.
  • Container object: an object that can contain other objects.
  • Factory object: an object whose purpose is to create other objects.
  • Metaobject: an object from which other objects can be created (compare with a class, which is not necessarily an object).
  • Prototype object: a specialized metaobject from which other objects can be created by copying
  • God object: an object that knows or does too much (it is an example of an anti-pattern).
  • Singleton object: an object that is the only instance of its class during the lifetime of the program.
  • Filter object.

分散オブジェクト

オブジェクト指向の方法はプログラミングモデルに限らず、分散システムのためのインタフェース記述言語としてもまた上手く使うことができる。分散コンピューティングモデルでのオブジェクトは、プログラミングオブジェクトと比べて、より大きく、より長い時間存在し、よりサービス指向の傾向にある。

分散オブジェクトをまとめる標準的な方法はIDLだ。IDLは分散サーバーオブジェクトのすべての詳細からクライアントを保護する。詳細というのは、オブジェクトがどのコンピュータにあるのか、どのプログラミング言語が使われているのか、どのOSか、他のプラットホームの固有の問題などである。IDLは、トランザクションや持続性といったサービスを同じ方法でオブジェクトに提供する分散環境の一部として通常は使われる。 Object Management GroupのCORBA と MicrosoftのDCOM が分散オブジェクトとして有名な二つである。

省略

セマンティック・ウェブ

省略

関連項目

  • Object lifetime
  • Object copy
  • Design pattern (computer science)
  • Business object (computer science)
  • Actor model

参考文献

省略

外部リンク

省略

 

 

 

翻訳 : RFC5377 -- Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents (IETFのドキュメントで付与される権利に関するIETF Trustの保管委員に対するアドバイス)

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

 

Network Working Group J. Halpern, Ed.
Request for Comments: 5377 Self
Category: Best Current Practice November 2008 

 
Advice to the Trustees of the IETF Trust
on Rights to Be Granted in IETF Documents (IETFのドキュメントで付与される権利に関するIETF Trustの保管委員に対するアドバイス

Status of This Memo(このメモの位置づけ)

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモにはインターネットコミュニティについての情報が記述されている。いかなる種類のインターネットスタンダードを規定していない。このメモの流通は無制限である。

Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

このドキュメントは、BCP 78 と 発行日に効力のあるIETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) が適用されます。これらのドキュメントには、このドキュメントに関するあなたの権利と制限が記述されているので注意深く読み直してください。

Abstract(要旨)

Contributors grant intellectual property rights to the IETF. The IETF Trust holds and manages those rights on behalf of the IETF. The Trustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts and RFCs. The Trustees of the IETF Trust accepts direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETF Contributions.
投稿者は知的財産を IETFに寄付している。IETF TrustはIETFに代わってこれらの権利を保持し管理する。IETF Trustの保管委員は管理の責任を引き受ける。この管理には、インターネットドラフトやRFCの中で、IETF Contributionsのコピー、実装、使用についてのライセンス承諾が含まれる。IETF Trustの保管委員は、IETFからの付与される権利に関する管理を受け入れる。このドキュメントには、IETF Contributionsで付与される海外への権利に関するIETFの考え方が記述される。

Table of Contents(目次)

 

1. Introduction(序説)

Under the current operational and administrative structures, IETF intellectual property rights are vested in the IETF Trust administered by a board of trustees made up of the members of the IAOC [RFC4371]. This includes the right to make use of IETF Contributions, as granted by Contributors under the rules laid out in [RFC5378]. The Trustees of the IETF Trust are therefore responsible for defining the rights to copy granted by the IETF to people who wish to make use of the material in these documents.
現在の運営並びに管理上の構造の中では、IETF知的財産権はIAOC[RFC4371]のメンバーで構成される保管委員会議によって運用されたIETF Trustに帰属する。 これには、投稿者が[RFC5378]に定められた規則の下で認めたIETFの投稿を利用する権利が含まれる。それゆえ、IETF Trustの保管委員は、これらのドキュメントの内容を利用したいと思っている人に対して、IFTFによって付与されたコピー権を定義する責任がある。

For consistency and clarity, this document uses the same terminology laid out in [RFC5378] and uses the same meanings as defined in that document.
一貫性と明快さのために、このドキュメントでは[RFC5378]で定められた同一の用語並びにこのドキュメントで定義されるような同一の意味を用いる。

The IETF Trust, by way of its Trustees, has indicated, as is consistent with the IETF structure, that it will respect the wishes of the IETF in regard to what these granted rights ought to be. It is therefore the IETF's responsibility to articulate those wishes.This document represents the wishes of the IETF regarding the rights granted to all users in regard to IETF Contributions, until it is superseded.
IETF Trustは、保管委員を通してIETFの構造が一貫しているように、どのように権利が付与されるべきかということに関するIETFの考えを尊重するだろうことを示す。それゆえ、これらの考えを明確に表現することは、IETFの責任である。このドキュメントは、取り替えられるまで、IETFの投稿についての全てのユーザーに付与される権利に関するIETFの考えを表している。

2. Purpose in Granting Rights(権利付与の目的)

In providing a description of the wishes of the IETF with regard to rights granted in RFCs, it is helpful to keep in mind the purpose of granting such rights.
RFCの権利付与に関するIETFの考えの説明を与える際に、そのような権利付与の目的に留意することは有益である。

The mission of the IETF is to produce documents that make the Internet work better (see [RFC3935] for more details). These documents, when completed, are published as RFCs.
IETFのミッションはインターネットをよりよくするドキュメントをつくることだ(詳しくは[RFC3935] を参考)。これらのドキュメントは、完成したときに、RFCとして発行される。

An important subclass of RFCs is standards describing protocols; for these, the primary value to the Internet is the ability of implementors to build solutions (products, software, etc.) that interoperate using these standards. Hence, the IETF has a strong interest in seeing accurate, interoperable implementations of the material the IETF publishes. The IETF Trust grants rights to copy to people to make use of the text in the RFCs in order to encourage accurate and interoperable implementations.
RFCの重要なサブクラスは記述しているプロトコルの標準である。このために、インターネットの基本的な価値は、これらの標準を使った総合運用性のある(プロダクト、ソフトウェアなどの)ソリューションをつくる作成者の能力である。このゆえに、IETFは発行する資料が正確で相互運用可能な実装であることを見ることに強い関心を持っている。IETF Trustは正確で相互運用可能な実装を奨励するためにRFCのテキストの利用するコピー権を付与する。

As early implementations from Internet-Drafts make use of descriptions in those Internet-Drafts, similar desires apply to Internet-Drafts.
インターネットドラフトからの初期の実装がこれらのインターネットドラフトにおける説明を利用するとき、似た要望がインターネットドラフトに適用される。

Similar considerations also apply to non-standard, non-protocol documents such as BCP (Best Current Practice) and Informational documents; in this document, we recommend a common approach to the issue of right-to-use licenses for all IETF documents.
似たような考慮事項が非標準、BCP(現時点における最善の実践)のような非プロトコルドキュメント、情報提供ドキュメントにもまた適用される。このドキュメントでは、全てのIETFドキュメントに対する使用権のライセンスの問題への共通のアプローチを推奨する。

Previous documents regarding rights in IETF documents have included in the RFC text specific text to be used to achieve the stated goals. This has proved problematic. When problems are found with such text, even when the problem is not a change in intent, it is necessary to revise the RFC to fix the problem. At best, this delays fixing legal issues that need prompt attention. As such, this document describes the IETF desires to the Trustees of the IETF Trust, but does not provide the specific legal wording to address the goals. The selection, and updating as necessary, of legal wording is left to the Trustees of the IETF Trust. Appeals of the actions of the Trustees of the IETF Trust are governed by other documents. As the Trustees are the members of the IAOC, the appeals procedure documented in BCP 101 (currently [RFC4371]) is applicable.
IETFのドキュメントにおける権利に関する以前のドキュメントはRFCのテキスト内の前述の目標を達成するために使用される特定のテキストを含む。これには問題があった。 そのようなテキストに問題が見つかった場合、問題が意図的な変更でない場合でも、問題を解決するためにRFCを改訂する必要がある。せいぜい、これは迅速な注意を必要とする法的な問題の解決を遅らせる。そういうものとして、このドキュメントはIETF Trustの管理委員会に対するIETFの要望を記述しているが、その目的を扱うための特定の法的表現を提供していない。法的表現の選択と更新は、必要に応じて、IETF Trustの管理委員会に委ねられる。IETF Trustの管理委員の行為の控訴は、他の文書によって支配されている。管理委員会はIAOCのメンバーであるため、BCP 101(現在は[RFC4371])に文書化されている上訴手続きが適用される。

3. Powers and Authority(権限)

As described in the introduction, and formally specified in [RFC5378], the legal authority for determining and granting users rights to copy material in RFCs and other IETF Contributions rests with the Trustees for the IETF Trust, which is made up of the members of the IAOC, as described in [RFC4071] and [RFC4371]. This document provides guidance to that body, based on the rough consensus of the IETF. The Trustees of the IETF Trust have the authority and responsibility to determine the exact text insertions (or other mechanisms), if any, needed in Internet-Drafts, RFCs, and all IETF Contributions to meet these goals. The IETF Trust License Policy is available from http://trustee.ietf.org/license-info.
序説にあるように、そして[RFC5378]で正式に明記されているように、RFCやほかのIETFの寄稿文にあるマテリアルのコピー権の決定と不要のための法的権限は、[RFC4071]と[RFC4371]に記述されているように、IAOCのメンバーであるIETF Trustの管理委員にある。このドキュメントはIETFのおおざっぱはコンセンサスに基づいて、主要部のガイダンスを提供する。IETF Trustの管理委員には、もし必要であれば、これらの目標を達成するためにインターネットドラフト、RFC、およびすべてのIETFの寄稿文に必要とされる、正確なテキスト(および他の仕組み)を決定する権限と責任がある。The IETF Trust License Policyは http://trustee.ietf.org/license-info から入手できる。

The rough consensus described in this document reflects the agreement of the IETF as of the IETF Last Call, and the Trustees of the IETF Trust are to begin drafting license text and other materials to act on these instructions upon IESG approval of this document for RFC publication. Changes to the IETF documentation, and document policies themselves, take effect as determined by the Trustees of the IETF Trust.
このドキュメントで説明されている大まかなコンセンサスは、IETF Last CallのようにIETFの一致を反映しており、IETF Trustの管理委員は、この文書をRFCの発行のためのこのドキュメントのIESGの承認を得た時点で、これらの指令に従うための 、認可のテキストとほかのマテリアルを、起草し始める。 IETFのドキュメントおよびドキュメントポリシー自体の変更は、IETF Trustの管理委員会が決定したとおりに発効する。

This document does not specify what rights the IETF Trust receives from others in IETF Contributions. That is left to another document ([RFC5378]). While care has been taken by the working group in developing this document, and care will be taken by the Trustees of the IETF Trust, to see that sufficient rights are granted to the IETF Trust in IETF Contributions, it is also the case that the Trust can not grant rights it has not or does not receive, and it is expected that policies will be in line with that fact. Similarly, the rights granted for pre-existing documents can not be expanded unless the holders of rights in those Contributions choose to grant expanded rights. Nonetheless, to the degree it can, and without embarking on a massive effort, it is desirable if similar rights to those described below can be granted in older RFCs.
このドキュメントでは、IETF TrustがIETFの投稿文の他からどのような権利を受け取るかについては明記していない。 それは別のドキュメント([RFC5378])に委ねている。 この文章が開発されている時にワーキンググループによって注意が払われ、IETF Trustの管理委員によって注意が払われて、十分な権利がIETF TrustとIETFの投稿文に権利が付与されることを確認するのと同時に、Trustが所有または受け取っていない権利を付与することができないという問題があり、ポリシーがその事実に沿ったものになると期待される。同様に、既存のドキュメントに付与された権利は、投稿の権利の保有者が拡大された権利を付与することを選択しない限り拡大することはできない。 それにもかかわらず、できるだけ、多くの努力を払うことなく、古いRFCで以下に述べる権利と同様の権利を付与できることが望ましい。

The IETF grants rights to copy and modify parts of IETF Contributions in order to meet the objectives described earlier. As such, different circumstances and different parts of documents may need different grants. This section contains subsections for each such different grant that is currently envisioned. Each section is intended to describe a particular usage, to describe how that usage is recognizable, and to provide guidance to the Trustees of the IETF Trust as to what rights the IETF would like to see granted in that circumstance and what limitations should be put on such granting.
IETFは、前述の目的を達成するために、IETF Contributionの一部をコピーして変更する権利を付与する。 そのようにして、ドキュメントの異なる状況および異なる部分は、異なる認可を必要とする場合がある。 このセクションには、現在想定されているそのような異なる認可に関するサブセクションが含まれてる。 各セクションは、特定の用途を記述し、その用途がどのように認識可能であるかを記述し、IETF Trustがその状況で何の権利を付与したいと考えているか、そして何の制限がそのような認可に課すべきかについてIETF Trustの管理委員会に対して手引をどのように提供するか記述することを意図している 。

These recommendations for outgoing rights are structured around the assumptions documented in [RFC5378]. Thus, this document is about granting rights derived from those granted to the IETF Trust. The recommendations below are how those granted rights should in turn be passed on to others using IETF documents in ways and for purposes that fit with the goals of the IETF. This discussion is also separate from discussion of the rights the IETF itself requires in documents to do its job, as those are not "outbound" rights. It is expected that the rights granted to the IETF will be a superset of those copying rights we wish to grant to others.
(未完成)


4.1. Rights Granted for Reproduction of RFCs(RFCの再発行のために付与される権利)

It has long been IETF policy to encourage copying of RFCs in full. This permits wide dissemination of the material, without risking loss of context or meaning. The IETF wishes to continue to permit anyone to make full copies and translations of RFCs.
(未完成)

4.2. Rights Granted for Quoting from IETF Contributions(IETFの寄稿文からの引用のために付与される権利)

There is rough consensus that it is useful to permit quoting without modification of excerpts from IETF Contributions. Such excerpts may be of any length and in any context. Translation of quotations is also to be permitted. All such quotations should be attributed properly to the IETF and the IETF Contribution from which they are taken.
(未完成)

4.3. Rights Granted for Implementing Based on IETF Contributions(IETFの寄稿文をもとにした実装のために付与される権利)

IETF Contributions often include components intended to be directly processed by a computer. Examples of these include ABNF definitions, XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values, MIBs, ASN.1, and classical programming code. These are included in IETF Contributions for clarity and precision in specification. It is clearly beneficial, when such items are included in IETF Contributions, to permit the inclusion of such code components in products that implement the Contribution. It has been pointed out that in several important contexts, use of such code requires the ability to modify the code. One common example of this is simply the need to adapt code for use in specific contexts (languages, compilers, tool systems, etc.) Such use frequently requires some changes to the text of the code from the IETF Contribution. Another example is that code included in open source products is frequently licensed to permit any and all of the code to be modified. Since we want this code included in such products, it follows that we need to permit such modification. While there has been discussion of restricting in some way the rights to make such modifications, the rough consensus of the IETF is that such restrictions are likely a bad idea, and are certainly very complex to define.
(未完成)

As such, the rough consensus is that the IETF Trust is to grant rights such that code components of IETF Contributions can be extracted, modified, and used by anyone in any way desired. To enable the broadest possible extraction, modification, and usage, the IETF Trust should avoid adding software license obligations beyond those already present in a Contribution. The granted rights to extract, modify, and use code should allow creation of derived works outside the IETF that may carry additional license obligations. As the IETF Trust can not grant rights it does not receive, the rights to extract, modify, and use code described in this paragraph can not be granted in IETF Contributions that are explicitly marked as not permitting derivative works.
(未完成)

While it is up to the Trustees of the IETF Trust to determine the best way of meeting this objective, two mechanisms are suggested here that are believed to be helpful in documenting the intended grant to readers and users of IETF Contributions.
(未完成)

Firstly, the Trustees of the IETF Trust should maintain, in a suitable, easily accessible fashion, a list of common RFC components that will be considered to be code. To start, this list should include at least the items listed above. The Trustees of the IETF Trust will add to this list as they deem suitable or as they are directed by the IETF.
(未完成)

Additionally, the Trustees of the IETF Trust should define a textual representation to be included in an IETF Contribution to indicate that a portion of the document is considered by the authors (and later, the working group, and upon approval, the IETF) to be code and thus subject to the permissions granted to use code.
(未完成)

4.4. Rights Granted for Use of Text from IETF Contributions(IETFの寄稿文からのテキストを使用するために付与される権利)

There is no consensus at this time to permit the use of text from RFCs in contexts where the right to modify the text is required. The authors of IETF Contributions may be able and willing to grant such rights independently of the rights they have granted to the IETF by making the Contribution.
(未完成)

4.5. Additional Licenses for IETF Contributions(IETFの寄稿文のための追加的なライセンス)

There have been contexts where the material in an IETF Contribution is also available under other license terms. The IETF wishes to be able to include content that is available under such licenses. It is desirable to indicate in the IETF Contribution that other licenses are available. It would be inappropriate and confusing if such additional licenses estricted the rights the IETF intends to grant in the content of RFCS.
(未完成)

However, the IETF does not wish to have IETF Contributions contain additional licenses, as that introduces a number of additional difficulties. Specifically, additional text in the document, and any additional license referred to by permitted additional text, must not in any way restrict the rights the IETF intends to grant to others for using the contents of ETF Contributions.
(未完成)
Authors of Contributions retain all rights in their Contributions. As such, an author may directly grant any rights they wish separately from what the IETF grants. However, a reader wishing to determine or make use of such grants will need to either consult external sources of information, possibly including open source code and documents, or contact the author directly.
(未完成)

5. IANA Considerations(IANAに関する考慮事項)

No values are assigned in this document, no registries are created, and there is no action assigned to the IANA by this document. One list (of kinds of code sections) is anticipated, to be created and maintained by the Trustees of the IETF Trust. It is up to the Trustees of the IETF Trust whether they create such a list and whether they choose to involve the IANA in maintaining that list.
(未完成)

6. Security Considerations(セキュリティに関する考慮事項)

This document introduces no new security considerations. It is a process document about the IETF's IPR rights being granted to other people. While there may be attacks against the integrity or effectiveness of the IETF processes, this document does not address such issues.
このドキュメントは新しいセキュリティに関する考慮事項を取り入れていない。これはほかの人に付与されているIETF知的財産権についてのプロセスのドキュメントである。IETFプロセスの完全性または有効性に対する攻撃があるかもしれないが、このドキュメントはそのような問題に扱っていない。

7. References(参考文献)

7.1. Normative References(標準の参考文献)

[RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights
Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
November 2008.

7.2. Informative References(有益な参考文献)

[RFC3935] Alvestrand, H., "A Mission Statement for the IETF",
BCP 95, RFC 3935, October 2004.

[RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF
Administrative Support Activity (IASA)", BCP 101,
RFC 4071, April 2005.

[RFC4371] Carpenter, B. and L. Lynch, "BCP 101 Update for IPR
Trust", BCP 101, RFC 4371, January 2006.

 
Author's Address

Joel M. Halpern (editor)
Self
P. O. Box 6049
Leesburg, VA 20178
US

EMail: jmh@joelhalpern.com