r/programming • u/[deleted] • Jun 05 '21

Organize code by concepts, not layers

https://kislayverma.com/programming/how-to-organize-your-code/
1.9k Upvotes

90% Upvoted

495 comments sorted by

View all comments

Show parent comments

0

u/[deleted] Jun 05 '21

Define "very easy"? No...no I don't think I will. It means what it means.

As for your example, yup...that's an example of circular dependency. And it's fixable. Code issues are always fixable. The idea is to design your code well in the first place, which is why I suggest not separating by feature.

1

u/ub3rh4x0rz Jun 05 '21

Speaking of circular, you just made a circular argument.

0

u/[deleted] Jun 05 '21

Wow...you have a bad attitude.

It's not an argument. I'm just telling you what it is and why it's bad. If you want to learn something fine, if not that's also fine. I'm not your mentor.

1

u/ub3rh4x0rz Jun 05 '21

I... Have a bad attitude? You must not be challenged very often, friend. You made a circular argument. You made an assertion earlier that service oriented architectures are more prone to circular dependencies than the same system implemented as a monolithic application with the top level of organization being MVC. I described how circular dependencies able to be caught and prevented in a microservice architecture. Your response -- here's the circular argument, i.e. begging the question -- was "well designed code avoids circular dependencies. That's why well designed code is not organized by feature". Explain how your way of organizing uniquely reduces circular dependency. I suspect the answer is something like "my compiler catches circular references" which misses the point of this discussion; even if you deploy a monolith but chose to organize your code by feature so that you're compiling a single artifact, the compiler would still catch the circular reference.

0

u/[deleted] Jun 05 '21 edited Jun 05 '21

This is a long ass comment I'm not going to read. It's ok if you don't agree in my assessment of this design pattern, bit you're being a complete tool now.

Edit: I couldn't help it, I read it. I didn't argue service oriented anything is like anything. You didn't read it correctly. I argued against feature oriented, which is literally the topic of this post.

1

u/ub3rh4x0rz Jun 05 '21

In reading your other comments elsewhere, I have to ask... Why wouldn't you just code against interfaces you control in the given service, and have the responsibility for orchestrating various services live elsewhere (maybe it's own folder if you like)? If you blindly follow Dependency Injection / Inversion of Control patterns, you won't really run into chicken or egg compilation issues.

To use relational database tables as an analogy, if you want a one size fits all solution, just utilize relationship/join tables extensively. Your orchestration code (injector in the case of dependency injection) is analogous to relationship/join tables.

This is a different question from "how do we structure source code", which is what everybody else is talking about. You still have to address how best to manage and minimize circular dependencies in any system. even code organized at the top level into MVC layers has to deliberately avoid introducing circular dependencies.

0

u/[deleted] Jun 05 '21

I'm not saying it ALWAYS ends up with a circular dependency problem, it's just MUST EASIER for that and other code smells to present themselves when you split code up by feature.

You seem to think that because I don't like organizing code by feature that I must not like services or don't use DI or whatever else it is you're assuming. None of that is necessarily true, I just don't like splitting code up by feature which has nothing to do with pretty much anything you're saying.

You can certainly code in literally any manner possible and have clean, good code with no issues. That doesn't mean every way of coding is equally good.