タグ付けされた質問 「oop」

オブジェクト指向プログラミングは、「オブジェクト」を使用したプログラミングパラダイムです。つまり、データフィールドとメソッド、およびそれらの相互作用で構成されるデータ構造です。

1
Erlangのプロセス/メッセージとSmalltalkのオブジェクト/メッセージの違いは何ですか?
Smalltalkのオブジェクト/メッセージとErlangのプロセス/メッセージの違いを理解しようとしています。このトピックに関する次の投稿を読みました。 私が理解している限り、Smalltalkでは、すべてがオブジェクトであり、すべてが同じ「オブジェクト/メッセージ」の抽象化を持っています-番号1でさえ、メッセージの受け渡しでのみ到達できるオブジェクトです。ある1アーラン/エリクシルの処理は?Erlangのすべてがメッセージ/プログラムパラダイムへの応答ですか?Erlangの番号にメッセージを送信できますか? どうもありがとう。

4
標準のデッキで見られるよりも複雑なトランプの種類のクラスを作る良い方法は?
私はオブジェクト指向プログラミングに非常に慣れていないので、単純なカードゲームを作ることでpythonでの学習を始めようとしています(伝統的なようです!)。私は正常に動作する次の例を実行し、PlayingCard()クラスのインスタンスを作成するためにクラスの複数のインスタンスを作成することについて教えてくれますDeck()。 class PlayingCard(object): def __init__(self, suit, val): self.suit = suit self.value = val def print_card(self): print("{} of {}".format(self.value, self.suit)) class Deck(object): def __init__(self): self.playingcards = [] self.build() def build(self): for s in ["Spades", "Clubs", "Diamonds", "Hearts"]: for v in range(1,14): self.playingcards.append(PlayingCard(s,v)) deck = Deck() 標準の52デッキだけではなく、より複雑なカードを使って何かを作りたいと思っています(値が適切に増加している)。私が念頭に置いているデッキはモノポリーカードゲームです。 カードには、ACTIONカード、PROPERTYカード、MONEYカードの3つの基本的なタイプがあります。アクションカードはさまざまなアクションを実行し、プロパティカードはさまざまなカラーセットに属し、マネーカードはさまざまな値を持つことができます。さらに、プロパティカードは「ワイルドカード」にすることができ、2つのセットのいずれかの一部として使用できます。最後に、すべてのカードには同等の金額値があります(各カードの上隅に示されています)。レントアクションカードでは、カードはカードに示されているカラープロパティにのみ適用できます。 私の質問は、一般的にこのような状況をどのように処理するかであり、クラスベースのpythonプログラムにこれらの異なるカードを含めるための良い方法は何でしょうか?私は単一のPlayingCard()クラスを保持し、のような多くの入力を保持する必要がありPlayingCard(type="PROPERTY", value="3M")ます。それともなど、別々のクラスを作成する方が良いだろうActionPlayingCard()、PropertyPlayingCard()などを?それとももっと良い方法がありますか?私が言うように、私はここで私の学習の初めであり、より高いレベルの設計の観点からこれらのタイプの状況を整理する方法。 どうもありがとう。

1
クラスアクセス修飾子より制限の少ないメンバーアクセス修飾子の使用はどうですか?
たとえば、いくつかのメンバーを持つクラスがあり、メンバーにはクラス自体よりも制限の少ないアクセス修飾子があるとします。 具体的な例は次のとおりです。 package apples; class A { // package private public int foo() { // public (=> less restrictive than *package private*) return 42; } } メンバーアクセス修飾子よりも制限の厳しいクラスアクセス修飾子を理解すると、制限の少ないメンバーアクセス修飾子が上書きされます。したがって、制限の少ないメンバーアクセス修飾子はまったく効果がありません。 私の理解は正しいですか? そうでない場合、結果はどうなりますか? 制限の少ないメンバーアクセス修飾子を使用する正当な理由は何ですか? 最後に、従うべきベストプラクティスは何ですか? 関数の参照を渡し始めると結果に影響が出る可能性があると考えたため、いくつかの実験も行いましたが、それでもアクセス修飾子は重要ではないようです。 私が構築した状況は次のとおりです: apples.Bbla()への参照を返すパブリックメソッドを提供しますapples.A.foo。 次に、をpizzas.C呼び出しapples.B.blaて参照を取得しA.foo、呼び出します。 したがって、にA.foo()は直接表示されませんがC、を介して間接的にのみアクセスできますB.bla() 私はそれをテストしましたが、foo() パッケージのアクセス修飾子をプライベートにするかどうかに関係なく、違いはありません。 package apples; import java.util.function.IntSupplier; public class B { public IntSupplier getReferenceToAFoo() { …

2
Javaでは、いつインターフェイスでプライベートインスタンスメソッドを使用する必要がありますか?
Java 9以降、インターフェースのメソッドはプライベートにすることができます。プライベートメソッドは、静的メソッドまたはインスタンスメソッドです。プライベートメソッドは、インターフェイス自体のメソッドでのみ使用できるため、その使用は、インターフェイスの他のメソッドのヘルパーメソッドに限定されます。 Cay S. Horstmann、コアJavaボリュームI-基礎 共通の機能をプライベートメソッドに配置して、パブリックにアクセスできないようにすることができます。ただし、ここでは2種類のプライベートメソッドを使用できます。 private private static private staticメソッドの使用は理解できますが、いつprivateメソッドを使用する必要がありますか?これはインターフェースであるため、ここではインスタンスを扱っていませんが、privateメソッドの作成が許可されているのはなぜですか?private staticメソッドだけが必要ではないですか?
9 java  oop 

1
C#-オーバーライドされたメソッドの基本バージョンの呼び出し
基本クラスAと派生クラスがあるとしBます。 クラスにAは2つの関数があります:fun1()およびfun2()、はをfun1()呼び出しますfun2()。 クラスはandをBオーバーライドfun1()しfun2()、再度fun1()呼び出しますfun2()。 ただし、base.fun1()オーバーライドを呼び出しますfun2()。非常に不幸なループを作成する基本クラスのバージョンの代わりにbase.fun1()呼び出しfun2()を行うため: fun1() -> fun2() -> base.fun1() -> fun2() -> base.fun1() -> ... のbase.fun1()基本バージョンを強制的に呼び出す方法はありますfun2()か?本当の問題はおそらくこれらのクラスの設計が悪いことにあることは承知していますが、それがどういうわけか可能かどうか私はまだ興味があります。

1
特性で使用する値を動的に生成するにはどうすればよいですか?
私が書いているライブラリの場合、そのHOWの属性をhandles使用して、そのHOWのインスタンスに、別のHOWが実行するさまざまな役割のメソッドを委任します。私の最初の試みはこのように見えました(これを読みやすくするために、これはのみを扱いますMetamodel::Naming): class ParentHOW does Metamodel::Naming { method new_type(ParentHOW:_: Str:D :$name!, Str:D :$repr = 'P6opaque' --> Mu) { my ::?CLASS:D $meta := self.new; my Mu $type := Metamodel::Primitives.create_type: $meta, $repr; $meta.set_name: $type, $name; $type } } class ChildHOW { has Mu $!parent; has Mu $!parent_meta handles <set_name shortname set_shortname>; submethod BUILD(ChildHOW:D: …
8 oop  traits  raku 
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.