設計思想とは? わかりやすく解説

設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/06/06 07:50 UTC 版)

李祖原」の記事における「設計思想」の解説

軍人の子として生まれ決し裕福な家庭ではなかったが、小学5年美術目覚めた家系には美術天分があったとしている。師範大付高で自身は他の多く生徒同様、美術教師志していたが、クラス建築家目指していた1人同級生影響受けてクラスでは美術教師にも建築系の指導試験求めようになった当時台湾大学建築学部設けていたのは成功大学けだった高校での美術指導功を奏してか、同年成功大学建築学部合格した50名のうち、師大附出身者含めて5人を占めた大学では1年生から4年生まで一つ大家のような校風昼夜問わず学内アトリエデッサン明け暮れて収穫多かったという。 青年時のスイス建築家ル・コルビュジエ(1887-1965)を「建築作品芸術家として才気溢れ歴史変えた一人であり、現代建築史偉大な人物」と評し自身の手本にしていた。 台湾帰国後も「中国文化知らずして、中国人建築設計することはできない」として、『中華建築』の思考深めていく。中国代表的思想家の牟宗三入門し儒学仏学老荘思想学んで「最高の文化宗教ほかならない」という境地辿り着く中華西洋文化をぶつけあった成果物として「東王漢宮」や「大安国宅」を生み出したは「屋上部に中国古代建築屋根置いてみた」と語っている。宏国大1989年)はが「自己の中国建築意識作品反映できた」と初め自認できるものとなった作品で、儒学則った左右対称外観と、天・地・人三者の関係を物語形状で、中国建築がもつ特色を「形式化」から「概念化」へ変えることを試みたという。 一方で21世紀になってからは雑誌EGG』と国内若手建築家選定する台湾で最も醜い建築物』に作品が数件ランクインするなど、世代の違いとはいえ不名誉な評価もある。

※この「設計思想」の解説は、「李祖原」の解説の一部です。
「設計思想」を含む「李祖原」の記事については、「李祖原」の概要を参照ください。


設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/08/16 07:03 UTC 版)

Scientific Linux」の記事における「設計思想」の解説

Scientific Linux第一目的は、世界中様々な研究所大学のための一般的なLinuxディストリビューション作りかくして同じよう努力を減らすことにある。主要なゴールは、若干マイナーな追加変更を伴う形で、Red Hat Enterprise Linux全て互換性持たせることと、Linux基礎邪魔することなく、場所に応じたカスマタイズを簡単にできるようにすることである。Poseidon Linuxのような他のディストリビューションとは異なりScientific Linuxは、科学向けソフトウェア大規模なコレクション含んでいない。しかしながらそのようなソフトウェアのインストールにはよく適合するようになっている

※この「設計思想」の解説は、「Scientific Linux」の解説の一部です。
「設計思想」を含む「Scientific Linux」の記事については、「Scientific Linux」の概要を参照ください。


設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/06/04 03:18 UTC 版)

住吉の長屋」の記事における「設計思想」の解説

近畿地方京都大阪)の長屋住宅は、中庭通り庭・後庭備えることを理想とする住宅様式である。しかし敷地充分でない場合など、良好でない住環境となることも少なくない安藤自身そうした住環境長年住み続けて、生活にとって重要である通風採光日照などの確保知悉していたことから、大胆なデザインによる革新的な住宅着想された。敷地間口2間、奥行き7間で14坪しかなく、施主当初意向など到底反映されない考えた安藤は、長屋すっぱり切り取ってコンクリートの箱を入れ抽象的な芸術に近いような物にしたいと考えた安藤曰く「単純ではあるけれども実際には単純ではない、物理的にどれほど小さな空間であっても、その小宇宙のなかにかけがえのない自然があり豊かさあるよう住宅をつくりたかったのです。」と述べている。また、全体の約三分の一中庭にすることで、建ぺい率60%でも敷地いっぱい建てられる合理性もあると考えた西洋的な環境中に日本的感性持ち込むため、日本建築採用されてきた寸法採用し、7尺5寸(約2.25m)という天井の高さを決めたとされる内装材や家具などは天然素材使用、床は石材フローリング家具木材である。 批判的意見に対しては、「このあたりの小さな町屋の空間記憶、生活の歴史伝統、といった人間生活する上で切ることのできない要素をかつての建物の形や材料用いることで直接伝承するのでなく、リチャード・セラケリーの絵ではないが、徹底的に抽象化していった幾何学的な四角い箱のなかに、人々営々と住み続けていた町屋という伝統的な住まいや、自然に対す考え方そういったものをすべて一気封じ込められた」と述べている。

