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

13
クラスの実装について他のプログラマに警告する方法
「特定の方法で使用しなければならない」クラスを書いています(すべてのクラスが...する必要があると思います)。 たとえば、fooManagerクラスを作成します。これには、などへの呼び出しが必要Initialize(string,string)です。そして、例をさらに進めるために、そのThisHappenedアクションをリッスンしなければクラスは役に立たないでしょう。 私のポイントは、書いているクラスにはメソッド呼び出しが必要だということです。しかし、これらのメソッドを呼び出さなければ、コンパイルは正常に終了し、空の新しいFooManagerが作成されます。ある時点で、クラスとその動作に応じて、機能しないか、クラッシュする可能性があります。私のクラスを実装するプログラマーは明らかに内部を見て、「ああ、Initializeを呼び出さなかった!」と気付くでしょう。 しかし、私はそれが好きではありません。私が理想的に望んでいるのは、メソッドが呼び出されなかった場合にコンパイルしないコードです。それは単に不可能だと思います。または、すぐに表示され、明確になるもの。 私がここで持っている現在のアプローチに悩まされているのは次のとおりです。 クラスにプライベートブール値を追加し、クラスが初期化されている場合は必要なすべての場所を確認します。そうでない場合は、「クラスが初期化されていません.Initialize(string,string)。本当に呼び出していますか?」という例外をスローします。 私はそのアプローチで少し大丈夫ですが、多くのコードがコンパイルされ、最終的にはエンドユーザーには不要になります。 また、Initiliaze呼び出すだけのメソッドよりも多くのメソッドがあると、コードがさらに増えることがあります。パブリックメソッド/アクションが多すぎないようにクラスを維持しようとしていますが、それは問題を解決するものではなく、単に合理的なものにするだけです。 私がここで探しているのは: 私のアプローチは正しいですか? より良いものはありますか? 皆さんは何をしますか/アドバイスしますか? 非問題を解決しようとしていますか?同僚から、使用する前にクラスをチェックするのはプログラマーだと言われました。私は敬意を持って同意しませんが、それは別の問題です。 簡単に言えば、そのクラスが後で、または他の人によって再利用されたときに、呼び出しを実装することを決して忘れない方法を見つけようとしています。 明確化: ここで多くの質問を明確にするために: 私は間違いなくクラスの初期化の部分について話しているだけでなく、それは一生です。同僚がメソッドを2回呼び出さないようにし、Yの前にXを呼び出すようにします。Assertsのアイデアは本当に気に入りましたが、Assertsが常に可能であるとは限らないので、他のアイデアを混ぜる必要があると確信しています。 私はC#言語を使用しています!どうして私はそれを言及しなかったのですか?!私はXamarin環境にいて、PCL、iOS、Android、およびWindowsプロジェクトを含むソリューションで通常6〜9個のプロジェクトを使用してモバイルアプリを構築しています。私は約1年半(学校と仕事を合わせて)開発者でした。そのため、時々ばかげた声明や質問があります。ここではおそらくすべては無関係ですが、情報が多すぎることは必ずしも悪いことではありません。 プラットフォームの制限と依存関係注入の使用のため、コンストラクターに必須のすべてを常に配置できるわけではありません。Interfaces以外のパラメーターはテーブル外にあります。または、私の知識が十分でない可能性があります。ほとんどの場合、初期化の問題ではありませんが、 彼がそのイベントに登録したことを確認するにはどうすればよいですか? 彼が「ある時点でプロセスを停止する」ことを忘れなかったことをどのように確認できますか ここで、私は広告取得クラスを覚えています。広告が表示されるビューが表示されている限り、クラスは毎分新しい広告を取得します。そのクラスは、Adを表示できる場所に構築するときにビューを必要とします。これは明らかにパラメーターに入れることができます。ただし、ビューが消えたら、StopFetching()を呼び出す必要があります。そうしないと、クラスは、そこにさえないビューの広告を取得し続けますが、それは悪いことです。 また、このクラスには、たとえば「AdClicked」など、リッスンする必要があるイベントがあります。聞いていない場合はすべて正常に動作しますが、タップが登録されていない場合、そこでの分析の追跡が失われます。ただし、広告は引き続き機能するため、ユーザーと開発者には違いが見られず、アナリティクスのデータは間違っています。それは避ける必要がありますが、開発者がtaoイベントに登録する必要があることを開発者がどのように知ることができるかわかりません。しかし、これは単純化された例ですが、アイデアは「彼が利用可能な公開アクションを使用することを確認する」ことであり、当然のことです!

