You are both right depending on your interpretation of “depends”… pun not intended.

If you interpret “depend” to mean “class B cannot exist without class A” then you are right: B depends on A. Typically, though, inheritance implies an “is a” relationship. Let’s give semi-meaningful names to classes A and B. Instead of “A” let us use “User”. Instead of B let us use “Manager”. When Manager extends User, we would typically say “Manager is a User.” When people speak about “dependencies” between classes, they are usually talking about object composition or aggregation.

While you could make an argument that inheritance is a form of dependency, we typically treat inheritance differently than class B having a pointer or reference to class A. This is a conceptual difference, in my opinion. Consider these code snippets in a situation where class A does not exist:

// inheritance
class B extends A {
}

// composition
class B {
    A a;

    B() {
        a = new A();
    }
}

// aggregation and dependency injection
class B {
    A a;

    B(A a) {
        this.a = a;
    }
}

In all three cases, if class A does not exist, then the code won’t compile. Clearly we have a dependency here in the most general sense of the word. Dependencies are about relationships between objects, and inheritance is a form of relationship between two classes. I think the difference in interpretations stems from how “dependency” is used in software engineering. Here we lean on the definition of dependency injection to help guide our understanding of what a “dependency” is.

In software engineering, dependency injection is a programming technique in which an object or function receives other objects or functions that it requires, as opposed to creating them internally.

^{Dependency injection, Wikipedia}

This puts us in the realm of aggregation, in the example above where an instance of A is passed to an instance of B as a constructor parameter. Similarly, composition implies two different objects (even though one object creates the other, they are still separate objects). Colloquially, I tend to use “dependency” to mean two separate objects that may or may not have an inheritance relationship where one object uses another. The two objects (A and B) are two different instances. This perspective is likely where your coworker differs.

The context of the conversation matters here, and this depends on how much you are generalizing the meaning of “dependency”. From my own experience working with other programmers, I use “dependency” in the same way that your coworker does. I don’t usually think of inheritance as a dependency between two classes unless I’m engaged in an academic discussion, such as this. The level of coupling is the distinguishing factor.

While inheritance defines a dependency between two classes, inheritance allows the child class to access protected members of the parent class. This intimate knowledge of the internals of the parent class is a much deeper form of coupling than the coupling allowed by composition or aggregation. Aggregation and composition only allow coupling to the public interface of a class (not the language construct “interface”, the public members of a class). This enables programmers to refactor the internals of A and B without affecting either class as long as the signatures of public methods are not affected.

Technically you are both correct, however I believe your coworker is using the more common definition of “dependency” here. If you describe inheritance to most programmers saying that B depends on A, then you will have this discussion over, and over, and over again. You are not incorrect. You are just using the word “depend” in a more general sense than most programmers do. We usually associate “depend” and “dependency” with two different objects holding references to each other while treating inheritance as something more constrained due to the tighter coupling between the parent and child class.

1. When B extends A, then B is an A (inheritance).
   • B has access to the protected members of A and is a deeper form of coupling.
2. When B holds a reference to A, then B uses an A. Now A is a dependency of B (and therefore B depends on A).
   • B only requires the public members of A and is a looser form of coupling than inheritance.

Does B extends A imply that B depends on A?

Believe it or not, this is an implementation detail of the language. I can prove it. Ever heard of single data inheritance?

Lets say we have a record of two ints. Call them x and y. This record we call A. Now lets also say we have a record of three ints. Call them x, y and z. This record we call B.

Clearly B is a A. Plus a z. But this is true even when B has never heard of A.

This is how the OSI stack works. A fully formed packet IS-A packet of many layers until you strip them off.

It’s just not how Java works. Not when we’re talking about classes.

It’s only when you define B in terms of A that a dependency is created. If I had defined B as an A with a z tacked on you’d get a dependent relationship because without knowing what an A is you’d have no idea what a B is.

That’s how Java works.

While you probably won’t convince your coworkers and not sure you should try (using non-standard terminology isn’t likely to work in your favor with others) I would argue this is a dependency every bit as much as in the classic sense because changes to A could affect or even break B so B is dependent on A’s API.

For example if I extend your Car class to make a SportsCar class under the assumption that your Car class will always have a gas engine because that’s what I want my SportsCar to have and unbeknownst to me you change your Car class to an electric engine, then when I update to use the newest version of your Class, my SportsCar class will be violating its own API’s contract, so Car is definitely a dependency of my SportsCar class.

Not sure why we don’t think of inheritance as creating a dependency but it does. That said most devs will look at you like you have three heads if you say this.

In semantical English, you are correct. However, a “dependency” has a very specific meaning in the software development world, and inheritance is not an example of such a dependency.

A dependency is an external component that is referenced within a class’ definition. This most commonly takes the shape of an injected A instance into B‘s constructor.

When you say “depends on”, the logical inference here is that you’re referring to a dependency as defined in the field of software engineering. When B inherits from A, that does not make A a dependency of B, and therefore “B depends on A” is not correct.

To meet you in the middle, I would say that it’s correct if you had said “B‘s class definition depends on A‘s class definition“, because this adequately distinguishes that you’re not just talking about dependencies in the software specific terminology.