独断的なソフトウェアとは何ですか？

Question

特定のソフトウェアは「非常に意見が多い」と言っている人をよく見ます。または、マイクロソフトが「意見のない」と書く傾向があることフレームワーク。これは実際にはどういう意味ですか？

Answer 1

フレームワークに意見がある場合、フレームワークをロックするか、物事のやり方を案内します。

たとえば、一部の人々は、テンプレートシステムはユーザー定義のメソッドや関数へのアクセスを提供すべきではないと考えています。それは、システムが生のHTMLを返すためにオープンのままになるためです。したがって、意見のあるフレームワーク開発者はデータ構造へのアクセスのみを許可します。設計上、ソフトウェアは制限されており、設計者が自分のやり方で物事を行うことを奨励しています。

別の例（信号リンクから取得）は wiki 。ウィキの設計者は多くの意見を持っていました。彼らはHTMLが複雑すぎて書くことができないと考えていたので、コンテンツを更新するより自然な方法だと思ったものを思いつきました。彼らはまた、デザインよりもコンテンツに重点を置くべきだと考えたため、派手なデザインを削除しました。

Appleは製品を設計する際に強い意見を持っています。

未意見のソフトウェア設計 は、PERL / PHPに似ています。これにより、開発者は開発者が適切な決定を下せるようになり、開発者が自分の手でコントロールできるようになります。

また、マイクロソフトを非意見のコラムに入れます。意見が分かれていないMicrosoftフレームワークの良い例： .NET 。 CLRと仕様を開くことで、あらゆる種類の言語と実装スタイルに対応しました。

Answer 2

オピニオン化されたソフトウェアは、基本的に1つの方法（正しい方法＆＃8482;）があることを意味します。一方、正しい方法で物事を行う＆＃8482;あなたがしなければならない決定の数が減り、ソフトウェア設計者がソフトウェアを機能させることに集中する能力が増すので、ソフトウェアでの開発を非常に簡単にすることができます。問題が解決策にうまくマッピングされている場合、優れたソフトウェアを使用するのは素晴らしいことです。提供されているツールにマッピングされない問題の部分を解決するのは、本当に苦痛です。ここでの例は、Ruby on Railsです。

一方、非意見のソフトウェアは、ユーザー（開発者）に多くの柔軟性を与えます。問題を解決する1つの方法を禁止していませんが、さまざまな方法で問題を解決するために使用できる柔軟なツールを提供します。この欠点は、ツールが非常に柔軟であるため、ソリューションの開発が比較的困難になる可能性があることです。フレームワークでは十分なヘルプが提供されないため、ユーザー（開発者）がさらに多くのソリューションを手作業でコーディングする必要があります。また、ソリューションを提供する方法についてより多くのことを考える必要があり、平凡な開発者は、何らかの意見のあるソフトウェアを購入した場合よりも貧弱なソリューションになる可能性があります。 PERLはおそらく、非意見のソフトウェアの典型的な例です。

私の理想は、非意見のフレームワークですが、強力な慣習があるものです。 ASP.NET MVCをこのカテゴリに入れます。現実には、すべてのソフトウェアがある程度意見を述べられています（おそらくPERLではありません）。 MVCには、モデルの選択に強力な規則がありますが、それらの規則内の問題を解決するためのさまざまな方法が用意されています。それらの方法のいくつかは、モデルを壊すことさえあります。ただし、このようなフレームワークで開発している規則に従って正しく使用すると、本当に嬉しいです。

Answer 3

それは基本的に、誰もが喜ぶことを試みるのではなく、作者がそれが機能するはずだと考える方法で機能するソフトウェアです。つまり、多くの人は気に入らないが、気に入る人はそれを気に入ることになる。

Railsは、おそらく意見のあるフレームワークの標準的な例です。あなたは自分のやり方で物事を行い、すべてがスムーズです。そうでない場合、あなたはいくつかの痛みに直面しています。しかし、それは大丈夫です-自分のやり方でやりたくない場合は、Railsを使用したくありません。

Answer 4

バランスをとるために、（他の回答のいくつかとは対照的に）意見に基づいたアプローチにより有利な（むしろ意見に基づいた）説明を提供します。

オピニオン化されたフレームワークは、「黄金の道」を提供します。これは、ほとんどの人とほとんどのシナリオ（著者の目には）のベストプラクティスであると考えられています。

ただし、これは必ずしもロックインを意味するわけではありません。これは、物事を異なる方法で実行するために追加の努力が必要になる場合があることを意味します。