3
PythonがC ++ではなくCで書かれているのはなぜですか?
でPythonのチュートリアル 1は、Pythonのオリジナル実装はCであることを読み取ることができます。 一方、Cで書かれたPython実装(...) PythonがC ++ではなくCで作成されたのはなぜですか? この決定の背景にある理由を知りたいのですが、その答えは歴史的な参考文献によって支持されるべきです(意見に基づくものではありません)。

5
Cコンパイラがそれほど少ないのはなぜですか?
Cは、世界で最も広く使用されている言語の1つです。既存のコードの大部分を占め、膨大な量の新しいコードに引き続き使用されます。ユーザーに愛されており、非常に広く移植されているため、Cを実行できることはプラットフォームの非公式な定義の多くに当てはまります。 それでは、すべてのコンパイラはどこにありますか? デスクトップには、(現実的に)GCCとClangの2つがあります。数秒間考えてみれば、おそらくインテルも存在していることを覚えているでしょう。他の人はほんの一握りで、平均的な人が名前を付けるにはあまりにもあいまいで、ほとんどの場合、最近の言語バージョン(またはよく定義された言語サブセット、単に「サブセット」)をサポートすることをほとんど気にしません。このリストのメンバーの半分は歴史的な脚注です。残りのほとんどは非常に特殊化されており、実際には完全な言語を実装していません。実際にオープンソースであると思われるものはほとんどありません。 SchemeとForth-ファンに愛されている他の小さな言語-はおそらく実際のユーザーよりも多くのコンパイラを持っています。SMLのようなものでも、Cよりも「深刻な」実装を選択できます。一方、検証を目的とする新しい(未完成の)Cコンパイラの発表では、実際にかなり否定的な応答が見られ、ベテランの実装は、 C99。 どうして?Cの実装はとても難しいですか?C ++ではありません。ユーザーは、それがどの複雑なグループに属するかについて非常に歪んだ考えを持っているだけですか(つまり、実際にはSchemeよりもC ++に近いということですか)。

6
Javaとは異なり、「new」および「virtual + override」キーワードでC#が作成されたのはなぜですか?
Javaではノーがあるvirtual、new、overrideメソッド定義のキーワード。したがって、メソッドの動作は理解しやすいです。場合原因DerivedClassが延びBaseClassのを、同じ名前と同じシグネチャを持つ方法有するBaseClassのその後ランタイム多形で行われるオーバーライドが(メソッドではない提供しますstatic)。 BaseClass bcdc = new DerivedClass(); bcdc.doSomething() // will invoke DerivedClass's doSomething method. C#に来ると、非常に多くの混乱が発生し、newor virtual+deriveまたはnew + virtualオーバーライドがどのように機能するかを理解するのが難しくなります。 なぜ世界DerivedClassで同じ名前と同じシグネチャを持つメソッドを追加しBaseClass、新しい動作を定義するのかを理解することはできませんが、実行時のポリモーフィズムでは、BaseClassメソッドが呼び出されます!(これはオーバーライドではありませんが、論理的にはそうする必要があります)。 以下の場合にはvirtual + override論理的な実装が正しいですが、プログラマが、彼はコーディングの際に上書きするようにユーザーに権限を与えるべき方法だと思うしなければならないのに。これには賛否両論があります(今は行かないでください)。 それで、なぜC#には非論理的な推論と混乱のためのスペースがあるのか。それで、どの現実世界の文脈で、代わりに使用するか、またvirtual + override代わりに使用することを考えるべきかという質問を再構成できますか?newnewvirtual + override 特にOmarからの非常に良い回答の後に、C#デザイナーはメソッドを作成する前にプログラマが考える必要があることについてより多くのストレスを与えたと思います。 今、私は質問を念頭に置いています。Javaのように、次のようなコードがあった場合 Vehicle vehicle = new Car(); vehicle.accelerate(); 後で新しいクラスをSpaceShip派生させVehicleます。次にcar、すべてをSpaceShipオブジェクトに変更したいので、1行のコードを変更するだけです Vehicle vehicle = new SpaceShip(); vehicle.accelerate(); これは、コードのどのポイントでも私のロジックを壊しません。 しかし、C#の場合、if SpaceShipがVehicleクラスをオーバーライドせずにaccelerate使用するnewと、コードのロジックが壊れます。それは不利ではないですか?