※この「設計思想」の解説は、「住吉の長屋」の解説の一部です。
「設計思想」を含む「住吉の長屋」の記事については、「住吉の長屋」の概要を参照ください。


設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/05/10 04:23 UTC 版)

劉培森」の記事における「設計思想」の解説

台湾最初に手がけたのが長庚医院だった。そこで室内設計携わり、そこで従来オフィス住宅とは異な医療機関独特の建築用語や空間使用あり方習得したことは、他の大型公共施設でのコンペ獲得にも生きている述べている。また国内外多数建築家建築事務所協業してきたことから、相手専門分野長所吸収し自己の知識へと昇華させてきた。フランスチームと体育館の設計担当したときは大型公共空間では避難通路を必ず設置することなどを学び実践している。国を跨いだ協業によって違う分野技術経験を学ぶことができると考えるに至ったのは、滞在したサンフランシスコチェン・カイコー陳凱歌)の作品さらば、わが愛/覇王別姫」に熱中する外国人目の当たりにしたことや、映画監督アン・リー李安)がハリウッド成功収めたこととし、劉は新し協業スタイル模索した。 「建築映画産業異なチーム互いに技術出し合うが、監督1人によって統括協調もたらされるという点でよく似ている」と述べ、劉も「華人頭脳外国人業務指揮する」というアン・リースタイル李安模式)に辿り着いた李安スタイル実践する最初機会高雄市立図書館総館だった。構造設計せんだいメディアテーク伊東豊雄組んだ日本竹中工務店フランス展示レイアウト担当チームイギリス交通計画顧問が劉のユニットメンバーとなり、そのチーム率いることで中国伝統天井構造生み出されたと語っている。

※この「設計思想」の解説は、「劉培森」の解説の一部です。
「設計思想」を含む「劉培森」の記事については、「劉培森」の概要を参照ください。


設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2020/11/17 07:03 UTC 版)

X Window Systemプロトコルとアーキテクチャ」の記事における「設計思想」の解説

Bob ScheiflerとJim Gettysは設計にあたって、Xの基本原則を以下のように定めた(Scheifler/Gettys 1996)。 実際アプリケーションでどうしても必要という場合以外は、新機能を追加するな。 システムが何でないのかを定義することは、何であるのかを定義するのと同じように重要である。あらゆるニーズ答える必要はない。むしろ、互換性維持した状態で拡張可能にしておけ。 1つでも例を挙げて一般化したほうが、全く例を挙げずに一般化するよりもマシである。 問題が完全に把握できないときは、解決策提供しないのが最善方法である。 作業10%について90%の効果しか得られないときは、単純な解法使え複雑さ可能な限り分離せよ。 ポリシーよりも機構を提供せよ。特にユーザインタフェースポリシークライアント側任せておけ。 先頭原則は、X11設計中に具体アプリケーションがそれを必要としていることを知っている場合限って新たな機能追加せよ」に修正された。X はだいたいにおいてこれらの原則に従ってきた。リファレンス実装拡張性改良視野入れて開発されており、1987年当時プロトコルとほぼ完全な互換性維持している。

※この「設計思想」の解説は、「X Window Systemプロトコルとアーキテクチャ」の解説の一部です。
「設計思想」を含む「X Window Systemプロトコルとアーキテクチャ」の記事については、「X Window Systemプロトコルとアーキテクチャ」の概要を参照ください。


設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2020/05/27 06:21 UTC 版)

新JIS配列」の記事における「設計思想」の解説

