問題タブ [abstract-base-class]

抽象クラスは基本クラスと同じですか?

ベースクラスという言葉をたまに見かけますが、調べてみると「抽象クラス」が飛び交っています。

基本的に同じことを意味する2つの単語ですか？

私は設計上の問題に直面しており、外部入力で行うことができます。抽象基本クラスのキャストを回避しようとしています (それは悪いと聞いたので)。

問題は次の構造にあります。

最初は、次の方法でうまくいくと思っていました。

そして...私はそうしましたが、特に敵対的または友好的なものから「ユニークな」機能にアクセスする必要があるため、これは問題を引き起こします。

私は恥ずかしそうに試しました（うまくいきましたが、好きではなく、安全だとも感じません）：

unordered_map基本抽象クラス型のキーとして使用する設計を維持することを望んでいた/維持しようとしていFactionTypeました... とにかく、入力は大歓迎です。

構文エラーがある場合は、お詫び申し上げます。

ライブラリには、ニューラル ネットワークのクラスがあります。1 つのネットワークを作成すると、すべて正常に動作しますが、2 つ以上のネットワークを作成すると、そのうちの 1 つが学習を停止します。エラーを数時間検索した後、初期化後に基本コンストラクターを呼び出すと、すべてのネットワークが正常に学習することがわかりました。

コードが次のように見える場合

ネットワークは学習しません。ここにあるすべてのソース -

https://sourceforge.net/p/meta-net-project/code/HEAD/tree/metanet/networks/artificial_networks/feedforward_network.py

私は何を間違っていますか？

メモリ効率の良い方法で変更可能なポイントを平面に格納するために、次のクラスを作成しましたnamedtuple('Point', 'x y')。インスタンス ディクショナリは大きいので、次のようにし__slots__ます。

Python 3 でテストしたところ、すべて問題ないように見えました。

ただし、Python 2 ではz、スロットにない場合でも属性を設定できます。

それはなぜですか? また、Python 2 と Python 3 の違いはなぜですか?

抽象基底クラスを使用すると、Python は実際に試してみなくてもオブジェクトの動作を知る方法を提供します。標準ライブラリでは、 collections.abcにコンテナ用に定義されたいくつかの ABC があります。たとえば、引数が反復可能であることをテストできます。

クラスのインスタンスを比較できるかどうかを判断するための ABC が 1 つあることを期待していましたが、見つけることができませんでした。メソッドの存在をテストする__lt__だけでは不十分です。たとえば、辞書は比較できませんが、__lt__まだ定義されています (object実際と同じ)。

私の質問は次のとおりです。比較自体を行わずにキャッチする簡単な方法はありTypeErrorますか?

私の使用例は、並べ替えられたコンテナーに似ています。最初の要素を挿入するときに例外を発生させ、2 番目の要素を待たないようにしたいと考えています。要素をそれ自体と比較することを考えましたが、より良いアプローチはありますか:

collections.SequenceABCを取るように文書化されている関数があるとしましょう。この関数内のコードを ABC インターフェイスに対してテストするにはどうすればよいですか? 私のコードがこの ABC によって定義されたメソッドのみを呼び出し、たとえば によって定義されたメソッドlistやその他の具体的な実装を呼び出していないことを確認する単体テスト (またはテスト) を作成できますcollections.Sequenceか? または、これを確認するための他のツールまたは方法はありますか?

私はこの単純なコードを持っていますが、奇妙なエラーが発生します:

私は何を間違っていますか？理論的な説明をいただければ幸いです。

シナリオ

Combo有名なタコス店が、モデル、ComboItem、Ingredient、およびを使用して Django アプリを構築したいと考えていOrderます。

1. 本社は、同梱アイテムでさまざまなコンボを作成し、元のアイテムの成分と価格をレイアウトしたいと考えています。
2. その後、各フランチャイズは、メニューで販売するコンボを選択でき、ストアのコンボアイテムの価格と材料を調整できます.
3. 注文が入ると、コンボとアイテムの詳細がログに表示され、HQがコンボの名前を変更したり、フランチャイズが価格/成分を変更したりしても、将来変更されるべきではありません.

使用事例

1. HQは「ホットタココンボ」を作成します。関連する 3 つのコンボ アイテムがあります。

   • タコス (価格: 99 ドル、材料: シェル、ビーフ、チーズ、ホットソース)
   • チュロススパイラル (価格: $.79)
   • ドリンク (価格: $1.29)

2. ニューヨークのフランチャイズは、メニューにホット タコス コンボを追加します。タコスの価格を $1.49 に調整し、タコスにレタスを追加します。

3. 顧客は、タコスにチーズをのせずにコンボを注文します。

4. HQ はコンボの名前を Fiery Taco Combo に変更します - NY のコンボ名は更新されますが、タコスは同じカスタム価格のままで、まだレタスが含まれています。

5. NY フランチャイズのマネージャーがすべての注文を確認し、Hot Taco Comboの 1 つの注文を確認します。タコスの材料はシェル、肉、レタスのみです。

問題

Comboaは基本的に 3 つのレベルすべてで同じオブジェクトですが、関連するオブジェクトは異なる可能性があるため、これを処理する最善の方法を決定するのに苦労していComboItemます。HQ は、名前などのコンボ属性を更新できる必要があり、すべてのフランチャイズ コンボ名を更新しますが、コンボ アイテムのカスタマイズはそのままにしておく必要があります。さらに、正確な注文記録のために、販売時点でのコンボの詳細とカスタマイズは、一度記録すると決して変更されるべきではありません。

AbstractBaseClass本来は、関連するモデルやオブジェクトをそれぞれのビジネスレベルで継承する for eachを考えていたのですが、その構造は冗長で保守が難しいと感じました。

次にGenericForeignKey、コンボを HQ、フランチャイズ、またはオーダーのいずれかに関連付け、必要に応じてオブジェクトを複製して、レベルを下げようと考えました。これは奇妙でエラーが発生しやすいと感じます。

誰かがこのようなケースに対処したことがありますか、または何か推奨事項はありますか? それは複雑な問題であり、複雑な解決策が必要なだけの問題ですか、それとも私が見逃している単純なアプローチがありますか? 前もって感謝します。