3
C ++で同じ目的でインターフェイスを使用できる一方で、PImplパターンのポイントは何ですか?
C ++でPImplイディオムを使用する多くのソースコードが表示されます。その目的はプライベートデータ/タイプ/実装を非表示にすることであるため、依存関係を削除し、コンパイル時間とヘッダーインクルードの問題を減らすことができると思います。 しかし、C ++のインターフェイス/純粋な抽象クラスにもこの機能があり、データ/型/実装を隠すために使用することもできます。また、オブジェクトを作成するときに呼び出し元にインターフェイスを表示させるために、インターフェイスのヘッダーでファクトリメソッドを宣言できます。 比較は次のとおりです。 費用: パブリックラッパー関数の実装を繰り返す必要さえないため、インターフェイスの方法のコストは低くvoid Bar::doWork() { return m_impl->doWork(); }なります。インターフェイスで署名を定義するだけです。 よく理解された: インターフェイステクノロジーは、すべてのC ++開発者によく理解されています。 パフォーマンス: インターフェイス方法のパフォーマンスは、PImplイディオムよりも悪くありません。どちらも余分なメモリアクセスです。パフォーマンスは同じだと思います。 以下は私の質問を説明するための擬似コードです。 // Forward declaration can help you avoid include BarImpl header, and those included in BarImpl header. class BarImpl; class Bar { public: // public functions void doWork(); private: // You don't need …

2
使用するCommon Lisp実装はどれですか?[閉まっている]
Common Lispでの開発を開始することには、実装の選択という差し迫った問題があるようです。CLの実装を検討するとき、何を考慮に入れる必要がありますか? ANSI規格に準拠する必要がありますか?SLIMEでサポートされるべきですか?特定の実装には適切なライブラリ、ドキュメントなどが欠けていますか?

2
RESTを実行する適切な方法は何ですか?
誰もが実際に何が何であるかを実際に理解していない場合でも、誰もがSOAを実行しています。だから彼らは間違っています。それを類推として使用して、RESTが何であるか(または少なくとも私はそう思う)を知っており、その一部を実行したいと考えています。しかし、私はそれを正しくしたい。 だから私の質問は、RESTを行う適切な方法は何ですか?

5
プロパティの1つが必要ない場合のインターフェイスの実装
とても簡単です。私はインターフェイスを実装していますが、このクラスには不要なプロパティが1つあり、実際には使用しないでください。私の最初のアイデアは、次のようなことをすることでした。 int IFoo.Bar { get { raise new NotImplementedException(); } } これ自体に問題はないと思いますが、「正しい」とは感じません。他の誰かが以前に同様の状況に遭遇したことはありますか?もしそうなら、どのようにアプローチしましたか?

