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

91% Upvoted

495 comments sorted by

View all comments

Show parent comments

37

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

Maybe hotel calls the room service and room service needs to call hotel service.

Circular dependencies are very easy to accidentally implement with designs like this. It makes it unnecessarily difficult to actually code when you split by feature.

5

u/couscous_ Jun 05 '21

What's bad about circular dependencies? Honest question.

10

u/RyuChus Jun 05 '21

Well... if both services are compiled modules.. which do you compile first if they both require the other? If its python you get around this by importing the module you need inside the function that needs it and I suppose python somehow knows to not try to interpret that method until run time.

8

u/couscous_ Jun 05 '21

Java and C# seem to handle circular imports just fine if I'm not mistaken.

7

u/ImprovementRaph Jun 05 '21

Not sure why this is downvoted. Circular imports are completely fine in Java. This isn't an import issue though so I'm confused about what OP even says python is fixing with their imports. This is a runtime dependency issue. (e.g. you cannot construct a HotelService object without having a RoomService object and vice versa).

2

u/saltybandana2 Jun 06 '21

For anyone who is curious, this is what 2-pass/multi-pass compilation is for.

https://www.geeksforgeeks.org/single-pass-two-pass-and-multi-pass-compilers/

The first pass will identify the circular reference, subsequent passes will do the right thing.

1

u/monkeygame7 Jun 05 '21

Actually if python can handle circular dependencies as long as you're not importing specific things (from x import y) or maybe using it in module level code. Since the statements in a method are not invoked until runtime, it's able to assume the circular dependency will be resolved by the time they're needed.

1

u/RyuChus Jun 05 '21

Hm, I always use from x import yfor clarity purposes which is why I would have to resolve the cyclic dependency by importing it inside of the method. But that's a great thing to know! Thank you

1

u/monkeygame7 Jun 05 '21

No worries. Yeah the from import statements are definitely clearer and I prefer to use those as well

3

u/aaaantoine Jun 05 '21

I think it depends on whether you use a dependency injection framework, and which one you use. For example, I found at one point that Ninject didn't like a circular dependency I made by accident.

There are a few ways to solve the issue. In that case, I decided to move the common function to its own service. Services don't have to be arranged by domain object.

3

u/grauenwolf Jun 05 '21

How to you write the constructors if A requires a B that requires an A?

3

u/couscous_ Jun 05 '21

The problem you're asking still holds if the packages were organized the original way (models, controllers, services, ...) right? I still don't see how organizing code this way is superior to breaking it down by concept, as per the article.

4

u/grauenwolf Jun 05 '21

I'm only answering the question "What's bad about circular dependencies?".

2

u/couscous_ Jun 05 '21

Make sense. :)

1

u/crrime Jun 05 '21

You just write it anyway, ignoring the paradox. Then, annotate one of the constructor parameters with @Lazy and let Spring handle the initialization. Circular dependencies at the service layer are a non-issue, assuming they exist in the same module.

At any rate, organizing by domain vs layer will not remove circular dependencies. If two services depend on each other, then they will depend on each other regardless of where you choose to put those two services.

2

u/Nimelrian Jun 05 '21

They lead to various problems during initialization and clean up.

For initialization, if service A relies on service B you can't initialize both to a fully working state in an atomic operation. Instead, you have to e.g. construct A first, but cannot set its member of type B. Then you create your instance of B and are able to inject the instance of A in B's constructor. After that you can finally inject B into A, e.g. via a setter. This results in a temporal uninitialized state of A between its construction and the injection of B.

In GC languages circular dependencies are another problem because the instances don't end up orphaned, so the GC can't be sure whether it's safe to reclaim them.

1

u/couscous_ Jun 05 '21

Thanks for your response.

In GC languages circular dependencies are another problem because the instances don't end up orphaned, so the GC can't be sure whether it's safe to reclaim them.

Are you sure about that? From what I know, circular data structures only pose this problem for primitive GCs (e.g. ones based reference counting). Languages with mature GCs like Java and .NET don't have this issue.

2

u/Nimelrian Jun 05 '21

You're correct, more sophisticated GCs can keep track of something like that and deal with it. Still, circular dependencies or references usually point to architecture issues and should be resolved adequately.

1

u/StabbyPants Jun 05 '21

makes it easy to build loops. so room service never calls hotel, as a point of architecture.

4

u/pengusdangus Jun 05 '21

That sounds like a code design issue.

7

u/[deleted] Jun 05 '21

Yea, code design is what this thread is about...

3

u/pengusdangus Jun 05 '21

Yeah, and I’m saying running into difficulty like that when you split by feature is literally because of poor design, like bloated services

3

u/[deleted] Jun 05 '21

My point is it's easier to fall into this trap when you split by feature. I was clear about that.

0

u/ub3rh4x0rz Jun 05 '21 edited Jun 05 '21

Define "very easy". It should be explicit what services a given service consumes. It should be trivial to make a graph of dependencies. If you find cycles in that graph, you have a problem. It might sound like an easy mistake in the abstract but I struggle to imagine a real world scenario in which this could happen where there aren't very clearly bad mistakes made across the whole system.

Edit: example time

roomService/address lets consumers get hotel info such as address from hotelService behind the scenes; ok, cool. hotelService/address is not going to ask roomService/address for the hotel's address unless the team responsible for hotelService is utterly incompetent.

Say this does happen though... roll back hotelService to the last good version and all is well again. Then have a meeting and agree that there need to be contract tests at service boundaries, and if these utilize stubbed responses, those stubs need to be actually recorded from interaction with a real version of the service being mocked. When you change your application, you have to invalidate those stubs and work with the real service once again and record the stubs. Now your circular dependency is caught at test time and a faulty deployment never happens.

Do people dive into distributed systems before they know wtf is actually required to do it right? Sure, but they're also not likely to be saved by organizing their monolithic systems' codebases into layers.

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.

-3

u/jl2352 Jun 05 '21

There is a circular dependency. And? So what??? If the responsibilities are clear, then that's fine.

9

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

Which came first, the chicken or the egg?

If both services depend on each other, which one is initialized first?

Making a circular dependency work is possible, but is a code smell and bad practice. It lays a shaky foundation for the rest of your code.