In general, SOLID principles are usually met (See Snowman's answer)

But since you mentioned the Android SDK, I will go a little into detail on how SOLID principles coming too short in this particular API.

Single responsibility principle. The View class is responsible for

• positioning
• drawing
• event processing
• handling a huge load of other callbacks.

So, if you consider the SRP as "A class should only have one reason to change" - you already lost the argument. They tried it by creating ViewGroup and making the ListView use an Adapter for the actual data. These things actually work quite well.

Open closed principle. Although basically open for extension, unfortunately only via inheritance. There's no way no modify behavior (e.g something in the drawing or layouting process) via strategy-pattern or something similar. Everything is a constant, so you have to choose between the existing options.

Liskov substitution principle is of course met via the java language requirements. I do remember though, that we had issues with TextView or EditText in the past, were the inherited method returned the same type and was named the same; behaved differently anyway. The post-condition wasn't met. Too bad I don't remember exactly what it was. Something with the Focus or same properties having different result or something.

Interface segregation. What should I say? The basic View interface is polluted with methods over methods. Why is the scrolling implemented (and accessed) via the View class? Remember the callbacks I mentioned before? But in general, if you're trying to "implement" the View "interface" (extending the class) you only need override the methods you really need - but this is more like a language feature in java. If you see it more pedantically, you'll actually implement scrolling by overriding the class even if you don't need it.

Dependency inversion seems to be ok in android. But I'm sure that if you really search for it, you'll find enough spots in the framework were something depends on an implementation instead of an abstraction. I'm not sure whether the 34 instanceof calls in the View class are a sign of good abstractions.

In general, the android sdk tries its best fulfilling all principles. I also know that it's fairly large and also needs to take performance into account, so it's harder to make it fulfill all principles.

I should add, that I probably wouldnt be able to do any better.

In general, SOLID principles are usually met (See Snowman's answer)

But since you mentioned the Android SDK, I will go a little into detail on how SOLID principles coming too short in this particular API.

Single responsibility principle. The View class is responsible for

• positioning
• drawing
• event processing
• handling a huge load of other callbacks.

So, if you consider the SRP as "A class should only have one reason to change" - you already lost the argument. They tried it by creating ViewGroup and making the ListView use an Adapter for the actual data. These things actually work quite well.

Open closed principle. Although basically open for extension, unfortunately only via inheritance. There's no way no modify behavior (e.g something in the drawing or layouting process) via strategy-pattern or something similar. Everything is a constant, so you have to choose between the existing options.

Liskov substitution principle is of course met via the java language requirements. I do remember though, that we had issues with TextView or EditText in the past, were the inherited method returned the same type and was named the same; behaved differently anyway. The post-condition wasn't met. Too bad I don't remember exactly what it was. Something with the Focus or same properties having different result or something.

Interface segregation. What should I say? The basic View interface is polluted with methods over methods. Why is the scrolling implemented (and accessed) via the View class? Remember the callbacks I mentioned before? But in general, if you're trying to "implement" the View "interface" (extending the class) you only need override the methods you really need - but this is more like a language feature in java. If you see it more pedantically, you'll actually implement scrolling by overriding the class even if you don't need it.

Dependency inversion seems to be ok in android. But I'm sure that if you really search for it, you'll find enough spots in the framework were something depends on an implementation instead of an abstraction. I'm not sure whether the 34 instanceof calls in the View class are a sign of good abstractions.

In general, the android sdk tries its best fulfilling all principles. I also know that it's fairly large and also needs to take performance into account, so it's harder to make it fulfill all principles.

I should add, that I probably wouldnt be able to do any better.

In general, SOLID principles are usually met (See Snowman's answer)

But since you mentioned the Android SDK, I will go a little into detail on how SOLID principles coming too short in this particular API.

Single responsibility principle. The View class is responsible for

• positioning
• drawing
• event processing
• handling a huge load of other callbacks.

So, if you consider the SRP as "A class should only have one reason to change" - you already lost the argument. They tried it by creating ViewGroup and making the ListView use an Adapter for the actual data. These things actually work quite well.

Open closed principle. Although basically open for extension, unfortunately only via inheritance. There's no way no modify behavior (e.g something in the drawing or layouting process) via strategy-pattern or something similar. Everything is a constant, so you have to choose between the existing options.

Liskov substitution principle is of course met via the java language requirements. I do remember though, that we had issues with TextView or EditText in the past, were the inherited method returned the same type and was named the same; behaved differently anyway. The post-condition wasn't met. Too bad I don't remember exactly what it was. Something with the Focus or same properties having different result or something.

Interface segregation. What should I say? The basic View interface is polluted with methods over methods. Why is the scrolling implemented (and accessed) via the View class? Remember the callbacks I mentioned before? But in general, if you're trying to "implement" the View "interface" (extending the class) you only need override the methods you really need - but this is more like a language feature in java. If you see it more pedantically, you'll actually implement scrolling by overriding the class even if you don't need it.

Dependency inversion seems to be ok in android. But I'm sure that if you really search for it, you'll find enough spots in the framework were something depends on an implementation instead of an abstraction. I'm not sure whether the 34 instanceof calls in the View class are a sign of good abstractions.

In general, the android sdk tries its best fulfilling all principles. I also know that it's fairly large and also needs to take performance into account, so it's harder to make it fulfill all principles.

In general, SOLID principles are usually met (See Snowman's answer)

But since you mentioned the Android SDK, I will go a little into detail on how SOLID principles coming too short in this particular API.

Single responsibility principle. The View class is responsible for

• positioning
• drawing
• event processing
• handling a huge load of other callbacks.

So, if you consider the SRP as "A class should only have one reason to change" - you already lost the argument. They tried it by creating ViewGroup and making the ListView use an Adapter for the actual data. These things actually work quite well.

Open closed principle. Although basically open for extension, unfortunately only via inheritance. There's no way no modify behavior (e.g something in the drawing or layouting process) via strategy-pattern or something similar. Everything is a constant, so you have to choose between the existing options.

Liskov substitution principle is of course met via the java language requirements. I do remember though, that we had issues with TextView or EditText in the past, were the inherited method returned the same type and was named the same; behaved differently anyway. The post-condition wasn't met. Too bad I don't remember exactly what it was. Something with the Focus or same properties having different result or something.

Interface segregation. What should I say? The basic View interface is polluted with methods over methods. Why is the scrolling implemented (and accessed) via the View class? Remember the callbacks I mentioned before? But in general, if you're trying to "implement" the View "interface" (extending the class) you only need override the methods you really need - but this is more like a language feature in java. If you see it more pedantically, you'll actually implement scrolling by overriding the class even if you don't need it.

Dependency inversion seems to be ok in android. But I'm sure that if you really search for it, you'll find enough spots in the framework were something depends on an implementation instead of an abstraction. I'm not sure whether the 34 instanceof calls in the View class are a sign of good abstractions.

In general, the android sdk tries its best fulfilling all principles. I also know that it's fairly large and also needs to take performance into account, so it's harder to make it fulfill all principles.

I should add, that I probably wouldnt be able to do any better.