The overall problem you're having is that you're letting the implementation of this object guide its interface. That's almost always a bad idea (and is pretty much only justifiable for performance reasons).
This almost certainly stems from a lack of understanding of what this object is for. What purpose it serves within the overall design of your system.
Without further context this cannot be answered. It depends on your usage scenario.
The difference here is not so much immutability (both your examples are immutable) as it is statefulness. If you care for the class remembering what directory it is monitoring and you want it to stick to that, go with the first. If you have multiple threads using the same ...
Since you say distributed generation is a requirement I'm going to argue for UUID. version 1.
the number must be fairly easy to remember and must say something about the time (or at least sequential order) the order was placed. This eliminates things like UUIDs as an option, since those are both very hard to remember and lack any time information.
Should setters only set the values of class properties, and not perform any other logic?
Following this rule makes having setters pointless. The only reason we put up with this tragic preemptive clutter is because some languages (also looking at you Java) have forced us to provide setters even when their side effects don't exist yet because allowing ...
The pattern itself doesn't violate the Open/Closed Principle (OCP). However, we violate the OCP when we use the pattern incorrectly.
The simple answer to this question is as follows:
Create your base functionality using Factory Method Pattern.
EXTEND your functionality by using the Abstract Factory Pattern
In the provided example, your base functionality ...
Combine whatever information you need with a randomly generated number.
So your ID could look like this: John-Doe-2019-07-20-13:24-XUgve2wQ
If you include a timestamp, this is both readable and highly likely to be unique.
Not all services require to be run as web services. A plenty of use cases which are async in behaviour can be performed by backend services which do not necessarily interact via REST or similar methods.
Any use case which does not require immediate response can have two parts, one to accept the request and send response and the other one to process the ...
Don't do premature optimization. Filtering reviews based on the ID of a user takes microseconds: I'm pretty sure the bottleneck in your app is at somewhere else.
Query the review of the current user, and show it immediately, as the user may be interested to know as soon as possible that he already reviewed the entity. Then, do an AJAX request to get the ...
You could use a flake, a "decentralized k-ordered unique ID generator". Flakes are
generated without any coordination between machines
roughly time ordered.
Flakes don't directly give you "easy to remember", but I imagine it would not be terribly hard to map them into something easier to remember - a table of 10^2 adjectives and 10^2 ...
Is this even in the ballpark of sane?
Nope, not even remotely close to sane.
What kills it is the "fairly easy to remember" requirement. A number stops being easy to remember at 5 or 6 digits, which is simply not realistic for an order ID, and completely impossible given your other requirements.
Personally, I would strongly question the "easy to remember" ...
Build a table with 3 to 5 letter nouns that mean something (pear, dog, horse, brass, et cetera).
Segment them, so you can assign different parts to different users who are to generate ids. The meaning of the words is irrelevant, just make sure you have more pools to pick from. Segment randomly.
When you generate an id, pick a random word from your pool and ...
Side effects are OK and one of the reasons for having properties instead of straight public member variables in the first place. Your example is not compelling though. But you can think of a private update method that gets called each time a property value is set. The update method could change some color in the UI or perform a new search using the new ...
In the Red book (implementing DDD), there is DDD scorecard at page 11, which helps you recognize when DDD should be considered.
If your project contains 30+ user stories
will grow in complexity
application's features are going to change often
the domain is new and you and your team does not understand the domain
that means, more complex and ...