制定当たっては、高等学校教科書9教科(9冊)の延べ130文字天声人語16語)などの資料n-gramデータとして集計してから用いたまた、実在人間にとって「無理なく・すばやく操作できる入力法を設計するために、女子大学生7名を対象として延べ380文字分の「指の運動特性調査行った入力過程得た運動特性データは、配列設計選別するための打鍵速度データとして使われた。 新JIS配列日本語入力分野において、「数百万字クラス大規模n-gramデータを、数百打鍵クラス大規模運動特性データによって仮想打鍵する」ことにより、無数に存在する配列候補から「各種要求を満たす評価の高い配列」を、現実的な設計期間で選び出せ設計手法利用され先駆けでもある。 成果物による入力速度客観的に評価比較でき、かつ人間動作能力子細に渡るまで反映させることができることから、この考え方は後に設計され多くかな入力法にも受け継がれている。 コンピュータ計算能力向上するにつれて事前候補絞込みをなるべく避けて「より広い範囲候補」から配列選別することが可能となるため、さらに高い性能を持つ配列が見つかる可能性もある。しかし新JIS配列設計時点では、コンピュータ計算能力高くなかったために、無数に存在する配列候補のうち「高速入力できる大まかな条件」を満たすグループのみを初期候補として選別し、その中から計算手動評価によって配列選び出している。

※この「設計思想」の解説は、「新JIS配列」の解説の一部です。
「設計思想」を含む「新JIS配列」の記事については、「新JIS配列」の概要を参照ください。


設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/11/27 00:07 UTC 版)

JavaとC++の比較」の記事における「設計思想」の解説

C++Javaとの違いは、それら言語の歴史から辿ることができる。 C++C言語派生規格であり、手続き型プログラミング言語クラス抽象データ型)を導入し静的型付けオブジェクト指向プログラミング実現するために開発された。C言語の設計思想を維持継承しC言語利点機械語アセンブラ準ずる高速性やハードウェア操作性など)を一切損なわないようにしているため、他のオブジェクト指向言語比べてコード実行効率柔軟性重視している反面安全性犠牲になっているJava当初組み込みシステム上でネットワークコンピューティングに対応 (support) するために開発された。Java移植性があり、セキュアであり、マルチスレッド対応であり、分散であり、そしてC++よりも単純 (simple) になるように設計された。Javaの文法C/C++プログラマ馴染みすいもの選ばれたが、C/C++との直接的な互換性維持されていないC++Java開発の目的異なるため、両者方針トレードオフ違い生じている。 C++Javaネイティブコード マネージコード Cの (部分的な) 上位互換 C/C++との互換性はない プログラマ信頼する プログラマを守る ハードウェアに近い低レベル下位レベル機能操作できる メモリ抽象化した型やオブジェクト通してのみアクセス可能 簡潔な表現 明確な表現 明示的な破壊許可安全性 マルチパラダイム手続き型オブジェクト指向総称型関数型オブジェクト指向総称型関数型 演算子多重定義 演算子効果不変 限られた範囲標準ライブラリGUIネットワークマルチスレッドを含む)機能豊富で容易に使用できる標準ライブラリ 組み込みパーソナルコンピュータワークステーション 業務システムWebフロントエンドWebバックエンド)、携帯端末 C言語とC++相互運用性確保されており、C++からCのライブラリ関数群)を直接利用することが可能になっている。なお、2018年現在C/C++最新規格それぞれC11およびC++17だが、双方に独自の追加仕様重ねられており、C言語対する完全な上位互換性なくなっている。ただし、互い差異埋めて互換性向上するための機能追加なされている。 また、JavaC/C++との互換性はないが、ScalaKotlinGroovyといった後発Java仮想マシン (JVM) ベースABI互換言語との間で相互運用可能になっている。

※この「設計思想」の解説は、「JavaとC++の比較」の解説の一部です。
「設計思想」を含む「JavaとC++の比較」の記事については、「JavaとC++の比較」の概要を参照ください。


設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/03/26 14:54 UTC 版)

ホンダ・NSX」の記事における「設計思想」の解説

外見の特徴であるリアオーバーハングの長さ理由二つあり、ひとつはマフラーエンジンルームから遠ざけルーム内の温度上昇防ぎエンジン補機類の寿命延長すること、もうひとつ空力性能の向上による高速走行時姿勢安定性の向上のためである。副次的作用として、ゴルフバッグ搭載可能なトランク用意されスペシャリティーカーとしても高い実用性有している。 当時スーパースポーツ多く車中心の考え方設計されており、運転姿勢や快適装備などドライバー負担を強いる部分多数あったのに対し本車ではそれを考慮してドライバー中心スポーツカーとすることを目標とした。 たとえばスタイリング上の特徴に、F-16戦闘機キャノピーモチーフとしたフロントウインドウがあり、従来スーパーカー比較して運転席からの視界良好である。実際に運転席からの平方向の視界は311.8度ある。

