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

オブジェクトのタイプを宣言するためのテンプレート。

5
いつクラスの代わりに構造体を使用しますか?[閉まっている]
構造体とクラスを使用する場合の経験則は何ですか?私はそれらの用語のC#定義を考えていますが、あなたの言語が同様の概念を持っているなら、あなたの意見も聞きたいです。 私はほとんどすべてにクラスを使用する傾向があり、構造が非常に単純化されており、PhoneNumberなどのような値型でなければならない場合にのみ構造体を使用します。しかし、これは比較的マイナーな使用のように思われ、より興味深いユースケースがあることを願っています。
174 c#  design  class  struct 

10
C#で「静的」を使用しないでください
コードレビューのために、他のアーキテクトに書いた申請書を提出しました。そのうちの1人はすぐに返事を書き、「「静的」を使用しないでください。静的クラスと静的メソッドを使用して自動テストを作成することはできません。「静的」は避ける必要があります。」 チェックして、クラスの1/4が完全に「静的」とマークされています。クラスはコード全体で使用される単一のグローバルクラスであるため、クラスのインスタンスを作成しない場合は静的を使用します。 彼は、静的コードでは使用できないモック、IOC / DIテクニックを含むものについて言及し続けました。彼は、サードパーティのライブラリがテスト不能であるために静的である場合、それは残念だと言います。 この他の建築家は正しいですか? 更新:ここに例があります: APIManager-このクラスは、次に許可される時間とともに呼び出しているサードパーティAPIの辞書を保持します。多くのサードパーティが利用規約で持っているAPIの使用制限を強制します。Thread.Sleep(APIManager.GetWait( "ProviderXYZ"))を呼び出して、サードパーティサービスを呼び出す場所で使用します。電話をかける前に。ここにあるものはすべてスレッドセーフであり、C#のTPLでうまく機能します。

13
OOPのオブジェクトはエンティティを表す必要がありますか?
オブジェクトはエンティティを表す必要がありますか? エンティティ私のような何かを意味Product、Motor、ParkingLotなど、物理的、あるいは明確な非物理的な概念オブジェクト-だけでなく、いくつかのコアデータは明らかにオブジェクトに属していると、定義されているもの、およびいくつかの関数/メソッドコアデータを明確に操作します。 たとえば、aのオブジェクトDemon、それ自体のエンティティ、想像上のオブジェクト、おそらく物理的ではなくエンティティを持つことができます オブジェクトは、メソッドのコレクション、共通の目標に結び付く共通のプロシージャセットになりますか? 例:クラスを呼び出すことができるMotorOperationsか、MotorActionsそこには実体ではありませんが、クラス内のメソッドは次のようなことを行う場合には、 getMotorDataFromHTMLForm() getMotorManufacturers() selectMotorFromUserRequirements($ requirements) canMotorCanHandleOperatingConditions($ conditions) computePowerConsumptionForMotor($ id) クラスは通常、オブジェクトの中心となるデータ+データの操作として定義されます。そのため、Motorモーターの仕様に関連するいくつかのモーター変数があり、それらのデータを組み合わせて何かを生成する操作があります。 私の場合、データを操作するクラスとクラスを通過するデータを持っているようなもので、一時的なクラススルーデータ以外に「モーター操作」を中心としたデータはありません。 質問 クラスはエンティティのないオブジェクトを表すことができますか?そうでない場合、なぜそれらは悪い/不完全/非OOP中心ですか?OOPに合わせて概念的に変更/改善する必要がある方法はありますか?

7
プライベート静的メソッドがあるのはなぜですか?
質問を解決したかっただけです。プライベートな可視性を持つ通常のメソッドとは対照的に、プライベートな静的メソッドを持つことのポイントは何ですか? 静的メソッドを持つことの利点は、クラスのインスタンスなしで呼び出すことができることだと思っていましたが、そのプライベートは静的であるというポイントさえありますか? 私が考えることができる唯一の理由は、オブジェクトレベルではなく、クラスレベルでメソッドを概念的に理解するのに役立つということです。

