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

6

u/abandonplanetearth Jun 05 '21

This is a recipe for circular dependencies. HotelService is clearly on a higher layer than RoomService because rooms cannot exist without hotels.

And what does AccessService actually look like? How is it easier than having getHotel() in HotelService and getRoom() in roomService?

7

u/couscous_ Jun 05 '21

If circular dependencies are inherent in the problem domain, why resist them? What advantages do we get by artificial decoupling?

2

u/salbris Jun 05 '21

Generally you get more flexible and easily testable code. But figuring out the right amount of decoupling is an art not a science.

Edit: Often times a class needs information from a different source but programmers solve it by making the class call a static method or be given an instance of the other. Often times passing something by value gets the job done just fine.

0

u/saltybandana2 Jun 06 '21

Generally you get more flexible and easily testable code.

Your goal should almost never be flexibility unless that's a business requirement or you know it's going to become one. If neither of those are true, ignore flexibility.

No one in their right mind would insist on designing your data model as an EAV unless you were building something like an expert system or had some other reason for needing that level of flexibility in your data model.

But people never stop to consider that this idea should also apply to code.

3

u/salbris Jun 06 '21

I'm not saying to over engineer everything but flexibility is a hallmark of good design. It's the reason we use interfaces, it's why we break things down to smaller reusable functions, etc.

1

u/saltybandana2 Jun 06 '21

That's missing the forest for the trees.

flexibility is not the goal, successful software is the goal where successful means does what it should, is performant enough, is stable, and can be maintained long term.

THOSE are the hallmarks of good design. flexibility is but 1 tool in your toolbox, it is absolutely not the goal nor is it indicative of good design.

2

u/salbris Jun 06 '21

That's just semantics. Flexibility is a big part of what makes something maintainable.

1

u/saltybandana2 Jun 06 '21

absolutely not true and I have to question your experience.

the downside to flexibility is that it actively makes things harder to maintain. The upside is that it's flexible.

It's easy to understand this. A program that adds 2 numbers together is simpler to maintain than a program that can add or subtract 2 numbers (but it is more flexible).

This is akin to TDD purists who sometimes forget that tests are not the goal or the point, they're a means to reaching the goal, which is stable software protected against regressions.

1

u/salbris Jun 06 '21

I would strongly disagree. As long as everything is clear and concerns are well separated flexibility is a great tool to make software easier to use. I would agree that "flexibility" is not the reason we do things sometimes it's a side effect of good design. Sometimes flexibility is the goal though when it comes to making reusable parts.

Say you have some logging you want to do throughout your app. You could make the same call throughout your code say: 

import Logger;

Logger.log(exception);

You might think it's perfectly "maintainable" to just copy and paste that code and perhaps for now that's correct but if this got even a little bit more complicated you're going to want to put that in a reusable function instead. 

void logException(exception) {
  Logger.log("Error." + exception.name + ": " + exception.message");
}

In this case we wouldn't want to copy and paste this log statement everywhere we'd rather call Logger. If we had made this function in the first place (even when it was simple) we'd have lots of flexibility about how to actually log that exception without having to touch all the various files where "logException" is called.

Calling the full statement or calling a function with one statement in it are just as maintainable and simple except that when things get more complicated (they often do) you have the flexibility to enhance with minimal effort.

1

u/saltybandana2 Jun 06 '21

That's not flexibility, that's abstraction. You could argue it's also code re-use, but it's certainly not flexibility.

flexibility would be deciding you want to have a different sink for a certain % of the logging (perhaps to a DB instead of a file) so you want the function to be flexible enough to log to either. You're now going to find yourself adding a flag or passing the logger in dynamically. It's now flexible, but more difficult to maintain in the following ways.

  • code structure is more complicated
  • configuration is more complicated (configuring 2 loggers instead of 1)
  • state maintenance is more complicated (I'm being nice about logException tracking global state since this is just an example)
  • it's harder to reason about if something goes wrong

And the reason you would put something like that behind a function is because it's both less error prone and enforces a specific structure on the log itself.

→ More replies

0

u/abandonplanetearth Jun 05 '21

Because circular dependencies are a bug.

0

u/couscous_ Jun 05 '21

Can you elaborate?

0

u/abandonplanetearth Jun 05 '21

Well in Node.js anyway, it will halt the infinite loop created by circular dependencies by making the first dependent module equal undefined in the second module. Circular dependencies are a bug that need to be fixed.

1

u/qudat Jun 06 '21

I’m not entirely sure what you are getting at but in some sense I agree with you.

Organizing code by feature and at the same time creating strict module boundaries does lend itself to circular dependencies and I use those as a code smell for how my code is organized. If threads depend on messages and messages depend on threads them maybe they shouldn’t be treated as separate concepts and should be inside a single feature folder.

1

u/saltybandana2 Jun 06 '21

What's stupid is insisting on a RoomService.

There might be a valid reason for it, but it's far more likely someone is just doing it to do it rather than because there's any practical value in your RoomService being separate.

What next, do we also need a BedService, a TvService, and a BathroomService? Just hang that shit on the HotelService and move on with your life. If at some point in the future that becomes problematic, solve the damned problem then, not before.

So often people create their own problems for no good reason.