6
結果をキャッシュしない方法でLINQを実装することにより、どのような利点が得られましたか?
これは、LINQを使用して足を濡らしている人々にとって既知の落とし穴です。 public class Program { public static void Main() { IEnumerable<Record> originalCollection = GenerateRecords(new[] {"Jesse"}); var newCollection = new List<Record>(originalCollection); Console.WriteLine(ContainTheSameSingleObject(originalCollection, newCollection)); } private static IEnumerable<Record> GenerateRecords(string[] listOfNames) { return listOfNames.Select(x => new Record(Guid.NewGuid(), x)); } private static bool ContainTheSameSingleObject(IEnumerable<Record> originalCollection, List<Record> newCollection) { return originalCollection.Count() == 1 && newCollection.Count() …

6
実装へのインターフェイス参照をキャストすることで、著者は何を意味しますか?
私は現在C#をマスターしようとしていますが、Gary McLean HallによるC#を介してAdaptive Codeを読んでいます。 彼はパターンとアンチパターンについて書いています。実装とインターフェースの部分で、彼は次のように書いています。 インターフェイスへのプログラミングの概念に慣れていない開発者は、多くの場合、インターフェイスの背後にあるものを手放すのが困難です。 コンパイル時に、インターフェースのクライアントは、使用しているインターフェースの実装を把握していないはずです。このような知識は、クライアントをインターフェイスの特定の実装に結び付ける誤った仮定につながる可能性があります。 クラスが永続ストレージにレコードを保存する必要がある一般的な例を想像してください。そのために、インターフェイスに正しく委任します。これにより、使用される永続的なストレージメカニズムの詳細が隠されます。ただし、実行時にどのインターフェイスの実装が使用されているかについて仮定するのは正しくありません。たとえば、インターフェイス参照を実装にキャストすることは常に悪い考えです。 それは言葉の壁か、私の経験不足かもしれませんが、それが何を意味するのかよくわかりません。ここに私が理解していることがあります: C#を練習するための自由時間の楽しいプロジェクトがあります。そこでクラスがあります: public class SomeClass... このクラスは多くの場所で使用されています。C#を学習しているときに、インターフェイスで抽象化する方がよいことを読んだので、次のようにしました。 public interface ISomeClass <- Here I made a "contract" of all the public methods and properties SomeClass needs to have. public class SomeClass : ISomeClass <- Same as before. All implementation here. そこで、いくつかのクラス参照をすべて調べて、それらをISomeClassに置き換えました。 私が書いた建設を除いて: ISomeClass myClass …

2
DDDの実装:ユーザーと権限
私は、ドメイン駆動設計の原則を把握しようとする小さなアプリケーションに取り組んでいます。成功した場合、これは大規模プロジェクトのパイロットになる可能性があります。「Implementing Domain-Driven Design」(Vaughn Vernon著)を読み、同様のシンプルなディスカッションフォーラムを実装しようとしています。また、githubでIDDDサンプルをチェックアウトしました。私は自分のケースにアイデンティティとアクセスを採用するのに苦労しています。背景情報をいくつかご紹介します。 私は(願わくば)ユーザーとアクセス許可のロジックを分離する背後にある理由を理解しています。それはサポートドメインであり、異なる境界コンテキストです。 コアドメインには、ユーザーはなく、作成者、モデレーターのみが存在します。これらは、サービスを使用してIDおよびアクセスコンテキストにアクセスし、受信したユーザーオブジェクトをモデレーターに変換することによって作成されます。 ドメイン操作は、関連する役割をパラメーターとして呼び出します。例: ModeratePost( ..., moderator); ドメインオブジェクトのメソッドは、指定されたモデレーターインスタンスがnullでないかどうかを確認します(IDおよびアクセスコンテキストから要求されたユーザーがモデレーターロールを持っていない場合、モデレーターインスタンスはnullになります)。 ある場合には、投稿を変更する前に追加のチェックを行います: if (forum.IsModeratedby(moderator)) 私の質問は: 後者の場合、セキュリティの懸念がコアドメインに再び溶け込んでいないのですか?以前は、本は「誰が主題を投稿できるか、またはどのような条件で許可されていますか。フォーラムは著者が今それをしていることを知る必要があります」と述べていました。 本のロールベースの実装は非常に簡単です。モデレーターがコアドメインである場合、必要なときに現在のユーザーIDをモデレーターインスタンスまたはオーサーに変換しようとします。サービスは適切なインスタンスで応答するか、ユーザーに必要なロールがない場合はnullで応答します。ただし、これをより複雑なセキュリティモデルにどのように適合させることができるかわかりません。私がパイロットをしている現在のプロジェクトには、グループ、ACLなどのかなり複雑なモデルがあります。 「投稿はその所有者または編集者のみが編集する必要があります」のようにあまり複雑ではないルールでさえ、このアプローチは破綻しているように見えます。 IdentityOrAccessコンテキストにOwnerOrEditorインスタンスを要求することは適切ではないと感じ、コアドメインではますますセキュリティ関連のクラスになります。さらに、userIdだけでなく、保護されたリソースの識別子(投稿、フォーラムなどのID)をセキュリティコンテキストに渡す必要があります。 ) コアドメインへのアクセス許可を引き出し、ドメインオブジェクトのメソッドまたはサービスでそれらをチェックすることで、最終的には、セキュリティに関する懸念をドメインに混在させることになります。 セキュリティとアクセス許可がコアドメイン自体でない限り、これらのアクセス許可関連のものはコアドメインの一部であってはならないことをどこかで読みました(そしてそれに同意する傾向があります)。上記のような単純なルールは、セキュリティをコアドメインの一部にすることを正当化しますか?

3
refと実行時のoutの違いは何ですか?
C#は、参照によって渡される引数を作成するためのrefand outキーワードを提供します。2つのセマンティックは非常に似ています。唯一の違いは、フラグ付き変数の初期化です。 ref関数に渡す前に変数を初期化する必要がありますが、必要ありoutません。 out関数内で変数を初期化する必要がありますが、必要ありrefません。 これらの2つのキーワードの使用例もほぼ同じであり、あまりにも頻繁に使用されるため、コードのにおいと見なされます(TryParseandやTryGetValuepattern などの有効な使用例もあります)。 このため、誰かが説明できますが、なぜC#には非常に狭いユースケース用の2つの非常に類似したツールがあるのですか? また、MSDNでは、実行時の動作が異なることが記載されています。 refキーワードとoutキーワードは異なる実行時の動作を引き起こしますが、コンパイル時のメソッドシグネチャの一部とは見なされません。 実行時の動作はどのように異なりますか? 結論 両方の答えが正しいように見えます、ありがとう。jmorenoを受け入れたのは、より明確だからです。

4
明示的なインターフェイス実装を使用してC#のメンバーを非表示にすることはできますか?
C#でのインターフェイスおよび明示的なインターフェイスの実装の操作方法は理解していますが、頻繁に使用されない特定のメンバーを非表示にするのが悪いと考えられているのではないかと考えていました。例えば: public interface IMyInterface { int SomeValue { get; set; } int AnotherValue { get; set; } bool SomeFlag { get; set; } event EventHandler SomeValueChanged; event EventHandler AnotherValueChanged; event EventHandler SomeFlagChanged; } イベントは有用ですが、使用されることはほとんどないことを事前に知っています。したがって、IntelliSenseの乱雑さを避けるために、明示的な実装を介して実装クラスからそれらを隠すことは理にかなっていると思いました。


4
C ++でインターフェイスと実装を整理する方法
C ++には、ヘッダーファイルの内容とcppファイルの内容に関するいくつかの異なるパラダイムがあることがわかりました。私の知る限り、ほとんどの人、特にCのバックグラウンドを持つ人は: foo.h class foo { private: int mem; int bar(); public: foo(); foo(const foo&); foo& operator=(foo); ~foo(); } foo.cpp #include foo.h foo::bar() { return mem; } foo::foo() { mem = 42; } foo::foo(const foo& f) { mem = f.mem; } foo::operator=(foo f) { mem = f.mem; } foo::~foo() {} …

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.