あまり考えられないフレームワークは、多くの異なるオプションを提供し、決定するのはあなた次第です。

オピニオン化されたフレームワークは、通常、開発者の負担を取り除き、車輪を再発明したり、同じ問題を何度も再考したりして、実際の問題に焦点を当てるのに役立ちます。

オープンソースの世界では、多くの意見が一致するが競合するフレームワークを見つけることができるため、選択肢はまだあります。独自のゴールデンパスを選択する必要があります。

Answer 5

オピニオン化されたソフトウェアは、特定の方法で物事を簡単に行えるように構築および設計されています。他のデザインパターンよりも特定のデザインパターンを優先します。その過程で、それが開発されたソフトウェア開発のスタイルから逸脱することを困難にします。別の言い方をすれば、「構成よりも慣習」を優先することです。つまり、ソフトウェアが多くの構成面を想定しているため、構成オプションは非常に限られています。前提条件が理解されると、意見のあるソフトウェアは通常、より早く習得できます。

一方、未熟なソフトウェアはほとんど仮定をしません。その結果、未開発のソフトウェア/ソフトウェア開発フレームワークには、多くの構成オプションがある傾向があります。開発者は通常、ソフトウェアのさまざまな側面に関して多くの決定を行う必要があります。多くの場合、これらの膨大なオプションを簡単に処理できるように、さまざまなツールが開発されています。例えばVisual Studio .NET for .NET、Eclipse IDE for Javaなど。未熟なソフトウェアは、一般に、意見を述べるソフトウェアよりもマスタリングに時間がかかります。

Answer 6

tl; dr ：

• オピニオン：例 Ruby on Rails 。物事を行うには特に好ましい方法が1つあり、その方法で物事を行う際に多くのサポートが得られます。他の方法で物事を行うのは難しいか、一部のシステムでは不可能です（Cassandraが思い浮かびます）。
• 未意見：例 Perl 5 。好きな方法、好きな方法、スタイルでできます。すべてのスタイルは等しくオープンで、有効であり、サポートされています。

Answer 7

多くの人がASP.NET MVCを「未ピニオン化」と呼んでいます。フレームワーク、そして私はそれについてのいくつかの考えを検討したいと思いました。

ASP.NET MVCがそれほど義務付けられていないのは事実です。 Linq-to-SQL、ADO.NETエンティティ、NHibernateなど、任意の永続化ソリューションを使用できます。

反対に、MVCフレームワークは、「構成よりも慣習」を好む傾向があり、Phil Haackを引用しています。これは、コントローラー、ビュー、モデル、その他のコードを見つけるための事前定義パターンに従うことを強く示唆しています。この動作は変更できますが、現在の状態で泳ぐのは簡単です。ほとんどの人にとっては、問題なく実行できます。

また、ASP.NET MVCを取り巻く多くの人々が意見を述べています。ユニットテストと依存性注入。私はすべて良いテストと懸念の分離を求めていますが、そのようなトピックは少しのめり込んでいると思います。

ここでも、これらの領域内で、フレームワーク自体が、必要なユニットテストソリューション、および使用する依存性注入およびモックフレームワークの採用に対して完全にオープンであることを認めなければなりません。 「バイブルバッシング」内であっても、柔軟性の別の例。行われていると思われる単体テストなど。

Answer 8

フレームワークに実装されている規則の量と、行われた決定の数です。

たとえば、フォームデータをコントローラーアクションに送信する方法が5つ（またはそれ以上）ある場合（ASP.NET MVCの場合）、フレームワークはかなり「未評価」のようです。 -決定はあなた次第です！

ただし、フレームワークが（他の方法を直接無効にするか、強く奨励することにより）そのことを行う方法を1つだけ可能にする場合（Fubu MVCの場合）、決定が下されたと言うことができますフレームワークによって、フレームワークが意見を述べるようにします。

Answer 9

現在よく見られる例は、ASP.NET MVCフレームワークです。それは驚くほど拡張性がありますが、それはいくつかの点でその没落であり、それに肉はありません。データアクセスを行いたいですか？それを自分で書く必要があります。 AJAXを続けたいですか？同上。

ただし、拡張性が高いので、それを基に構築すれば、意見のあるフレームワークに変えることができます。これは、 MVCContrib のようなものです。より少ないコードを記述します。

これは、意見から脱却したい場合、バニラ版で作業している場合よりも多くの作業が必要になることを意味します。ただし、これは80/20シナリオです。自分の意見に基づいたフレームワークを正しく選択した場合、20％の確率で意見を中断したいだけで、残りの80％の生産性は高くなります。