※この「設計思想」の解説は、「ホンダ・NSX」の解説の一部です。
「設計思想」を含む「ホンダ・NSX」の記事については、「ホンダ・NSX」の概要を参照ください。


設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/03/26 23:32 UTC 版)

Clojure」の記事における「設計思想」の解説

リッチ・ヒッキー (Rich Hickey)がClojure言語設計した目的は、既存Javaプラットフォーム上で動作して並行コンピューティングができる、関数型LISP系の言語作ることである。 Clojure言語並行コンピューティング実現する手法は、不変(イミュータブル)な状態の連鎖という概念によって特徴づけられる。状態が不変であるため、ひとつの状態に対して複数操作並列に行うことができ、並列性という問題が「状態遷移管理」になる。そのため、Clojure言語には、状態遷移に関して明確な定義をもつ可変参照型いくつか用意されている。

※この「設計思想」の解説は、「Clojure」の解説の一部です。
「設計思想」を含む「Clojure」の記事については、「Clojure」の概要を参照ください。


設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/02/08 17:17 UTC 版)

ライトニングネットワーク」の記事における「設計思想」の解説

ペイメントチャネルは、その参加者ブロックチェーントランザクション公開することなく相互に資金送り合うことを可能にする。これは協調性欠け参加者罰することにより実現されるチャネル開いたとき、参加者ファンディング(入金)をしなくてはならない(ブロックチェーン上のファンディングトランザクション)。CheckSequenceVerify や CheckLockTimeVerify などのタイムベース拡張スクリプトがこの懲罰を可能としている。 ビットコインブロックチェーン上にある分大きなチャネルネットワークがあること、およびビットコイン利用者達が少なくも一つ開かれたチャネルを持つことによってこのグラフ参加していることを前提とすると、無限に近い額のトランザクション内部作成可能であろうビットコインブロックチェーン上に早期送信されトランザクションだけが、非協力的チャネル相手方である。 ライトニングペーパーより Bitcoin Improvement Proposals(英語版)のCheckSequenceVerify(CSV) が、CSVライトニング用いたハッシュタイムロックコントラクトに詳しい。

※この「設計思想」の解説は、「ライトニングネットワーク」の解説の一部です。
「設計思想」を含む「ライトニングネットワーク」の記事については、「ライトニングネットワーク」の概要を参照ください。


設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/04/03 05:59 UTC 版)

ザハ・ハディッド」の記事における「設計思想」の解説

彼女は、ロシア構成主義建築美術の強い影響を受け、コンセプチュアル空想的なものを現実空間出現させ、見学・利用者に驚き与えている。かつては同じく脱構築主義者であるダニエル・リベスキンド同様に実際建築作品ではなく建築思想の提唱者として、また過激なコンセプト示した図面製作者としてもっぱら知られていた。 無数の道路パイプのようなラインゆるやかに折れ曲がり交差し重なり合いながら高速流れイメージや、近未来的で巨大な有機体状の構造物などを描いたドローイング特徴とする。 彼女のプロジェクト担当した経験を持つ金田充弘2012年当時アラップ東京事務所在籍していた構造エンジニア)によると、「形へのこだわりもとより建築ファサード融合が非常に大切」としているという。 一方でロンドンにある事務所2015年7月現在)は古風なレンガ造り外観となっている。東京千代田区)にも事務所を持つ(2015年7月現在)。

※この「設計思想」の解説は、「ザハ・ハディッド」の解説の一部です。
「設計思想」を含む「ザハ・ハディッド」の記事については、「ザハ・ハディッド」の概要を参照ください。


設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/11/09 10:19 UTC 版)

姚仁喜」の記事における「設計思想」の解説