11
プログラムを複数のクラスに分割するのが良いのはなぜですか?[閉まっている]
私はまだ高校生(10年生)で、学校で実際のコンピューターコースをまだ受講していません。これまでにやったことはすべて本を通してです。これらの本は、継承などの概念を教えてくれましたが、プログラムを複数のクラスに分割するとどのように役立ちますか?本は私に決して言わなかった。 主に最近のプロジェクトのためにこれを求めています。これはアーケードビデオゲームで、一部の人が言っているようにFlashゲームのようなものです(Flashゲームとは何なのかはわかりませんが)。事は、それはただ一つのクラスです。1つのクラスで完全に正常に動作します(ただし、時折ラグが発生します)。だから、私はそれを複数のクラスに分割することがどのように役立つかを尋ねています。 このプロジェクトはJavaで行われ、記録のために私がプロジェクトに取り組んでいるのは私だけです。

8
「神のオブジェクト」が間違っていることを証明または反証するにはどうすればよいですか?
問題の概要: 長い話を簡単に言えば、私はコードベースと開発チームを引き継ぎました。私はこれを置き換えることは許されておらず、God Objectsの使用は大きな問題です。今後、リファクタリングをしてもらいたいのですが、「もっと簡単だから」、God Objectsを使ってすべてをやりたいチームから押し戻されています。これは、リファクタリングが許可されないことを意味します。私は長年の開発経験、これらのことを知るために雇われた新しいボスなどを押し返しました。また、サードパーティのオフショア会社が営業担当者を説明しました。これは現在、役員レベルと会議です明日であり、長期的にはより安くなると思うので、多くの技術的な弾薬を使ってベストプラクティスを提唱したいと思います(そして、個人的にはサードパーティが心配していることだと感じています)。 私の問題は技術レベルからのものであり、長期的にはよく知っていますが、超短期間と6か月の期間には問題があります。 1人(ロバートC.マーティン、別名ボブおじさん)の、1人のデータ(1人のみ)(ロバートCマーティン)が十分な議論をしていないと言われているように。 質問: 「神」オブジェクト/クラス/システムのこの使用は明らかに悪いと言っている分野の有名な専門家が直接引用できるリソース(タイトル、発行年、ページ番号、引用)は何ですか?最も技術的に有効なソリューションの場合)? 私がすでに行った研究: ここにはたくさんの本があり、「god object」と「god class」という言葉の使用についてインデックスを検索しました。奇妙なことに、ほとんど使用されておらず、たとえば、私が持っているGoF本のコピーは使用されません(少なくとも私の目の前のインデックスによると)が、下の2冊の本で見つけましたが、もっと欲しい私は使えます。 ウィキペディアのページで「God Object」と現在の参照リンクの少ないスタブを確認したので、個人的には有効とは見なされない環境ではあまり使用できないと言うことには個人的に同意します。引用された本はまた、私がこれらの技術的ポイントを議論している人々によって有効であるには古すぎると考えられています。 「オブジェクトは使いやすい」。私は個人的にこの声明が間違っていると信じていますが、それが何であれ真実を証明したいと思います。 ロバートCマーティンの「C#のアジャイルの原則、パターン、および実践」(ISBN:0-13-185725-8、ハードカバー)では、266ページに「神のクラスが悪い考えであることを誰もが知っています。システムのすべてのインテリジェンスを単一のオブジェクトまたは単一の機能に集中させること。OODの目標の1つは、動作を多数のクラスおよび多数の機能に分割および分散することです。-そして、とにかく時々神のクラスを使用する方が良いことを時々言い続けます(例としてマイクロコントローラーを引用)。 ロバートCマーティンの「クリーンコード:アジャイルソフトウェアクラフツマンシップハンドブック」136ページ(およびこのページのみ)で、「神のクラス」について説明し、「クラスは小さくなければならない」ルールの違反の主な例として呼び出しています彼は138ページから始まる単一責任原則の推進に使用しています。 私が抱えている問題は、すべての参考文献と引用が同じ人(ロバートC.マーティン)から来ており、同じ一人の人/情報源から来ていることです。彼はただ一つの見解であるため、「神クラス」を使用しないという私の願望は無効であり、ソフトウェア業界の標準的なベストプラクティスとして受け入れられないと言われています。これは本当ですか?ボブおじさんの教えを守ろうとすることで、技術的な観点から間違ったことをしているのでしょうか? 神のオブジェクトとオブジェクト指向プログラミングおよび設計: これについて考えるほど、OOPを勉強するときに学ぶことが多くなり、明示的に呼び出されることはありません。良いデザインへのその暗黙は私の考えです(私が学びたいので、自由に訂正してください)、問題は私がこれを「知っている」ことですが、誰もがそうではありません。統計的にほとんどの人はプログラマーではないため、実際にはほとんどの人が統計的に無知であるにもかかわらず、私は事実上それを普遍的な真実と呼んでいます。 結論: 彼らが技術的な主張をしており、真実を知り、実際のエンジニア/科学者のような引用でそれを証明できるようにしたいので、引用する最良の追加結果を得るために何を検索するのか迷っています私は、神のオブジェクトを使用したコードの個人的な経験のために、神のオブジェクトに偏っています。どんな援助または引用も深く感謝されるでしょう。

