{"id":423,"date":"2026-07-02T13:10:37","date_gmt":"2026-07-02T13:10:37","guid":{"rendered":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/?p=423"},"modified":"2026-07-02T13:17:36","modified_gmt":"2026-07-02T13:17:36","slug":"dependency-inversion-principle","status":"publish","type":"post","link":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/2026\/07\/02\/dependency-inversion-principle\/","title":{"rendered":"Dependency Inversion Principle"},"content":{"rendered":"\n

Depend on Abstractions, Not on Concrete Implementations<\/h4>\n\n\n\n

The Dependency Inversion Principle (DIP)<\/strong>, the fifth and final principle of SOLID, states that:<\/p>\n\n\n\n

\n

\u201cHigh-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.\u201d \u2014 Robert C. Martin<\/p>\n<\/blockquote>\n\n\n\n

Let’s break this into two separate statements because each carries its own important meaning.<\/p>\n\n\n\n

First Statement<\/h5>\n\n\n\n

High-level modules (those containing business logic) should not depend directly on low-level modules (those handling technical details such as database access or email delivery).<\/p>\n\n\n\n

Instead, both layers should depend on abstractions, such as interfaces or abstract classes.<\/p>\n\n\n\n

Second Statement<\/h5>\n\n\n\n

Abstractions themselves should not know about implementation details.<\/p>\n\n\n\n

Instead, implementation details should conform to the contract defined by the abstraction.<\/p>\n\n\n\n

Simply Put<\/h5>\n\n\n\n

Do not import concrete implementations where an interface is sufficient.<\/strong><\/p>\n\n\n\n

Real-Life Example: How to Understand It?<\/h4>\n\n\n\n

Imagine ordering food for home delivery.<\/p>\n\n\n\n

You do not call a delivery driver directly. Instead, you call a restaurant and place an order.<\/p>\n\n\n\n

The restaurant knows it needs someone capable of delivering the food to your address.<\/p>\n\n\n\n

It does not matter which courier performs the delivery. What matters is that every courier can pick up the package and deliver it successfully.<\/p>\n\n\n\n

Now imagine you insist that only one specific courier can deliver your food.<\/p>\n\n\n\n

If that courier gets sick, quits the job, or is unavailable, you do not receive your meal.<\/p>\n\n\n\n

You have become dependent on a specific person instead of the role that person fulfills.<\/p>\n\n\n\n

Programming works the same way.<\/p>\n\n\n\n

That “role” is an interface\u2014an abstraction.<\/p>\n\n\n\n

The restaurant (business logic) does not know anything about the individual courier (the concrete class).<\/p>\n\n\n\n

It only knows that it needs someone who fulfills the role of a courier: picking up and delivering packages.<\/p>\n\n\n\n

A Thought Exercise<\/h5>\n\n\n\n

Imagine an OrderProcessor<\/code> class responsible for processing orders in an online store.<\/p>\n\n\n\n

To complete an order, it must save data somewhere.<\/p>\n\n\n\n

If OrderProcessor<\/code> directly creates an instance of MySQLOrderRepository<\/code>, then you are effectively calling the courier directly.<\/p>\n\n\n\n

What happens when you decide to switch to PostgreSQL, MongoDB, or file-based storage for tests?<\/p>\n\n\n\n

You must modify a class that should focus on business logic, not infrastructure details.<\/p>\n\n\n\n

That is exactly the problem DIP solves.<\/p>\n\n\n\n

Example \u2014 DIP Violation<\/h4>\n\n\n\n

Suppose we are building a notification system for an e-commerce platform.<\/p>\n\n\n\n

The NotificationService<\/code> class sends notifications to customers after they place an order.<\/p>\n\n\n\n

Someone unfamiliar with DIP might write something like this:<\/p>\n\n\n\n

\n

“I need to send emails, so I’ll use EmailSender<\/code>.”<\/p>\n<\/blockquote>\n\n\n

<\/pre>\n
\/\/ Low-level class \u2014 concrete implementation<\/div>\n
class EmailSender {<\/div>\n
\u00a0<\/pre>\n
\u00a0\u00a0\u00a0 public void send(String recipient, String message) {<\/div>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \/\/ technical detail: sending email via SMTP<\/div>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 System.out.println(“Sending email to: ” + recipient);<\/div>\n
\u00a0\u00a0\u00a0 }<\/div>\n
}<\/div>\n\n
<\/pre>\n
\/\/ High-level class \u2014 business logic<\/div>\n
class NotificationService {<\/div>\n
\u00a0<\/pre>\n
\u00a0\u00a0\u00a0 \/\/ Dependency on a CONCRETE IMPLEMENTATION<\/div>\n
\u00a0\u00a0\u00a0 private EmailSender emailSender = new EmailSender();<\/div>\n
\u00a0<\/pre>\n
\u00a0\u00a0\u00a0 public void notifyUser(String userEmail, String orderInfo) {<\/div>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 emailSender.send(<\/div>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 userEmail,<\/div>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “Your order: ” + orderInfo<\/div>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 );<\/div>\n
\u00a0\u00a0\u00a0 }<\/div>\n
}<\/div>\n\n\n
At first glance, the code appears reasonable.<\/p>\n\n\n\n
However, let’s see what happens when requirements change\u2014which they always do in real projects.<\/p>\n\n\n\n
Scenario 1: Add SMS Notifications<\/h5>\n\n\n\n
The business wants to support SMS notifications in addition to email.<\/p>\n\n\n\n
To achieve this, we must modify NotificationService<\/code>, even though the business logic itself has not changed.<\/p>\n\n\n\n
As a side effect, we are also moving toward violating SRP.<\/p>\n\n\n\n
Scenario 2: Unit Testing<\/h5>\n\n\n\n
In unit tests, we do not want to send real emails.<\/p>\n\n\n\n
Unfortunately, there is no easy way to replace EmailSender<\/code> with a mock because the class creates it internally with new<\/code>.<\/p>\n\n\n\n
Scenario 3: Multiple Email Providers<\/h5>\n\n\n\n
Suppose we want to support:<\/p>\n\n\n\n
    \n
  • SendGrid,<\/li>\n\n\n\n
  • Mailgun,<\/li>\n\n\n\n
  • an internal SMTP server.<\/li>\n<\/ul>\n\n\n\n
    Every provider change requires modifying NotificationService<\/code>, even though it should not care who actually sends emails.<\/p>\n\n\n\n
    Root Cause<\/h5>\n\n\n\n
    NotificationService<\/code> depends on a concrete implementation (EmailSender<\/code>) instead of depending on an abstraction.<\/p>\n\n\n\n
    Example \u2014 DIP-Compliant Design<\/h4>\n\n\n\n
    How do we fix this?<\/p>\n\n\n\n
    We introduce an abstraction: an interface that defines the contract:<\/p>\n\n\n\n
    \n
    “Anything capable of sending notifications can be used here.”<\/p>\n<\/blockquote>\n\n\n
    <\/pre>\n
    \/\/ Abstraction \u2014 the contract<\/div>\n
    interface NotificationSender {<\/div>\n
    \u00a0\u00a0\u00a0 void send(String recipient, String message);<\/div>\n
    }<\/div>\n\n\n
    Now low-level implementations depend on the abstraction:<\/p>\n\n\n
    <\/pre>\n
    class EmailSender implements NotificationSender {<\/div>\n
    \u00a0<\/pre>\n
    \u00a0\u00a0\u00a0 @Override<\/div>\n
    \u00a0\u00a0\u00a0 public void send(String recipient, String message) {<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 System.out.println(<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “Email to: ” + recipient +<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ” | ” + message<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 );<\/div>\n
    \u00a0\u00a0\u00a0 }<\/div>\n
    }<\/div>\n\n\n
    <\/p>\n\n\n
    <\/p>\n
    class SmsSender implements NotificationSender {<\/div>\n
    \u00a0<\/p>\n
    \u00a0\u00a0\u00a0 @Override<\/div>\n
    \u00a0\u00a0\u00a0 public void send(String recipient, String message) {<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 System.out.println(<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “SMS to: ” + recipient +<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ” | ” + message<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 );<\/div>\n
    \u00a0\u00a0\u00a0 }<\/div>\n
    }<\/div>\n\n\n
    The high-level module also depends on the abstraction:<\/p>\n\n\n
    <\/pre>\n
    class NotificationService {<\/div>\n
    \u00a0<\/pre>\n
    \u00a0\u00a0\u00a0 private final NotificationSender sender;<\/div>\n
    \u00a0<\/pre>\n
    \u00a0\u00a0\u00a0 \/\/ Dependency Injection<\/div>\n
    \u00a0\u00a0\u00a0 public NotificationService(<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 NotificationSender sender) {<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 this.sender = sender;<\/div>\n
    \u00a0\u00a0\u00a0 }<\/div>\n
    \u00a0<\/pre>\n
    \u00a0\u00a0\u00a0 public void notifyUser(<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 String userContact,<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 String orderInfo) {<\/div>\n
    \u00a0<\/pre>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 sender.send(<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 userContact,<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “Your order: ” + orderInfo<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 );<\/div>\n
    \u00a0\u00a0\u00a0 }<\/div>\n
    }<\/div>\n\n\n
    Usage<\/h5>\n\n\n\n
    public class Main {<\/div>\n
    \u00a0<\/p>\n
    \u00a0\u00a0\u00a0 public static void main(String[] args) {<\/div>\n
    \u00a0<\/p>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 NotificationSender emailSender =<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 new EmailSender();<\/div>\n
    \u00a0<\/p>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 NotificationService serviceA =<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 new NotificationService(emailSender);<\/div>\n
    \u00a0<\/p>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 serviceA.notifyUser(<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “john@example.com”,<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “#12345”<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 );<\/div>\n
    \u00a0<\/p>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 NotificationSender smsSender =<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 new SmsSender();<\/div>\n
    \u00a0<\/p>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 NotificationService serviceB =<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 new NotificationService(smsSender);<\/div>\n
    \u00a0<\/p>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 serviceB.notifyUser(<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “+48 600 000 000”,<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “#12346”<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 );<\/div>\n
    \u00a0\u00a0\u00a0 }<\/div>\n
    }<\/div>\n\n\n
    What Changed?<\/h4>\n\n\n\n
    1. We Introduced an Interface<\/h5>\n\n\n\n
    NotificationSender<\/code> defines the contract.<\/p>\n\n\n\n
    Any notification sender must implement it.<\/p>\n\n\n\n
    2. We Removed Object Creation from Business Logic<\/h5>\n\n\n\n
    NotificationService<\/code> no longer creates dependencies using new<\/code>.<\/p>\n\n\n\n
    Dependencies are provided externally.<\/p>\n\n\n\n
    This technique is called Dependency Injection (DI)<\/strong>.<\/p>\n\n\n\n
    DIP is the principle. DI is a common technique used to implement it.<\/strong><\/p>\n\n\n\n
    3. New Communication Channels Are Easy to Add<\/h5>\n\n\n\n
    Want:<\/p>\n\n\n\n
      \n
    • push notifications,<\/li>\n\n\n\n
    • Slack messages,<\/li>\n\n\n\n
    • Microsoft Teams notifications,<\/li>\n\n\n\n
    • WhatsApp alerts?<\/li>\n<\/ul>\n\n\n\n
      Simply create another implementation of NotificationSender<\/code>.<\/p>\n\n\n\n
      No changes are required in NotificationService<\/code>.<\/p>\n\n\n\n
      4. Testing Becomes Easy<\/h5>\n\n\n\n
      Tests can inject a fake sender instead of a real implementation.<\/p>\n\n\n\n
      Why Is DIP Important?<\/h4>\n\n\n\n
      Flexibility and Replaceable Implementations<\/h5>\n\n\n\n
      When business logic is isolated from technical details, changing:<\/p>\n\n\n\n
        \n
      • databases,<\/li>\n\n\n\n
      • notification channels,<\/li>\n\n\n\n
      • external APIs,<\/li>\n<\/ul>\n\n\n\n
        does not require changing the business logic itself.<\/p>\n\n\n\n
        It is like replacing a light bulb while keeping the same socket.<\/p>\n\n\n\n
        Better Testability<\/h5>\n\n\n\n
        This is one of the biggest practical benefits.<\/p>\n\n\n\n
        When a class depends on an interface, tests can inject a mock object rather than using the real implementation.<\/p>\n\n\n\n
        class MockSender implements NotificationSender {<\/div>\n
        \u00a0<\/p>\n
        \u00a0\u00a0\u00a0 public List<String> sent =<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 new ArrayList<>();<\/div>\n
        \u00a0<\/p>\n
        \u00a0\u00a0\u00a0 @Override<\/div>\n
        \u00a0\u00a0\u00a0 public void send(<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 String recipient,<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 String message) {<\/div>\n
        \u00a0<\/p>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 sent.add(recipient);<\/div>\n
        \u00a0\u00a0\u00a0 }<\/div>\n
        }<\/div>\n\n\n
        No emails are sent.<\/p>\n\n\n\n
        No external systems are contacted.<\/p>\n\n\n\n
        The business logic is tested in isolation.<\/p>\n\n\n\n
        Fewer Team Conflicts<\/h5>\n\n\n\n
        When dependencies are based on interfaces, different developers can work independently on:<\/p>\n\n\n\n
          \n
        • NotificationService<\/code>,<\/li>\n\n\n\n
        • EmailSender<\/code>,<\/li>\n\n\n\n
        • SmsSender<\/code>.<\/li>\n<\/ul>\n\n\n\n
          The interface acts as a contract between teams.<\/p>\n\n\n\n
          Long-Term Benefits<\/h5>\n\n\n\n
          Large projects that ignore DIP often evolve into what engineers call:<\/p>\n\n\n\n
          \n
          “spaghetti dependencies”<\/p>\n<\/blockquote>\n\n\n\n
          A tangled network of concrete class dependencies.<\/p>\n\n\n\n
          Every modification creates a chain reaction.<\/p>\n\n\n\n
          Refactoring becomes dangerous.<\/p>\n\n\n\n
          Testing becomes difficult.<\/p>\n\n\n\n
          New developers may need weeks to understand the dependency graph.<\/p>\n\n\n\n
          DIP is an investment whose value grows alongside the size of the project.<\/p>\n\n\n\n
          When Should You Apply DIP?<\/h4>\n\n\n\n
          When a Class Connects to External Resources<\/h5>\n\n\n\n
          Examples include:<\/p>\n\n\n\n
            \n
          • databases,<\/li>\n\n\n\n
          • external APIs,<\/li>\n\n\n\n
          • file systems,<\/li>\n\n\n\n
          • payment gateways,<\/li>\n\n\n\n
          • messaging services.<\/li>\n<\/ul>\n\n\n\n
            The implementation may change, but business logic should remain unaffected.<\/p>\n\n\n\n
            When You Want Unit-Testable Code<\/h5>\n\n\n\n
            If a class creates dependencies using:<\/p>\n\n\n\n
            new SomeService()<\/p>\n\n\n\n
            you cannot easily replace those dependencies during testing.<\/p>\n\n\n\n
            If dependencies are provided through constructors or setters, mocks become trivial to use.<\/p>\n\n\n\n
            In Frameworks That Already Use DIP<\/h5>\n\n\n\n
            Spring Framework is essentially DIP at industrial scale.<\/p>\n\n\n\n
            Its IoC (Inversion of Control) container creates objects and injects dependencies automatically.<\/p>\n\n\n\n
            Annotations such as:<\/p>\n\n\n
            <\/p>\n
            @Autowired<\/div>\n
            @Component<\/div>\n
            @Service<\/div>\n\n\n
            are mechanisms that support DIP.<\/p>\n\n\n
            <\/pre>\n
            @Service<\/div>\n
            public class OrderService {<\/div>\n
            \u00a0<\/pre>\n
            \u00a0\u00a0\u00a0 private final PaymentGateway paymentGateway;<\/div>\n
            \u00a0<\/pre>\n
            \u00a0\u00a0\u00a0 @Autowired<\/div>\n
            \u00a0\u00a0\u00a0 public OrderService(<\/div>\n
            \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 PaymentGateway paymentGateway) {<\/div>\n
            \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 this.paymentGateway = paymentGateway;<\/div>\n
            \u00a0\u00a0\u00a0 }<\/div>\n
            }<\/div>\n\n\n
            OrderService<\/code> depends on the PaymentGateway<\/code> interface, not on a concrete implementation.<\/p>\n\n\n\n
            Spring decides which implementation to inject.<\/p>\n\n\n\n
            The class does not need to know.<\/p>\n\n\n\n
            Similarly, Hibernate and JPA use abstractions such as repositories and the EntityManager<\/code> to separate business logic from database-specific details.<\/p>\n\n\n\n
            Memory Trick<\/h4>\n\n\n\n
            \n
            Depend on the contract, not on the contractor.<\/p>\n<\/blockquote>\n\n\n\n
            \n
            If you see new ConcreteService()<\/code> inside a business class, the implementation decision is probably being made in the wrong place.<\/p>\n<\/blockquote>\n\n\n\n
            \n
            Point upward to abstractions, not downward to details.<\/p>\n<\/blockquote>\n\n\n\n
            Summary<\/h4>\n\n\n\n
            DIP completes the SOLID principles.<\/p>\n\n\n\n
              \n
            • SRP<\/strong> says classes should have a single responsibility.<\/li>\n\n\n\n
            • OCP<\/strong> says software should be open for extension but closed for modification.<\/li>\n\n\n\n
            • LSP<\/strong> ensures subclasses can safely replace base classes.<\/li>\n\n\n\n
            • ISP<\/strong> promotes small, focused interfaces.<\/li>\n\n\n\n
            • DIP<\/strong> ties everything together by ensuring that high-level logic depends on stable abstractions rather than volatile implementation details.<\/li>\n<\/ul>\n\n\n\n
              Define a contract.<\/p>\n\n\n\n
              Depend on the contract.<\/p>\n\n\n\n
              Let implementation details serve the contract\u2014not control it.<\/p>\n","protected":false},"excerpt":{"rendered":"
              Depend on Abstractions, Not on Concrete Implementations The Dependency Inversion Principle (DIP), the fifth and final principle of SOLID, states that: \u201cHigh-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.\u201d \u2014 Robert C. Martin Let’s break this into two separate […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"saved_in_kubio":false,"footnotes":""},"categories":[12],"tags":[],"class_list":["post-423","post","type-post","status-publish","format-standard","hentry","category-solid"],"_links":{"self":[{"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/posts\/423","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/comments?post=423"}],"version-history":[{"count":3,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/posts\/423\/revisions"}],"predecessor-version":[{"id":428,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/posts\/423\/revisions\/428"}],"wp:attachment":[{"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/media?parent=423"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/categories?post=423"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/tags?post=423"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}