読み取り専用モードでコメントを書くことは許可されていないため、再度サンドボックスに書き込むリスクがあります。
エントリー
ハブラを読んで、私はコメントの 1つにつまずいた。 むしろ、このコメントの引用につまずいた：
「OOPは方法論的に間違っていると確信しています。 彼女はクラスを構築することから始めます。 数学者が公理から始めるかのようです。 しかし、公理で始まる人は誰もいません。誰もが証拠から始めます。 適切な証拠のセットが見つかった場合にのみ、これに基づいて公理が導き出されます。 つまり 数学では公理になります。
プログラミングについても同じことです。最初にアルゴリズムの開発を開始する必要があり、この作業の最後になって初めて、明確で一貫性のあるインターフェイスを作成できるようになります。 リファクタリングが非常に人気があるのは、OOPのこの混乱のためです。パラダイムの劣等のため、プログラムをOOPスタイルで設計することに決めたまさにその瞬間に、あなたは単にプログラムを書き換える運命にあります。
（c）Alexander Stepanov、C ++の共著者、STLの著者
この記事の本質（または、むしろ、Stepanovの引用された引用の分析）に進む前に、挑発的な発表（「哲学は詐欺師の数学」）を含む短い記事を思い出したいと思います。 （それ自体はすでに奇妙です;そのような雑誌では何かに注意を払うことはまれです）。 電子版はこちらです。 次に、この記事の用語を参照しますので、よく理解することをお勧めします。
手を見て
引用文をオラトリオの観点から評価してください。 しかし、美しい！ 彼らが言うように、あなたの手を見てください。 予想外の大きな声明で始まるため、すぐに注目を集めます。 次に、スピーカーはリスナー（リーダー）に、OOPのクラスと数学の公理との類似性を伝えます。 この類推は、最終的なコードの基礎としてさらに機能します：「あなたは単に運命にある...」！ 拍手。 カーテン。 敵は倒されます。
正直なところ、Stepanovが説明しているように、このような正統派のバージョンでOOPを使用することは、どういうわけか私には決して起こりませんでした。 私の理解では、OOPは非常に便利なツールの1つにすぎません。 OOP（パラダイム）は非常に食用で（おいしい）、デフォルトのソースはありません。デフォルトのソースには、すべてがオブジェクトであるという重要な考えが必ず含まれています。 必要に応じてOOPを使用しても、OOPの魅力は失われません。包括的な主要なアイデアの枠組み内だけではありません。 はい、OOPの概念では、オブジェクトのみを広く使用する必要はないようです。 この非常に重要なアイデアを再定式化し、たとえば「すべてがオブジェクトである」オプションから「すべてをオブジェクトとして表すことができる」オプションに切り替えることをお勧めします。 表示される場合もありますが、実行する必要はありません！ そして、必ずしもすべてが悪いわけではありません。
引用の基礎は、一方では数学の証明と公理、もう一方ではオブジェクトのアルゴリズムとインターフェイスの類似性です。 この類似性はどの程度実証されていますか？ 財団の予想のように聞こえますか？
公理、私が何も混同しない場合、証拠なしで真と認められる最初の声明があり、それ自体が他の証拠を構築するための基礎として機能します意味）。 はい、はい、私の記憶の隅のどこかに、かつて単なる公理と考えられていた多くの声明が最終的に証拠を見つけたという考えがあります。 しかし、これは数学者の思考の流れが常に証拠から公理に行くと言う理由ではありません。 正式には、何らかの理由で公理は定理に含まれ、定理は常に証明されますが、これは公理が常に適切な証明に基づいて導出されると主張する理由でもありません。 FALSE SYLLOGISMのように聞こえますか？
また、引用文では、インターフェイスからアルゴリズムへの開発プロセスは不合理であると受け入れられています（おそらく、アルゴリズムは最初でなければならず、一貫性のあるインターフェイスの定式化でなければなりません）。 理由がわかりません。 オブジェクトをどこかで使用する必要があることが突然（便利に）わかった場合は、その構造とインターフェイス（つまり、このオブジェクトとデータを交換できるメソッド）をスケッチすることから始めます。 本質的には、ここでいくつかの追加レベルの抽象化を作成します。 この段階では、実装の詳細（アルゴリズム）にはまだ触れていません。これは、私の意見では、一貫性のあるインターフェイスの作成を妨げることはありません。 手続き型プログラミングでは、コードの一部をプロシージャまたは関数として実行すると、インターフェイスから開始して（コードにスタブを挿入します—空の関数）、その実装の詳細のみを実行できます。 そして、それはばかげて見えません。 もちろん、逆方向の開発コースも可能です。最初に実装アルゴリズム（または複数の実装アルゴリズム）を最初に開発し、次にそれを関数または作成されたクラスのメソッドとして設計します。 しかし、これは、常にこれを行う必要があるという意味ではありません。 したがって、引用のこの部分も、財団の予想のように見えます。
もちろん、本当に大規模で複雑なプロジェクトを開発するときは、ステパノフが説明するとおりに物事ができるという考えを認めます。 私の経験ではこれを判断することはできませんので、この側面はあなたの判断に任せます。 それにも関わらず、OOP方法論が非常に得意な状況が多数存在するため、これは原則としてOOP方法論的に正しくないことを考慮する理由でもありません。
最終的に、キーとなるOOPのアイデア-すべてがオブジェクトである-も選択肢の狭まりのように見えます。 さて、なぜ「すべてがオブジェクト」なのでしょうか？ 「すべてをオブジェクトとして表現できる」のはなぜですか？ それとも翻訳エラーですか？
おわりに
あなたと私は、詐欺師のために、単純にコミュニケーションのステレオタイプとして、この数学を非常に直感的によく使用します。 おそらく、それをhabraのルールで説明し、コメントでの使用を禁止する価値があるのでしょうか？
脅威。 そして、どこかでプログラミング理論や数学を台無しにしたら申し訳ありません。 修正させていただきます。
この投稿の目的は、アレクサンダー・ステパノフや他の誰かの権威を軽視することではなく、「私がどれほど賢いか」を示すことでもありませんでした。 議論で意見を弁明することを学ぶとき、私たちはしばしばソフィズムを使うようになりますが、これを実現すらしないという事実に注意を喚起したかっただけです。 詐欺師にとってこのような数学が判明します。