5
Javaでプリミティブvsクラスを使用する場合
Javaにはブール(クラス)対ブール(プリミティブ)があることがわかります。同様に、整数(クラス)対int(プリミティブ)があります。クラスに対してプリミティブバージョンを使用する場合のベストプラクティスは何ですか?特定の(パフォーマンス?)理由がない限り、基本的に常にクラスバージョンを使用する必要がありますか?それぞれを使用する最も一般的で受け入れられている方法は何ですか?
54 java  class  usage 

5
クラスに関係のない関数はどこに置くべきですか?
私はクラスの一部として使用するために最初に書いた数学関数の束があるC ++プロジェクトに取り組んでいます。もっとコードを書いているうちに、どこでもこれらの数学関数が必要だと気づきました。 それらを置くのに最適な場所はどこですか?私がこれを持っているとしましょう: class A{ public: int math_function1(int); ... } そして、私が別のクラスを書くとき、私はその他のクラスでそれを使用することはできません(または、少なくともその方法を知りません)math_function1。さらに、この関数の一部はクラスAに実際には関連していないことに気付きました。それらは最初のように見えましたが、今では数学関数であることがわかります。 この状況での良い習慣は何ですか?今、私はそれらを新しいクラスにコピー&ペーストしていますが、これは最悪のプラクティスだと確信しています。
47 c++  functions  class 

4
クラスを「静的」にする理由と時期 クラスの「静的」キーワードの目的は何ですか?
static多くの言語のメンバーのキーワードは、そのメンバーにアクセスできるようにするためにそのクラスのインスタンスを作成しないことを意味します。ただし、クラス全体を作成する理由はありませんstatic。なぜ、私はクラスを作る必要があるときstatic? クラスを作るとどんなメリットがありstaticますか?つまり、静的クラスを宣言した後も、インスタンス化せずにアクセスしたいすべてのメンバーを静的として宣言する必要があります。 これは、たとえば、Math開発者のコ​​ーディング方法に影響を与えることなく、クラスを(静的ではなく)通常と宣言できることを意味します。言い換えれば、クラスを静的または通常にすることは、開発者にとっては透過的です。

4
静的クラスよりも非静的内部クラスを好むのはなぜですか?
この質問は、Javaでネストされたクラスを静的なネストされたクラスにするか、内部のネストされたクラスにするかです。私はこことStack Overflowを検索しましたが、この決定の設計への影響に関する質問は本当に見つかりませんでした。 私が見つけた質問は、静的なクラスと内部のネストされたクラスの違いについて尋ねていることです。ただし、Javaで静的にネストされたクラスを使用する説得力のある理由はまだ見つかりませんでした。匿名クラスを除き、この質問では考慮していません。 静的なネストされたクラスを使用した場合の影響についての私の理解は次のとおりです。 結合の減少:クラスは外部クラスの属性に直接アクセスできないため、一般的に結合が減少します。一般に、結合が少ないということは、コードの品質の向上、テストの容易化、リファクタリングなどを意味します。 シングルClass:クラスローダーは毎回新しいクラスを処理する必要はなく、外側のクラスのオブジェクトを作成します。同じクラスの新しいオブジェクトを何度も取得するだけです。 内部クラスの場合、一般に、人々は外部クラスの属性へのアクセスをプロと考えることがわかります。この直接アクセスは高いカップリングを意味し、ネストされたクラスを別のトップレベルクラスに抽出したい場合は、本質的に向きを変えた後にのみ行うことができるため、デザインの観点からこの点で異なるようにお願いします静的なネストされたクラスに入れます。 したがって、私の質問はこれに帰着します:非静的内部クラスに利用可能な属性アクセスが高い結合につながり、したがってコード品質が低下すると仮定するのは間違っていますか、これから(非匿名)ネストされたクラスが一般的に静的ですか? または言い換えると:ネストされた内部クラスを好む理由は納得できますか?

