SOLID

A: Absolutely! WordPress hooks (add_action, add_filter) are a perfect OCP implementation using procedural code. Your functions stay closed (working code), others extend via hooks (adding functionality). OOP adds more tools, but hooks alone achieve OCP beautifully.

A: Not at all. A simple array-based container handles 95% of cases. For larger plugins, consider PHP-DI or Pimple. But starting with constructor injection and interfaces is enough.

A: No! Overriding is fine as long as the contract is preserved. You can make behavior more specific, optimize performance, or add features — but you cannot break the promises the parent made (same return types, no new exceptions, same preconditions).

A: No, SRP is about responsibility, not file count. You can have multiple related functions in one file as long as they serve the same high-level responsibility. For example, all post validation functions can live in post-validation.php, while email functions go in email-notifications.php.

A: Partially. The Hooks API is an excellent abstraction layer — plugins depend on the hook system, not on core internals. But older WordPress code uses global functions and static calls heavily.

A: Initially yes, but it pays off as the project grows. Start simple – a few hooks are enough for small plugins. Add interfaces and abstract classes when you have 3+ similar implementations. The complexity is justified when it prevents breaking existing functionality while adding features.

A: Instead of one callback doing everything, create multiple focused callbacks. For example, on save_post, use separate functions for validation, notification, caching, and analytics — each attached to the same hook but handling one responsibility.

A: Ask yourself: “Can I replace every use of the parent class with this child class, without the tests failing or behavior changing?” If yes — you’re good. If any test breaks or you need to add instanceof checks — LSP is violated.

A: When you extend WP_Widget, your widget must implement widget(), form(), and update() correctly. If you override update() to return false always, you break WordPress’s expectation — an LSP violation.

A: Filters are a great example of LSP — any callback passed to apply_filters() must accept and return the same type. If a filter expects a string and you return an array, you’ve violated the contract — exactly like LSP.

A: OCP is crucial for plugin compatibility. If your plugin follows OCP (provides hooks), users can extend it safely. When you update, their extensions keep working because they’re not modifying your code. This is why editing vendor plugin files is dangerous – updates erase custom changes.

A: WordPress hooks are perfect for SRP! Each hook callback should handle one specific task. Use do_action() to notify other parts of your code about events, allowing different responsibilities to respond independently. This creates loose coupling and high cohesion.

A: Add hooks at logical extension points – before/after major operations, when data changes, or when rendering output. Follow WordPress core’s approach: do_action('before_save_'), apply_filters('the_content'), etc. Don’t overdo it – too many hooks make code hard to follow.

A: Yes, using inheritance purely for code reuse (without a real “is-a” relationship) is a warning sign. It often leads to LSP violations. Use traits or composition instead for code reuse, and reserve inheritance for true behavioral subtypes.

A: For tiny plugins (under 200 lines), it can be overkill. But once you have classes with external dependencies (email, cache, DB, APIs), DIP pays off immediately through testability and flexibility.

A: No, only functions that return data users might want to modify. Use filters for content transformation (apply_filters('post_title', $title)), use actions for event notifications (do_action('post_saved', $id)). Internal helper functions don’t need hooks.

A: Apply the Boy Scout Rule — “leave code better than you found it.” When you need to modify existing code, refactor that section to follow SRP. Don’t attempt massive rewrites, but gradually improve code as you work with it. Focus on new features being SRP-compliant from the start.

A: Even small sites benefit from SRP, but the implementation scale differs. For a simple blog, separating validation from email sending in your contact form is enough. You don’t need complex class hierarchies — simple, focused functions work great and make your theme easier to maintain as the site grows.

A: No, OCP is about adding features, not fixing bugs. Bug fixes are legitimate modifications. The principle means “don’t modify working code to add new features” – fixing broken code is different. After the fix, that code should be closed for new features again.

A: DIP is the principle — depend on abstractions, not concretions. Dependency Injection (DI) is a technique to achieve it — passing dependencies into a class rather than creating them inside.

A: No, modern PHP handles function calls efficiently. The real performance killer is poorly written monolithic code that does unnecessary work. Well-organized code following SRP is easier to optimize because you can identify and improve bottlenecks without touching unrelated functionality.