姚は1つ物件でも業者ストーリー所有者ストーリー思想があると考えており、建築に「カメラレンズ(を通した視点)」と「(街の)ストーリー性」を反映している。 長年友人であるTVプロデューサー王偉忠(中国語版)は上海で姚の建築展に参観し「姚は建築一つ舞台考えている」との印象受けた述べている。かつてはニューヨークフィルムアカデミー短期間だが映画学んでいた。 建築家ではない兄弟建築設計学んでいたが、幼少時両親が自由発想許容していたからだと述べている。重病患い週に1度しか登校できなかったときも、担任教師は姚に叱責懲罰をしなかったといい、束縛なく育ったことが人生影響与えた述べている。自宅療養中は辞典から漫画まで幅広く読書耽った高校時美術興味をもち、画廊通っていたが、進学先東海大学には美術学科がなく建築学科選択した当時厳格な校風国立台湾師範大学にしか美術学科がなく、自分には合わない諦めている。 姚は自身頻繁な海外渡航使っている台湾桃園国際空港が好きではなかった。駅や空港建築流動性優先し刹那的な感覚囚われるためとしている。高鉄彰化駅設計受けた際は、駅では一般的なのない開放感とは逆に多用したデザイン取り入れた当地名産である花卉意識し駅舎温室に、内部を花やサトイモ見立てた後年烏鎮戯劇節(中国語版)を「東洋アヴィニョン演劇祭」とすべく戯劇節発起人務めた台湾演出家頼声川烏鎮劇場こけら落とし公演のために友人だった姚に設計オファーした。姚は頼の代表作品「如夢之夢(中国語版)」と烏鎮18、19世紀情景思い浮かべながらデザインしたという。 台北聯合報建て替えで姚の設計による聯合・大於へと生まれ変わったが、姚は初めて社を訪問した際に地下室印刷工場印象残ったため、活版印刷活字着想得てビル外観デザイン応用した

※この「設計思想」の解説は、「姚仁喜」の解説の一部です。
「設計思想」を含む「姚仁喜」の記事については、「姚仁喜」の概要を参照ください。


設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/02/21 08:11 UTC 版)

CANO-AID」の記事における「設計思想」の解説

ユーザインターフェースである画面帳票データベースファイル関わる入出力は、ある決まった処理手続き踏んでいる。従って個々ロジックプログラマコーティングするではなくコンピュータシステムによってソースコード自動生成することが可能である。自動生成のためには、事前にデータディクショナリ中心としたリポジトリに、その入出力関わる設計情報事前に登録をして置く。自動生成の際には、その設計情報から、その入出力適合したソースコード自動生成することになる。また、業務アプリケーションは、オンライン場合データベースメンテナンスする、問い合わせるバッチ場合は、マッチングする、サマリする、データ編集する帳票出力するといった機能分類することができる。このようなものをパターンとして部品化しておき、その部品自動的に組み合わせることによって動作するプログラム自動生成することが、可能になるといった基本的な考え方が、CANO-AIDの設計思想である。

※この「設計思想」の解説は、「CANO-AID」の解説の一部です。
「設計思想」を含む「CANO-AID」の記事については、「CANO-AID」の概要を参照ください。


設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/08/08 03:45 UTC 版)

X Window System」の記事における「設計思想」の解説

1984年Bob ScheiflerとJim GettysはXの基本原則を以下のように定めた実際アプリケーションでどうしても必要という場合以外は、新機能を追加するな。 機構が何でないのかを定義することは、何であるのかを定義するのと同じように重要である。あらゆる要求答える必要はない。むしろ、互換性維持した状態で拡張可能にしておけ。 1つでも例を挙げて一般化したほうが、全く例を挙げずに一般化するよりもマシである。 問題が完全に把握できないときは、解決策提供しないのが最善方法である。 10%作業望み90%の効果得られるときには、その解法使え複雑さ可能な限り分離せよ。 方針よりも機構を提供せよ。特にユーザインタフェースについての方針クライアント側任せておけ。 先頭原則は、X11設計時に具体アプリケーションがそれを必要としていることを知っている場合限って新たな機能追加せよ」に修正された。 Xはだいたいにおいてこれらの原則に従ってきた。参考実装拡張性改良視野入れて開発されており、1987年当時プロトコルとほぼ完全な互換性維持している。

※この「設計思想」の解説は、「X Window System」の解説の一部です。
「設計思想」を含む「X Window System」の記事については、「X Window System」の概要を参照ください。


設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/06/11 02:27 UTC 版)

Ruby」の記事における「設計思想」の解説

