プロジェクトはオブジェクト指向なしで存続できますか？

特定のクラスの数値問題を解決する小さなMATLABパッケージを書いています。アルゴリズムには3つの段階があり、ユーザーは各段階で5つの選択肢があります。私が使用して全体の問題を実装しているの機能及び3スイッチケース（各アルゴリズムのステージに1つ）。それは正常に動作しますが、私はそれをより多くのこと（5つ以上の選択肢ともう1つのステージ）にして、Pythonの移植版（一部の人は興味がある）を作ることを検討しています。$\approx 20$

OOPフレームワークに変換する必要があるのか​​（まったく得意ではない）、または私が持っている手続きフレームワーク（得意）に固執する必要があるのか​​と思いました。私の手続き型コードでは、関数が2つのことを行わず、重複が最小限であることを確認しました（2つのコードセグメントが同じことを行うことはほとんどありません）。

ドメインに適していると思われる場合は、SOに移行してください。

オブジェクト指向が役立つ場合にOOPフレームワークに変換する必要はありません。関数の数は、これらの関数内および関数間のコードの重複、またはこれらの関数の長さよりもインジケーターが少ないことに注意してください。（コードが100行を超える関数は、「改善の可能性」の典型的な指標になります。）

オブジェクト指向が役立つ部分を特定できない場合は、OOPフレームワークへの変換が最善の最初のステップではありません。むしろ、オブジェクト指向に精通している人に何を単純化または改善できるか尋ねて、それがなぜ単純化または改善であるかを理解してみてください。

deal.IIやPETScのようなフレームワークを使用したい場合は、それらが提供する機能が役立つ場合に使用してください。独自のコードをより良くしたり、より保守しやすくなると考えているからではありません。ただし、すでにMATLABフレームワーク内にいるため、代わりにC ++ OOPフレームワークに変更することはほとんどありません。（MATLABは、おそらくすでにご存じのとおり、完全なOOPサポートを提供します。）

Pythonの移植については、現在の知識に基づいて開始し、大幅に改善するために十分な知識を得た後で、2回目の開始を行ってください。

この質問は、スタックオーバーフローに適しています。これは計算科学の一般的な問題なので、ここにも適していると思います。

合成アルゴリズムに関して、Cコードを読むことができる場合、これをうまく行うライブラリーの良い例はPETScです。オブジェクト指向プログラミングスタイルはデータのカプセル化に役立ちますが、簡単な最初のステップとして、ステージの各選択を共通のインターフェイスを持つ関数にすることができます。次に、アルゴリズムについて、各ステージの関数を入力として渡し、メインアルゴリズムで各ステージの関数を呼び出します。

$1 + 1$1+1.plus(1)$1+1$plus(1,1)1plus__plus____rplus__

したがって、四角いペグを丸い穴に無理に押し込む必要があると感じないでください。アルゴリズムが単純な手順で見栄えが良い場合は、そのままにしておきます。オブジェクト指向システムに含める必要がある場合は、オブジェクト指向以外のコードにオブジェクト指向インターフェースをいつでも配置できます。C ++のコーダーはこれを毎日行います（そしてそのために支払いを受けさえします）。