•  18-09-2019
  •  | 
  •  

質問

小切手帳に使用する Access データベース (かなり単純な VBA が背後にある) があり、それを SQL バックエンドを備えたスタンドアロン プログラムとして書き直したいと考えています。C++、Java、または Python のいずれかを使用することを考えています。

書き始める前は、(OO ロジックのクラスと C++ のクラスを受講したため) 「OO の用語で」考えるだろうと思っていたので、OO で書くだろうと思っていましたが、自分でできるのは OO だけであることがわかりました。それを手続き型として視覚化します (ただし、おそらく、Access でデータベースがどのように機能するかを考えることに精神的に行き詰まっているためです)。どうやって決めればいいのでしょうか？私は意味を理解しているのでしょうか、それとも概念を理解していないようでしょうか?

ご協力いただきありがとうございます。

役に立ちましたか？

解決

まあ、OO はやりすぎかもしれませんが、素晴らしい練習になります。どのコードモンキーでも手続き型コードを書くことができます。これは、どのような場合でも最も抵抗の少ない方法であるため、ほとんどの人は、あまり機能しない 1 回限りのアプリにこの方法を使用します。ただし、OO との連携経験を得るために記事を書いている場合は、そのように考えるのが最善です。まず金融取引を管理するオブジェクトを設計することから始め、次に DB と対話する方法も必要になります。おそらく、LINQ (または JAVA に相当するもの) を学習できる Entity フレームワークを使用して、トランザクション オブジェクトからデータベース呼び出しを抽象化する DB レイヤーを作成できるかもしれません。これはすべて、楽しみと練習のためにこれを行っていることを前提としています。

他のヒント

私は OO をお勧めします。これは手続き型プログラミングほど難しくはなく、適切なツールを使用すれば実際に保守するのが簡単です。 デルフィ 私の選択は、優れた DB プログラミング サポート、ビジュアル デザイナー、厳密に型指定され、利用可能なコンポーネントが豊富であることです。 Delphi で書かれた優れたアプリケーションは数多くあります。. 。過小評価されがちですが、忠実なファンを獲得している理由はたくさんあります。

デルフィ嫌いの人たちがトマトを積み込んでくるのを、私は身をかがめてやります。

oo は、単純な小切手帳アプリとしてはやりすぎのようです。すべての金融口座を管理するような、より大規模なものを試してください。このようにアカウントクラスを設計することは理にかなっています

まあそれはあなたのモチベーション次第です。小切手帳アプリケーションをできるだけ早く作成したい場合は、プロシージャ コードを大量に作成するだけです。あなた以外の誰も違いが分かりません。このアプリケーションを使用してプログラマーとしての能力を向上させたい場合。時間をかけて、OO での書き込み方法を学びましょう。

私なら Python を使います:コンパイルは行わず、動的型付けを使用します (必要に応じて厳密な型付けも使用できます)。さらに、オープンソース コミュニティで絶大な支持を得ており、優れたサポート、ツール、ドキュメントが無料で提供されます。

OO vs.手続き型 -- あなたが言及したこれらすべての言語は、手続き型スタイル、つまりすべてを行う 1 つの大きなクラス/メソッドで書くことができますが、DRY 原則に従う必要があることがすぐにわかります (Don' 「Repeat Yourself」)、特定のことをうまく実行するいくつかのプライベート メソッドから始めます。それ以降、類似したものを別のクラスにグループ化し、そこからそれらのクラスを抽象化する必要があります。私がここでどこに行くのかわかりますか？

私の意見では、OO と手続き的なことにあまり集中すべきではありません。最初は手続き型に進む可能性がある場合は、手続き型に進みます。これが最も簡単に始めることができます。一方、OO のものは、YAGNI (You Ain't Gonna Need It) に相当するかもしれません。

ただし、あなたがすべきことは、書くことです テスト, 、単体テスト、次に統合テスト。そして、最初にテストを書くように努めるべきです。こうすることで、手続き型アプリケーションから始めた場合でも、後でそれを本格的な OO アプリケーションにリファクタリングできます。ただし、オブジェクトが必要な場合に限ります。これらのテストは、アプリケーション内のコードを移動するときのセーフティネットになります。

最初からアプリケーションをオブジェクトとして考えようとすると、クラス階層とアーキテクチャに行き詰まる可能性があります。

私は天才ではないので間違っているかもしれませんが、私の経験では、単純な関数から始めて、それらをオブジェクトやオブジェクトにグループ化することを考えます。 モジュール 次のように言い始めるよりも良いでしょう。OK、このオブジェクトはパターン X を実装しているこのオブジェクトと対話するので、この方法でインターフェース Y を実装 Z から切り離します。後で、ドメイン モデルが弱いことに気づくかもしれません。進化的な設計の道を歩み、小さな構成要素から始めます。

拡張できる簡単なアプリを探している場合は、チェックしてください 動的データ.

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top