開発者まつもとゆきひろは、「Ruby言語仕様策定において最も重視しているのはストレスなくプログラミングを楽しむことである (enjoy programming)」と述べている。 Ruby には PerlPython とは決定的に違う点があり、それこそRuby存在価値なのです。それは「楽しさ」です。私の知る限りRuby ほど「楽しさ」について焦点当てている言語は他にありません。Ruby純粋に楽しみのために設計され言語作る人、使う人、学ぶ人すべてが楽しめることを目的としています。しかし、ただ単に楽しいだけではありません。Ruby実用性も十分です。実用性なければ楽しめないではありませんか。 — まつもとゆきひろRuby プログラミング入門 まえがき 監修者よりのページ ただし、まつもとによる明文化され言語仕様存在しないPerlモットーやり方はいろいろある (There's More Than One Way To Do It; TMTOWTDI)」は「多様性は善 (Diversity is Good)」というスローガンRuby引き継がれてはいるものの最重要なものではないとも述べており、非推奨手法可能にするとともにそのような手法言語仕様により使いにくくすることによって自粛促している。 また、まつもとは『まつもとゆきひろ コード世界 スーパー・プログラマになる14思考法』でもRuby開発理由次のように述べている。 「なぜRuby開発したのか」。そのように問われるときに、もっとも適切な答えは、Linux開発者であるリーナス・トーバルズ言葉と同じではないか思います。『それがぼくには楽しかったから』 — まつもとゆきひろまつもとゆきひろ コード世界 スーパー・プログラマになる14思考法 P.9 また、英語圏開発者の間ではMINASWAN (Matz is nice and so we are nice. 和訳: まつもとナイスだから我々もナイスであろう) の標語用いられている。 「PythonPHPPerlでは静的型導入しているため、Rubyも型を導入するべきでは」と長年言われているが、まつもとは「Rubyに型を取り入れたくない。DRY (Don't repeat yourself)ではないから⁠」⁠「⁠型宣言することはコンピュータ使われているような気になる」と否定的であり、2019年5月現在Ruby静的型導入される予定はない。 クラス名アルファベット大文字から始めるという制約があり、日本語などの非ASCII文字のみでクラス名定義する方法がない。この件についてまつもとは以下のように語っており、英語を共通言語として使うべきであるという立場表明している。 2文字以降自由なので、もしどうして日本語使いたいであれば少々不自然に見えますが、先頭だけ大文字接頭辞をつけるのはどうでしょうか。しかし、私個人としては、日本語変数名などを使うことは、そのプログラムを読む人の範囲日本語読める人に限定してしまうことになるので、ひどくもったいないのではないか感じてます。そこで、この点を積極的に改善する気にはなれないのです。

※この「設計思想」の解説は、「Ruby」の解説の一部です。
「設計思想」を含む「Ruby」の記事については、「Ruby」の概要を参照ください。


設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/06/16 03:45 UTC 版)

ドラゴンクエストシリーズ」の記事における「設計思想」の解説

第1作製作時、初めRPG触れユーザーに対してユーザー参考材料にするであろう海外RPGハードルが高すぎるという判断から、堀井自ら『ファミコン神拳』でRPGというゲームの説明をするなど、間口広げる方針取った。これはシリーズ全体方針ともなり実際に第1作から『III』までの通称ロト三部作」は、ファミコン初めRPG触れユーザーに対してRPG面白さ奥深さ理解してもらえるように、実際にプレイしながらRPGリテラシー習得できるように意識して作られている。 ロトシリーズ以降この方針は貫かれ、『IV製作後には今更方針変えるともないだろうと判断したこと、万人向け作っているため、難しすぎる謎は全部ボツにしていることを表明している。『X』でオンライン化が決まった際にも「いかに敷居低くするか」が最初のテーマになっている

※この「設計思想」の解説は、「ドラゴンクエストシリーズ」の解説の一部です。
「設計思想」を含む「ドラゴンクエストシリーズ」の記事については、「ドラゴンクエストシリーズ」の概要を参照ください。


設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/12/27 00:54 UTC 版)

World 1-1」の記事における「設計思想」の解説

第三世代ビデオゲームでは、ゲームの仕組みに関するチュートリアルはまれであり、代わりにプレイヤーはそのステージデザインによって新しビデオゲーム適応していた。『メトロイド』、『ゼルダの伝説』、『スーパーマリオブラザーズ』などのファミコンゲームの最初ステージは、プレイヤーゲームの仕組み学びながら進められるように設計されている。スーパーマリオブラザーズは、マリオ主人公としての初の横スクロールゲームであり、宮本茂デザインした最初ゲームのひとつでもある。スーパーマリオブラザーズの第1ステージでは、プレイヤー無差別に障害物突きつけるではなくステージ進めながらプレイヤー接するように導くことで、さまざまな危険やオブジェクト紹介している。 宮本は、プレイヤーが「自分のしていることを徐々に自然に理解する」ために必要なすべてのものを含み、より自由にプレイできるようにして、「自分ゲーム」になるようにWorld 1-1デザインした説明している。