4
私のコードで「マネージャー」を避ける方法
この質問は、Software Engineering Stack Exchangeで回答できるため、Code Review Stack Exchangeから移行されました。 6年前に移行され ました。 現在、C ++向けにEntity Systemを再設計しています。多くのマネージャーがいます。私の設計では、ライブラリを結合するためにこれらのクラスがあります。「マネージャー」クラスに関しては、多くの悪いことを聞いたことがあります。おそらく、クラスに適切な名前を付けていません。しかし、他にどのような名前を付けるべきかはわかりません。 私のライブラリーのほとんどのマネージャーは、これらのクラスで構成されています(ただし、多少異なります)。 コンテナ-マネージャ内のオブジェクトのコンテナ 属性-マネージャー内のオブジェクトの属性 ライブラリの新しいデザインには、ライブラリを結び付けるために、これらの特定のクラスがあります。 ComponentManager-エンティティシステムのコンポーネントを管理します ComponentContainer コンポーネント属性 シーン*-シーンへの参照(以下を参照) SystemManager-エンティティシステム内のシステムを管理します SystemContainer シーン*-シーンへの参照(以下を参照) EntityManager-エンティティシステム内のエンティティを管理します EntityPool-エンティティのプール EntityAttributes-エンティティの属性(これはComponentContainerおよびSystemクラスのみがアクセス可能です) シーン*-シーンへの参照(以下を参照) シーン-すべてのマネージャーを結び付ける ComponentManager SystemManager EntityManager Sceneクラス自体にすべてのコンテナ/プールを配置することを考えていました。 すなわち これの代わりに: Scene scene; // create a Scene // NOTE: // I technically could wrap this line in …

1
定数クラスを作成するためのベストプラクティスを提案する
この質問は、Software Engineering Stack Exchangeで回答できるため、Code Review Stack Exchangeから移行されました。 5年前に移行され ました。 定数クラスの宣言については、私のチームメンバーの間で議論があります。定数変数を以下のような別のクラスに移動しています。 public class Constants { public const string StateId = "ST"; public const string CountryId = "CI"; } 私のチームメンバーの何人かは、オーバーライドオプションを回避するためにクラスを封印済みとして宣言することを提案しました。また、定数クラスのインスタンス作成を回避するために静的としてマークすることを提案する人もいます。 ただし、将来の必要に応じて読み取り専用変数を初期化するのに役立つため、静的コンストラクターでSealedとして使用することを好みます。これに関するアドバイスをお願いします。
25 c#  class 


5
純粋に機能的な言語はモジュール性をどのように処理しますか?
私は、オブジェクト指向のバックグラウンドから来ました。そこでは、クラスを使用して、少なくともオブジェクトを作成するために使用するか、継承で使用できるコードの簡単なリサイクルを可能にする抽象化層を作成することができます。 たとえば、動物のクラスを持つことができ、そこから猫と犬を継承し、すべてが同じ特性を多く継承し、それらのサブクラスから動物の品種または名前を指定できるオブジェクトを作成できますそれの。 または、クラスを使用して、わずかに異なるものを処理または含む同じコードの複数のインスタンスを指定できます。検索ツリーまたは複数の異なるデータベース接続のノードとそうでないもの。 私は最近関数型プログラミングに移行しているので、私は疑問に思い始めて いました。つまり、クラスとオブジェクトの概念のない言語です。


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