タグ付けされた質問 「static-access」

7
(Javaとは異なり)静的データメンバーをC ++でクラスの外部で個別に定義する必要があるのはなぜですか?
class A { static int foo () {} // ok static int x; // <--- needed to be defined separately in .cpp file }; A::x.cppファイル(またはテンプレート用の同じファイル)で個別に定義する必要はありません。A::x同時に宣言と定義ができないのはなぜですか? 歴史的な理由で禁止されていますか? 私の主な質問は、staticデータメンバが同時に宣言/定義された場合(Javaと同じ)、機能に影響しますか?

3
静的メソッドを持つ静的クラスはSOLIDと見なされますか?
SOLIDには、 「プログラム内のオブジェクトは、そのプログラムの正確性を変更することなく、サブタイプのインスタンスで置き換えられるべきである」という概念を持つLiskov置換原則が含まれています。 静的メソッド(Mathクラスに少し似ている)を持つ静的クラスにはインスタンスがまったくないため、静的メソッドを持つ静的クラスがある場合、システムはSOLIDと見なされますか?

4
Java-完全に静的なクラスを持つことは悪い考えですか?
私は現在、より大きなソロプロジェクトに取り組んでおり、インスタンスを作成する理由がわからないクラスがいくつかあります。 たとえば、現在のダイスクラスはすべてのデータを静的に格納し、そのメソッドもすべて静的です。サイコロを転がして新しい値を取得したいときは、を使用するだけなので、初期化する必要はありませんDice.roll()。 私はこのような主な機能を1つだけ持っているいくつかの類似したクラスを持ち、すべてのイベントを担当する一種の「コントローラー」クラスで作業を開始しようとしています(プレイヤーが移動したとき、そうです)、このクラスでも同じ考えに従うことができることがわかりました。これらの特定のクラスに対して複数のオブジェクトを作成する予定はないので、それらを完全に静的にすることは悪い考えでしょうか? Javaに関しては、これが「悪い習慣」と見なされるのかと思っていました。私が見たものから、コミュニティはこのトピックに関して一種の分裂のように思われますか?とにかく、私はこれに関するいくつかの議論が大好きだし、リソースへのリンクも素晴らしいでしょう!

1
PHPに静的プロパティをオーバーロードする機能がないのはなぜですか?
イントロ PHPでは、クラスでマジックメソッドを宣言することにより、メソッド呼び出しとプロパティアクセスをオーバーロードできます。これにより、次のようなコードが有効になります。 class Foo { public function __get($name) { return 42; } } $foo = new Foo; echo $foo->missingProperty; // prints "42" インスタンスのプロパティとメソッドのオーバーロードとは別に、PHP 5.3.0以降でstaticは、マジックメソッドをオーバーライドすることでメソッド呼び出しをオーバーロードすることもできます__callStatic。 何かが足りない 利用可能な機能から目立って欠けているのは、静的プロパティをオーバーロードする機能です。たとえば: echo Foo::$missingProperty; // fatal error: access to undeclared static property この制限は明確に文書化されています。 プロパティのオーバーロードは、オブジェクトコンテキストでのみ機能します。これらのマジックメソッドは、静的コンテキストではトリガーされません。したがって、これらのメソッドは宣言しないでくださいstatic。PHP 5.3.0以降、マジックオーバーロードメソッドの1つが宣言されている場合、警告が発行されstaticます。 しかし、なぜ? 私の質問は: この機能が現在サポートされていないという技術的な理由はありますか?それとも、(震え)政治的な理由ですか? 過去にこの機能を追加する試みが中止されたことはありますか? 最も重要なことは、質問は「ユーザーランドPHPで動的な静的プロパティをどのように設定できますか?」ではありません。とはいえ__callStatic、共有したいことに基づいて特にかわいい実装を知っている場合は、ぜひ共有してください。

2
Staticは悪いですが、Factoryパターンはどうですか?
私はTDDプロジェクトに参加しているので、この種の開発に関係する優れた慣行に可能な限りこだわります。それらの1つは、静的およびグローバルを可能な限り回避することです。 私はこの問題に直面しています。「オプション」(追加の「マイクロ記事」)をリンクできるオブジェクト「記事」があります。 私はすべてが非常に切り離されているため、基本的にオブジェクトごとに1つのクエリを作成する必要があるため、非生産的であるか、あまり多くのクエリを生成しない良いアプローチを持つ方法を理解することはできません。 私の実際の観点から、3つのオプションがあります。 1)記事内のビルド: class Article { //[...] public function getArrOption(){ //Build an array of Options instance. //return an array of Options. } } プロ:まっすぐ進む 定数:保守性:articleオブジェクトには、Optionオブジェクトの構築ロジックが含まれるようになりました。これはおそらくコードの重複につながります。 2)optionFactoryを使用する class Article { //[...] public function getArrOption(){ return OptionFactory::buildFromArticleId($this->getId()); } } プロ:ロジックの構築はArticleクラスの外にありません Const:「静的なモックは難しい」というルールを破り、Articleクラスのテストを難しくしています。 3)すべてのロジックを分離します。 //Build the array of Option instance in a …
13 php  tdd  static-access 

2
多数のコンポーネントで使用される「グローバル」構成クラスを作成するためのベストプラクティス
ドライバーパーツと、さまざまな関連タスクを実行する約5つのライブラリーを持つ大規模なプロジェクトがあります。ライブラリの多くは、起動時にドライバーコードによってデータベースから読み取られる「グローバル」構成データへのアクセスを必要とします。ドライバーとは、メイン機能を含む部分を意味します。 これを処理する方法についての私の考えは、構成項目を取得する静的メソッドを使用して構成クラスを作成することでした。これは最善の方法ですか?他にどのようにこれを達成できますか? 例えば: class config { public: static get_item(key); private: static values; }; シングルトン設計はここで適切ですか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.