magic_lobster_party @ magic_lobster_party @fedia.io

Posts

0

Comments

419

Joined

12 mo. ago

The only problem is to ensure the entire team agrees to only use it like an interface and nothing else. But I guess that’s the only proper way to do it in C++, for now.

In your example, the declaration of ArrayList look like:

    
public class ArrayList extends AbstractList implements List {
}

  

The dependence on AbstractList is public. Any public method in AbstractList is also accessible from the outside. It opens up for tricky dependencies that can be difficult to unravel.

Compare it with my solution:

    
public class ArrayList implements List {
    private AbstractList = new AbstractList();
}

  

Nothing about the internals of ArrayList is exposed. You’re free to change the internals however you want. There’s no chance any outside code will depend on this implementation detail.

If the lists have shared components then that can be solved with composition. It’s semantically the same as using abstract classes, but with the difference that this code dependency doesn’t need to be exposed to the outside. This makes the dependency more loosely coupled.

I usually break it out using composition if that’s ever needed. Either by wrapping around all the implementations, or as a separate component that is injected into each implementation.

Ask Bjarne to add interfaces enough many times until he gives in.

On a more serious note, I’m not exactly sure what the best C++ practice is. I guess you just have to live with abstract classes if you really want interfaces.

In 99% of the cases, inheritance can easily be replaced with composition and/or interfaces. Abstract classes tend to cause hard dependencies that are tough to work with.

I’m not sure why you would use abstract classes without data. Just use interfaces.

So things like abstract classes are mostly absent from my codebase.

I believe the consensus nowadays is that abstract classes should be avoided like the plague even in languages like Java and C#.

That still counts as one

It doesn't matter, why the present is garbage, it's garbage and we should address that.

The problem is fixing it without inadvertently breaking for someone else. Changing the default behavior isn’t easy.

There’s probably some critical systems that relies on old outdated practices because that’s the way it worked when it was written 20 years ago. Why should they go back and fix their code when it has worked perfectly fine for the past two decades?

“I’m using affordable care act! I don’t want Obamacare!”

Well someone must pull that switch and push that cart. Only a highly trained professional from MIT can do it.

I think the general rule of thumb is: Keep it Simple, Stupid.

Don’t include fields “just in case”. If you don’t have a use for a field right now, then don’t include it. It’s often easier to add fields than removing.

Avoid having fields that can be derived from other fields. Code “UNAUTHORIZED” can be derived from 403. Having both adds confusion. It adds the question whether the code field be something other than “UNAUTHORIZED” when the response is 403.

Just 403 with empty body is fine. Add message in a JSON in case it’s useful for the user. If the user needs more fields in the future, then it’s easy to expand the JSON.

Better be explicit about the walled garden rather than being diffuse about it

Yeah, the old logos were all over the place. At first glance it’s not obvious they’re all Google apps.

Only from the comment saying it was a duplicate. The question wasn’t even the same and the answer was barely touching my question.

I haven’t asked that much on SO. Often I can find the answer myself. In other cases my question is so niche I don’t know how to formulate it into a good SO question.

One of my questions got closed for being duplicate because it was tangentially related to a different question. I got the answer, but it left me a sour taste.

Steam stats are the only stats available, and they probably correlate pretty well with console stats.

Helldivers 2 is doing really well on Steam despite being a PlayStation game.

They’re lobbying so they can make more money from cryptocurrency. It’s not going to benefit the common folk in any way (unless you believe in trickle down economics).

There’s a special place in hell for those who set an upper limit in password lengths.

Reserves = USDT, which is definitely backed by real USD.