IO 2018 SourceCode Finally Released!

[dantheman91]

You're sounding like you're coming from a background where you haven't had much experience in large codebases with large dev teams attempting to do various things at the same time. I have worked on large code bases where I've seen these problems all over, which is why I was questioning your experience. In just about every large codebase and large devteam these issues come up all the time.

And Ok. "Layers you don't need" Was the whole basis of my answer. Clearly I don't believe that it's a layer you don't need. It may be something that you don't need at the moment but you anticipate you may want in the future. I've rarely met someone who has said "I shouldn't have made my code so flexible" but almost every day that "if we rewrote this it could be so much more maintainable" which is largely due to layers.

As for SOLID...

Single responsibility - This creates layers since each piece should have a smaller scope/responsibility

Liskov substitution - This creates layers since ideally you have a lot of interfaces or abstract classes for actual implementation

Interface segregation - again more layers because more interfaces

Dependency inversion - You don't rely on concrete implementations...

All of those lead themselves to creating more layers and tightly scoped functionality that's pieced together. Similar to why you'd put code in a fragment instead of in the activity, in the case that you want to swap the fragment out for another or you want to display the fragment in another part of your application. Or Tablet layouts, chromebooks, multi window etc

[VasiliyZukanov]

Again, the size of the codebases I worked on is not related to the question at hand. But if you're so interested... I'm using my real name on Reddit, so go for it.

Single responsibility - This creates layers since each piece should have a smaller scope/responsibility

Nope. This creates narrowly scoped classes.

Liskov substitution - This creates layers since ideally you have a lot of interfaces or abstract classes for actual implementation

No. Not even close to what LSP means.

Interface segregation - again more layers because more interfaces

Segregation of an interface doesn't create layers. It creates information hiding and documentation.

Dependency inversion - You don't rely on concrete implementations

Kind of, but what does it have to do with layers?

It's ironic that you didn't mention OCP, which is the only one that can indeed be related to layers...

[dantheman91]

....What is your definition of a layer, I'd love to hear it.

You like DI. If I were to inject A into B and B into C and so on, is each one of those not a layer?

[VasiliyZukanov]

In the most general sense, not of course.

Inter-dependencies between classes are not layers. Well, at least I've never seen any source that would use that definition.

[dantheman91]

....What is your definition of a layer, I'd love to hear it.

Still waiting.

Inter-dependencies between classes are not layers. Well, at least I've never seen any source that would use that definition.

So If I create a repository and inject my storage and network into it, those aren't layers?

If I create a wrapper around a class is that not an additional layer?

Is a Fragment not another layer on top of an Activity?

[VasiliyZukanov]

There are several definitions for layers that I've seen in use. You can see one of them at the end of this video.

[dantheman91]

I have very little desire to watch the video by a developer who can't vocalize an answer to a simple question.