What SOLID principles does the Java List interface challenge?

Interface Segregation Principle (ISP) is challenged because List was designed by people who had no idea what exactly your program needs (it's from a library) and so they threw together everything that might be needed from a List. It's rare for a program to need every method in it. Including more than you need in an interface violates ISP. Alternatives would be a hand rolled interface that communicates actual needs or simply narrower interfaces from the library (Iterable, Collection).

The Liskov Substitution Principle is challenged because ArrayList performs differently than LinkedList. Performance can impact correctness.

_{This claim has stirred some controversy. Please allow me to clarify:}

A correct program satisfies requirements. Performance can be a requirement. Performance is a behavior. LSP requires subtypes to have the same behavior in the context of a program p. Changing behavior violates LSP. It's up to you to decide if it's enough to care.

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T

wikipedia - LSP

LinkedList o1 = new LinkedList(); // Consider LinkedList type S
List o2 = new ArrayList(); // Consider List type T
MyProgram p = new MyProgram();
// Test if S is a subtype of T for P
compareBehavior(p, o1, o2); 

If you're thinking it's obvious that LinkedList is a List in the type system then you are missing the point. That isn't what LSP tests.

The LSP makes clear that in OOD the ISA relationship pertains to behavior. Not intrinsic private behavior, but extrinsic public behavior; behavior that clients depend upon.

objectmentor.com - LSP

Your languages type system simply can't test that for you. You have to check.

Consider program p that requires a List. But p was also written expecting ArrayList performance. That expectation is now required of every listy thing you pass to p. Not because the listy thing is a List in the type system. Because p demands it.

According to LSP whether o1 is a subtype of o2 isn't simply about if the type system is ok with the substitution that compareBehavior will make when it calls program p.run(o). It's about how p will behave. Whether that behavior is different with different objects.

That doesn't mean o2 must run identical code to o1. It means the externally visible behavior of that code must be identical.

And that includes performance.

And that maters if your requirements say it does.

And so correctness is impacted if it does.

And since this is my hypothetical example, it does.

It should be noted that the SOLID principles are simply warning signs that point to hidden costs that may be worth managing. Do not treat them as gospel or you'll find that every working program ever written is heretical. Forgive us lowly sinners.

• SRP is a bogus principle, as responsibility and count and scope thereof are free subjective parameters of design, chosen and assigned at will. Any program can be argued to have a single responsibilty, even if it does both Moon landings and fishing. Sure, mutability and state management are an additional responsibility, lets consider SRP violated, why not?
• OC is a bogus principle, because it does not define when a component should be extensible and what modification is. Sure lets consider OC violated, because collections are hard to meaningfully extend. No one modifes a standard library, so they are closed for modification for sure. Unless you are Oracle's Doctor Deprecator and eat SecurityManagers for breakfast.
• LSP is not a principle, it is a definition, nothing to violate here, unless you consider Java interface and its implementations to have a subtype relationship (which is not necessary).
• Interface segregation principle is a bogus principle, because it does not define how segregation is to be done. Sure, lets consider it violated, because mutability and indexed access are not segregated.
• Dependency inversion is not applicable, because there not a lot of dependencies in collections. Also, it does not define what is a dependency and what is implementation detail and where do they split.

In other words, each and every of these "principles" are uselessly vague enough to be both violated and not for any component under consideration. Uncle Bob should have just do quantum mechanics instead of education.

I hear a lot of noise - "this is just a recommendation", "a guide, not a rule", "use with care", "apply common sense", etc. I reply - if I need to be a qualified enough to distinguish when each principle applies and how to interpret omitted definitions, by that point I am surely qualified enough to make design decisions without refering to these principles at all.

As for lecture notes - please omit any principles that are not practically applicable or do not have a SOLID rationale.