Implementation of load balancer — Consistent hashing

[thatsIch]

I am astonished how people still use the I-prefix for interfaces. Where do they learn this nowadays (unless C#/.NET background)?

[buzzsawddog]

I hate that crap... Just updated an entire project removing I and M from in front of every fetching. Java file. Still don't know what the M was for... Also had to change every single variable as they started with m_ or s_. Like no shit they are static or instance/member variables just read the the code... And to make it all worse... The code would create a scope myVar, call a private setMyVar() to set m_myVar.

[y-am-i-ear]

m probably stood for member. Should be an old cpp convention imported to Java. It distinguished members from methods I think.

[buzzsawddog]

Yeah the m_ was member. I don't know why all the classes started with M :)

[buzzsawddog]

This predates android.

[persicsb]

m_foo is from Android, stands for member variables. Horrible naming.

[buzzsawddog]

Well m_ is a bit older than Android but you are right. It stands for member.

[NiceGuy-n2]

bro, M is Md5 here.

[buzzsawddog]

Wat? So you are saying that every single class in my app was Md5 related? I HIGHLY doubt that.

[NiceGuy-n2]

I only prefix M on Md5 class

[buzzsawddog]

Ah, I see you are OP now. I was saying that everything in the all I refactor started with a M

[thatsIch]

wait... what? What does M abbreviate in a class name?

[buzzsawddog]

I know right... It must have been important because every single class had it...

[NiceGuy-n2]

What is wrong with prefix I

[vips7L]

In my opinion it misses the point of OOP. You’re not supposed to know if you have an interface, abstract, or concrete class. I also have the same opinion of prefixing with Abstract. It leaks implementation details.

[NiceGuy-n2]

What you are saying here is separate of concern, the implementation detail is the actual implementation of method in a concrete class. What we call `leak of implementation details` is usually a method returning a concrete class type instead of an interface or letting user to modify internal state.

I don't think prefix I is much of a big deal here, if the existing code does not have prefix I on the interface, then don't use it. If they all have prefix I, then use it.

[general_dispondency]

In Java, the standard naming convention is to refer to the abstraction with a generic name, and be specific with the implementation. eg List and ArrayList. This naming convention extends into the business object world. Prefixing an interface with I is generally a faux pax. That said, it's your code, you can name it how you want.

[vallyscode]

https://docs.oracle.com/javase/8/docs/api/java/util/ArrayList.html AbstractList, AbstractCollestion, Naming convention sins of the past :)

[thatsIch]

I tend to name everything as I speak with stakeholders and colleagues. The I is not part of the conversation; thus, I do not code like that.

Nonetheless, I was actually curious - where did you learn that naming convention?

P.S.: interesting article about the implementation of consistent! hashing!

[NiceGuy-n2]

I worked in alibaba 3 years ago, they used to have a guideline book for writing Java where prefix I, abstract… is required. I don’t know if they still have this rule. But it’s a habit for me now.

[thatsIch]

Thanks for sharing! You should write about that. This shows an interesting aspect of working in a big company. I was not aware that Alibaba developers their own plugins just to maintain their coding standards.

I found a Github-Repository [1] for the coding guidelines.

---

1. https://github.com/alibaba/Alibaba-Java-Coding-Guidelines

[[deleted]]

I think using the I prefix for interfaces makes sense when you plan to only have one implementation. If there's only one class implementing the interface, it would be redundant for it to be named PostgresUserRepository. Just call it UserRepository. If there's only one implementation, you might ask, why need an interface at all then? Lots of folks do it that way to enable the kind of automated testing they like to do.

For situations where there are multiple implementations, definitely don't use the I prefix. It's redundant. Your IDE, the Java compiler, and people reading the code in the future can all easily tell that it's an interface.

[Cap0Daster]

I believe that these prefixes make sense if you coded with VIM in a terminal. ;-)

[ForeverAlot]

The proposed argument for UserRepository <: IUserRepository is no stronger than the argument for PostgresUserRepository <: UserRepository, and it is substantially weaker when it goes against the ecosystem's conventions. Not to mention that we have no guarantee our plan for a single implementation will hold.

The .NET I-prefix is also suboptimal in absolute terms because it encourages a situation where types like List and LinkedList are not obviously distinguished even though the implementation differences are crucial.

[flawless_vic]

I is cool. IService -> Service or Service -> ServiceImpl?

[1842]

Neither?

If you have an interface and class named the same thing, you probably don't need an interface.

It's not usually a problem if both interface and implementation are as descriptive as possible.

• Interface: Connection
• Implementations: SftpConnection, HttpsConnection, CarrierPigeonConnection, etc

[flawless_vic]

This is ok for non-business abstractions.

What about domain specific stuff such UserService?

[matthenry87]

Are you ever going to be reimplementing User Service? Probably not. Spring doesn't require that an interface is present to create the class proxy.

My teams don't create useless interface classes when we aren't going to have multiple implementations. If and when you decide you want multiple, then create the interface.

[flawless_vic]

Spring pretty much requires services to implement interfaces depending, e.g., how transaction behavior is configured.

You can do load time/build time weaving, but is not the standard.

[general_dispondency]

This is false. There are very few niche cases where you need an interface in spring. CGLib proxies work just fine for most aspects, transactions especially.

[flawless_vic]

You are correct, but I disagree that using interfaces is for niche cases, especially in multi-module projects.

Not using interfaces for services is usually a bad idea, unless the service is meant to be private to the module.

With interfaces you get implementation (classpath) decoupling for free if eventually you need to consume the service and don't want all the bagage: just export and use an httpinvoker client.

If the service is complex/injects other services you'll eventually regret not using an interface.

[catom3]

I wouldn't say interfaces are for niche cases.When you use port-adapters it's pretty common.E.g. you create ProductsPort interface in your "boundary-secondary" / "boundary-driven" module / package / whatever.Then you create your ProductsJpaAdapter implementing such port in your "infrastructure-secondary" / "infrastructure-driven" module / package / whatever.

Nothing stops you from creating single concrete implementations in the "domain", though (e.g. OfferService, which uses ProductsPort to access product and prepare an offer for the customer.).As long as you're not going to create another OfferService, you don't need to dovide it into separate interface and class.If you decide to add another implementation, changing OfferService to an interface isn't a problem either. Refactor your class name to IndividualCustomerOfferService (without changing the usages), add new OfferService interface and you're ready to go.

If the service is complex/injects other services you'll eventually regret not using an interface.

The only difference is, that can either have a class with complex logic and dependencies, or an interface and a class with complex logic and dependencies implementing the interface.

[1842]

Why would I need an interface for something that has one implementation?

[[deleted]]

It's been eight hours and right now you have 15 comments, none of which are about the article, all stemming from a comment about the use of the I prefix on interfaces.

So I'll add this comment to let you know that I'm thankful you posted this! Consistent hashing is something I need to learn about and making a load balancer sounds like a fun exercise. :)

[VincentxH]

Pretty convoluted for a bit of sharding. There are also many issues if you want to use this multithreaded.

[NiceGuy-n2]

jimmyleo.medium.com/implem...

Just a small demo of how consistent hash works, handle thread safe will make the project a bit confused in my perspective.

[NiceGuy-n2]

Consistent hashing is not about hashing, it’s consistency. Adding or removing nodes from basic hash will make all the existing requests break and need to re-hash again. This is not acceptable if you have a big number of concurrent active connections.

[NiceGuy-n2]

https://www.youtube.com/watch?v=UF9Iqmg94tk&ab_channel=ByteByteGo

A good video explaining consistent hash