問題タブ [anti-patterns]

2つの並列継承チェーンがあります。

私の経験では、並列継承階層は、成長するにつれてメンテナンスの頭痛の種になる可能性があります。

toXML(), toSoap(), toYAML()つまり、プリンシパルクラスにメソッドを追加しません。

関心の分離の概念を破ることなく、並列継承階層を回避するにはどうすればよいですか？

確かにあなたの何人かはこれに対処しました。これは、プログラマーが OO に夢中になりすぎて、パフォーマンスやデータベースの存在を忘れた場合に発生する傾向があります。

たとえば、Email テーブルがあり、このプログラムで送信する必要があるとします。起動時に、送信する必要があるものを次のように探します。

これは、自分自身を繰り返さないという観点からは良いことですが、避けられない場合があり、次のようにする必要があります。

これの名前はありますか？

かなり大規模な Ruby アプリケーションでは、特定のオブジェクトが名前と ID などの 2 つの要素によって識別される状況があります。これらの値の型はそれぞれ多少異なる目的を果たしているため、厳密には同じではありません (ID と名前は別の場所に保持されます)。そのため、アプリケーション全体でさまざまな値 (ID、名前、オブジェクト) が渡されます。この状況は、特定の関数にどの型を渡す必要があるかが明確でないというバグにすでに悩まされているため、少なくともある程度は問題のように思えます。具体的な名前を付けたことは一度もありませんが、実際には、何年にもわたって多くのアプリケーションで同様の問題コードを見たことを思い出します。

型のない言語である Ruby では、C++ のように従来の型ベースの多相関数を使用できません。回避策として、同僚はしばしば次のようなコードを使用しています。

私たちのコードベース (イニシャライザだけでなく) の周りにこのコードが急増すると、私が「乱雑なポリモーフィズム」と呼ぶ結果になります。多くの場合は機能しますが、非常に不可解な状況が生じることもあります。

これについて 3 つの質問があります。

• アンチパターンとしてこれに正式な名前はありますか? 「乱雑なインターフェイス?」、「乱雑なポリモーフィズム?」または、他の何か？
• 人々はこれがどれほど悪いと思うでしょうか？
• これをリファクタリングする体系的な方法はありますか? 私たちが作成した多くのテストがこのルーズタイピングを使用しているため、テストと実装の両方を同時に変更する必要があり、通常のテストベースのリファクタリングの足場効果がないという、通常のリファクタリングでの課題です。この緩やかなポリモーフィズムを実際に「強化」し、コードをすぐに切り取るのではなく、関数に抽象化することができると思います。しかし、これは良い考えでしょうか？

これは少しアンチパターンかもしれませんが、C# クラスのプロパティが複数の値を受け入れることは可能ですか?

たとえば、Public int プロパティがあり、常に int を返したいとしますが、10 進数、整数、またはその他のデータ型を割り当てることによってプロパティを設定できるようにしたいとします。私の質問は、プロパティが複数の値を受け入れることができるかどうかです。

以前に見たパターンに出くわしたので、それについて意見を求めたいと思いました。問題のコードには、次のようなインターフェースが含まれます。

そして、予想される使用法は次のようになります。

これにはいくつかの理由があります。setText(...) と getOc​​curances(...) が存在するのは、データに対して同じ高価な分析を行った後に実行したいクエリが複数あるためですが、これは結果クラスにリファクタリングできます。

これが悪いと思う理由: 実装は、インターフェイスによって明確に示されていない方法で状態を保存しています。また、「prepareResult」を呼び出してから「getResult」を呼び出す必要があるインターフェースを含む同様のものを見てきました。さて、これらの機能のいくつかを採用した、適切に設計されたコードを思いつくことができます。Hadoop Mapper インターフェースは、JobConfigurable と Closeable を拡張しますが、これらのインターフェースを実装するユーザー コードを使用するフレームワークであるのに対し、複数の実装を持つ可能性のあるサービスであるため、大きな違いが見られます。呼び出す必要がある「close」メソッドを含めることに関連するものはすべて正当化されると思います。これを行うための合理的な方法は他にないからです。JDBC のように、これは漏れやすい抽象化の結果である場合もありますが、私が考えている 2 つのコードでは、

私の質問は次のとおりです。

1. 誰もがこれが貧弱に設計されたインターフェースであることに同意しますか?
2. これは記述されたアンチパターンですか?
3. この種の初期化はインターフェイスに属しますか?
4. 私は機能的なスタイルと不変性を好むので、これは私には間違っているように思えますか?

これが名前に値するほど一般的である場合は、インターフェイスが本質的にステートフルではない場合 (コレクションのように)、特定の順序で複数のメソッドを呼び出すことを強制するインターフェイスの「シークレット ハンドシェイク」アンチ パターンをお勧めします。

鈍器としての PHP

最近、PHP が頻繁にバッシングされていると聞きます。かなりの数のプロジェクトで、非常識な php コード ベースを見てきました。非常に残念なことに、コードを書いたときにその人が幻覚剤を飲んでいたのではないかと思います。ときどき、最初の開発者が何をすべきでないかについてもう少しガイダンスがあれば、コードはどのようになっていただろうかと思います。

しかし、私は、100% OOP で作成された非常によく組織化された PHP プロジェクトをいくつか見てきましたが、それらは「php プログラマー」によって書かれたものではなく、維持するのが楽しいものでした。

私はすべての若手開発者にJava Anti-Patternsへのリンクを提供します。このページの良い点の 1 つは、Java 固有の例です。Java には、よくある間違いを起こしやすい多くの機能があるからです。php の同様のリストを見つけたいと思っていましたが、Google 検索では意味のあるものは何も見つかりませんでした。

開発者が PHP をプログラミングする際に知っておくべきことについて、すでにいくつかの質問がありますが、私は否定的な点に焦点を当てたいと思いました。

PHP でよく見られる避けるべきことは何ですか? また、同じことをより良い方法で行うための一般的な解決策は何ですか?

言及されると思われるがPHP固有ではないいくつかの明白な例：

• SQL を連結しないでください。準備ステートメントまたは適切なエスケープを使用します。
• やみくもに PHP を HTML に埋め込まないでください。テンプレート/MVC を使用してください。
• フィルタリングされていない生のユーザー入力をやみくもに投稿しないでください - XSS攻撃のためにそれをスクラブしてください。
• すべての POST と GET を手動で解析しようとしないでください。Web フレームワークを使用してください。

以下は、PHP 固有のものと考えられるいくつかの例です。

• ファイルのインクルード/リンクを必要とする層が多すぎないようにし、条件付きリンクを避けるようにしてください。むしろ、適切な命名規則を持ち、組織と一貫性を保つようにしてください。
• あなたがそれを助けることができない限り、PHP の生のデータベース API を使用しないでください。代わりに、 ADODBのようなデータベース フレームワークを使用してください。
• ある場所では変数を文字列に設定し、別の場所ではブール値に設定して、ブール値のテストが意味を成すことを期待して、PHP の動的型付けを過度に使用しないでください。

では、あなたの好きな PHP の禁止事項と、それを正しく行う方法を教えてください。

高可用性とディザスタリカバリに関してJavaアプリケーションの最悪の慣行を監査する必要がある場合は、ハードコードされたIPアドレスとバインドハンドルの最適ではないキャッシングを探すことになるでしょう。他に何を考慮する必要がありますか？

ウィキペディアのソフト コーディング アンチパターンに関するエントリは、簡潔で紛らわしいものでした。ソフトコーディングとは？どのような設定で悪い習慣 (アンチパターン) になりますか? また、それが有益であると考えられるのはいつですか?もしそうなら、どのように実装すべきですか?