※この「設計思想」の解説は、「World 1-1」の解説の一部です。
「設計思想」を含む「World 1-1」の記事については、「World 1-1」の概要を参照ください。


設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2020/10/15 08:21 UTC 版)

大塚泰子」の記事における「設計思想」の解説

人の心の動きこそが、豊かな精神性育むものであり、建築空間感動生むような「しかけ」や、経験の場所を作ることが役目だと考え建築通じ感動癒し喜び哀愁などの人間の心の動き呼び起こすものを創ることを目指している。自然と建築の関係をどう取り入れ、どう遮断するかを常に意識し両者接点をいかにデザインして、人の心を動かす「しかけ」をどのように創るかという点を最も重視している課題だと考えている。

※この「設計思想」の解説は、「大塚泰子」の解説の一部です。
「設計思想」を含む「大塚泰子」の記事については、「大塚泰子」の概要を参照ください。


設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/10/09 05:10 UTC 版)

タンデム翼機」の記事における「設計思想」の解説

かつては以下のようなメリットがあると考えられた。 大きな翼面積確保できる。つまり翼面荷重小さく抑えられるエンジンが重い上に非力で、なおかつプロペラ効率も悪い場合その方都合が良い)。 合計翼面積が同じ単葉機比べると、一枚あたりの翼を小さく(つまり強く)できる。 前後両方大きな固定翼面があるため、ピッチ(縦ゆれ)方向安定性自然と良くなる。 しかし実際には、 前の翼が気流を乱すため後の翼の効率落ち翼面積割には揚力得られない上に、前の翼の乱流により後ろの翼がゆすられ不安定なダッチロールが起こることがある。(近年タンデム翼機は、この気流乱れ避けるため、前後翼の縦方向取り付け位置が、同列になっていないのが普通である)。 大きな翼面積得たければ、主翼複葉(や三葉にすれば良い。また複葉の翼は構造によって強くできる。 ピッチ方向の安定性(と操縦性)を得るには尾翼もしくは先尾翼充分である。

※この「設計思想」の解説は、「タンデム翼機」の解説の一部です。
「設計思想」を含む「タンデム翼機」の記事については、「タンデム翼機」の概要を参照ください。


設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2017/12/26 17:07 UTC 版)

Axiom (数式処理システム)」の記事における「設計思想」の解説

Axiom においてはオブジェクトはすべて型を持っている。型は数学的な構造」であり、例えば環、体、多項式などがある。またデータ構造リスト構造木構造ハッシュテーブルなど、計算機科学のものが実装されている。 関数引数として型そのものを取ることができ、型はその返り値にもできる。たとえば Fraction という関数引数として IntegralDomain取り、その引数分数からなる体を返すまた、有理数からなる大きさ 4 × 4行列のなす環は SquareMatrix(4, Fraction Integer) によって生成できる。その環での演算を行う場合、1 は単位行列、A^-1 は A の逆行列 (存在する場合) であると解釈される複数演算が同じ名前を持つことができ、それらはオブジェクト指向プログラミング場合と同様、引数求められる結果の型によって区別されるAxiom拡張言語として SPAD呼ばれるものがある。Axiom実装されている数学的な知識はすべて SPAD書かれているAxiom対話的実行環境は、SPAD概ね全て理解するSPAD はかつて A#、続いて Aldor という名前で開発されていた。後者は現在も、SPAD代わりに Axiom から使うことができる。しかし Axiom とは異なライセンス公開されている。

※この「設計思想」の解説は、「Axiom (数式処理システム)」の解説の一部です。
「設計思想」を含む「Axiom (数式処理システム)」の記事については、「Axiom (数式処理システム)」の概要を参照ください。


設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/08/15 02:47 UTC 版)

Scribes」の記事における「設計思想」の解説

仕事の流れ阻害最小限にすること、おもしろみのない作業自動化すること、不要な設定変更をなくすこと、シンプルさ基づいた理性的な編集作業達成することを目標にしている。この目標達成するために必要のない慣習守っていない。

※この「設計思想」の解説は、「Scribes」の解説の一部です。
「設計思想」を含む「Scribes」の記事については、「Scribes」の概要を参照ください。


設計思想

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/06/12 23:00 UTC 版)

長岡安平」の記事における「設計思想」の解説

公園内植え樹木植物についてはその土地適した自然木」でなければならない、人の眼を楽しませる花弁花樹を必要とする、とした。地域の自然特色生かす設計手法努めた。また公園内園路主要なものは3〜6間(5.45-10.91メートル)、細園路1間(約1.82メートル内外幅員もたせること、坂道設計する際は、かりに勾配緩くて同一勾配60間(1090.8メートル)以上続てはならないので約30間(約545.4メートル毎に2〜3間(3.64-5.45メートル)以上の平地若しくは緩勾配地を置くこと、を述べている。さらに公園設備については運動器具をとりいれること、また外柵堅固にすることを強調している。また公園設計には経営方針最初から考えるべきであるとした。材料では、特に石は安価な相豆石を好んだ

※この「設計思想」の解説は、「長岡安平」の解説の一部です。
「設計思想」を含む「長岡安平」の記事については、「長岡安平」の概要を参照ください。

ウィキペディア小見出し辞書の「設計思想」の項目はプログラムで機械的に意味や本文を生成しているため、不適切な項目が含まれていることもあります。ご了承くださいませ。 お問い合わせ

「設計思想」の例文・使い方・用例・文例

Weblio日本語例文用例辞書はプログラムで機械的に例文を生成しているため、不適切な項目が含まれていることもあります。ご了承くださいませ。


英和和英テキスト翻訳>> Weblio翻訳
英語⇒日本語日本語⇒英語
  

辞書ショートカット

すべての辞書の索引

「設計思想」の関連用語

設計思想のお隣キーワード
検索ランキング

   

英語⇒日本語
日本語⇒英語
   



設計思想のページの著作権
Weblio 辞書 情報提供元は 参加元一覧 にて確認できます。

   
ウィキペディアウィキペディア
Text is available under GNU Free Documentation License (GFDL).
Weblio辞書に掲載されている「ウィキペディア小見出し辞書」の記事は、Wikipediaの李祖原 (改訂履歴)、Scientific Linux (改訂履歴)、住吉の長屋 (改訂履歴)、劉培森 (改訂履歴)、X Window Systemプロトコルとアーキテクチャ (改訂履歴)、新JIS配列 (改訂履歴)、JavaとC++の比較 (改訂履歴)、ホンダ・NSX (改訂履歴)、Clojure (改訂履歴)、ライトニングネットワーク (改訂履歴)、ザハ・ハディッド (改訂履歴)、姚仁喜 (改訂履歴)、CANO-AID (改訂履歴)、X Window System (改訂履歴)、Ruby (改訂履歴)、ドラゴンクエストシリーズ (改訂履歴)、World 1-1 (改訂履歴)、大塚泰子 (改訂履歴)、タンデム翼機 (改訂履歴)、Axiom (数式処理システム) (改訂履歴)、Scribes (改訂履歴)、長岡安平 (改訂履歴)の記事を複製、再配布したものにあたり、GNU Free Documentation Licenseというライセンスの下で提供されています。
Tanaka Corpusのコンテンツは、特に明示されている場合を除いて、次のライセンスに従います:
 Creative Commons Attribution (CC-BY) 2.0 France.
この対訳データはCreative Commons Attribution 3.0 Unportedでライセンスされています。
浜島書店 Catch a Wave
Copyright © 1995-2024 Hamajima Shoten, Publishers. All rights reserved.
株式会社ベネッセコーポレーション株式会社ベネッセコーポレーション
Copyright © Benesse Holdings, Inc. All rights reserved.
研究社研究社
Copyright (c) 1995-2024 Kenkyusha Co., Ltd. All rights reserved.
日本語WordNet日本語WordNet
日本語ワードネット1.1版 (C) 情報通信研究機構, 2009-2010 License All rights reserved.
WordNet 3.0 Copyright 2006 by Princeton University. All rights reserved. License
日外アソシエーツ株式会社日外アソシエーツ株式会社
Copyright (C) 1994- Nichigai Associates, Inc., All rights reserved.
「斎藤和英大辞典」斎藤秀三郎著、日外アソシエーツ辞書編集部編
EDRDGEDRDG
This page uses the JMdict dictionary files. These files are the property of the Electronic Dictionary Research and Development Group, and are used in conformance with the Group's licence.

©2024 GRAS Group, Inc.RSS