New answers tagged java
0
First, I would remove any notion of "best practice" here. You have a specific problem and are looking for an appropriate answer. There are two views on how to design the table, but the most appropriate answer depends on your requirements.
The traditional database modeling way
If you have a record that can have multiple things, then the usual response is ...
2
There's an equivalence between your getSomething method and an abstract class. Both are examples of the Strategy Pattern.
public abstract class SomethingGetter<R, MSGIN, MSGOUT> {
abstract MSGOUT query(MSGIN in);
abstract List<R> getResults(MSGOUT out);
public SomeClass<R> run(MSGIN query) {
//some logic here
...
2
A. They're used to describe the API of various classes.
Correct.
I struggle with the correctness of the phrasing. It's not wrong, but it is essentially a confusing tautology. But they had to avoid calling it "the interface" to not give away the answer, and I'm struggling to find a better (and similarly terse) alternative.
B. They're used to avoid ...
2
Normally, for full historical tracking, you don't need the current status in a different table.
Instead, add two timestamps to your table which represent the start of the given time slice, and the end of the given timeslice. For an update, just set the end timestamp and insert a new row.
Something like this:
userid | status | validFrom | ...
1
Shouldn't I make HahahaService.delete() call JobService.runjob() by itself and return a Job?
It's important to distinguish between domain services (such as HahahaService, which houses actual business logic) and infrastructure services (such as JobService, which handles scheduling, thread pools etc.). You don't want the domain layer to know about ...
1
I would recommend against thread local storage. That bypasses the normal rules around object lifetime (how long it exists) and scope (where it can be seen). It will potentially lead to very hard to debug situations, for example when your code runs into an exception and there is stale data in the thread context. Also, I am not certain there is a promise for ...
0
Like others mentioned, on one hand equality is just a mathematical concept satisfying some properties (see e.g. Albuquerque's answer). On the other hand its semantic and implementation is determined by the context.
Regardless of the implementation details, take for example a class representing arithmetic expressions (like (1 + 3) * 5).
If you implement an ...
4
Here is a simplified version of the Mono Architecture:
The heart of this architecture is the Common Language Runtime or CLR. The CLR contains a Just-In-Time compiler (JIT) that converts Common Intermediate Language (IL) into the native code of the platform it is running on. It serves the same purpose as the JIT in Java.
In practice, this means that you ...
0
If you want a "slightly more powerful list", then implement it. Make use of extension methods to add what you want to that class. For example, the following code will give you a list that returns the value when removing an element and provides Push and Pop:
using System;
using System.Collections.Generic;
public static class ListExtensions
{
public ...
2
instead of having 2 weaker concepts and having to convert between them
Well, that is actually not how I see it. Since a List allows one effectively to execute all stack-like operations, if one really needs "both concepts in one", using a List allows this, so this is IMHO not a "weaker" concept.
Of course, the equivalent of a Pop() operation on a List ...
2
Reactive programming - at an abstract level - deals with decoupling flows using asynchronous data streams.
However, pretty much the industry standard for achieving asynchronous data streams is through event-driven paradigm, and most of the Reactive implementations use this approach.
If there is a better approach to create decoupled flows, then Reactive ...
0
In your flow, I don't see multiple handlers with option for one of them to handle the flow based on condition.
It is just a sequence of steps.
Generally Chain of Responsibility is used when you have a priority order(not necessarily priority, however there is a sequence) of handlers and each decides whether to handle it there or pass it on.
You can definitely ...
3
Part of the point of objects is to limit the things you can do with them as well as enable you to do things.
If I could add items randomly into a stack then it wouldnt be a stack.
If I pop from a list should it return the first or last item added?
Limiting behaviour and having specialised objects is a good thing because it allows you to have sensible ...
1
Your question is very general. So will be my answer.
The easiest way would be to write the implemented method to cover the special cases. It it's complex, you may delegate the execution to more specialised function (that can be outside the interface). But if it were that simple you wouldn't probably ask.
Another way could be :
to implement your ...
0
The method that implements the interface will do exactly what the code that you put into the method does. So if you want the instances of your class to do something different when the interface method is called, you just do it.
Some interface methods are explicitely defined to work that way. For example, in iOS a UIViewController has an interface method ...
1
You definitely have your work cut out for you. Due to the rate of change, and the requirements you have to constantly move to the new API versions, you have a limited set of options.
Option 1
Create a microservice that wraps this troublesome API. It's sole purpose is to provide your application a consistent interface. Your microservice would be deployed ...
3
It's fine as is, if you think about it the right way.
You can think of a Virtual Machine as a task running on the hypervisor. They get context switched nearly the same way after all. Tasks and Apps aren't the same thing. Tasks only exist when they're running. Apps exist even after you've terminated their running tasks. They sit around waiting for you to ...
0
Equality is subtle to get right and its importance is deceptively far-reaching. Especially in languages where implementing an equality operator suddenly means that your object is supposed to play nice with sets and maps.
In the overwhelming majority of cases, equality should be identity, meaning an object is equal to another if and only if it is the same ...
1
It depends.
Is it a good idea ... ? It depends. It can be a good idea, if you are developing an application that will be used only once, for instance,
in a univercity assignment (if you are going to throw the code away after assignment reviewed), or some migration utility
(you migrate the legacy data once and don't need the utility any more).
But in the ...
0
As others have mentioned, the exact semantics of object equality are a part of the business domain's definition. In this case, I don't think it's reasonable to have a "general" object like Address (containing number, street, city, zipcode) to having a very narrow definition of equality (which, as others have mentioned, works in Brazil but not in the US, for ...
2
Although many answers were given, my opinion still isn't present.
I was once taught that the equals method should only be doing an exact comparison between the objects
Apart from what rules say, this definition is what people assume from their intiution when they talk about equality. Some answers say equality depends on context. They are right in a sense ...
42
It is in the context of the university assignment where the task purpose is to explore and understand operator overriding. This seems like an example assignment that has enough implied purpose to make it appear as a worthwhile exercise at the time.
However, if this was a code review by me I would mark this up as a significant design flaw.
The problem is ...
3
An equality operator will claim that two objects are equal if and only if they should be considered equal, due to whatever considerations that you find useful.
I’ll repeat that: Due to whatever considerations that you find useful.
The software developer is in the driver’s seat here. Apart from being consistent with obvious requirements (a=a, a=b implies ...
25
Equality is a matter of context. Whether or not two objects are considered to be equal is as much a question of context as it is of the two objects involved.
So, if in your context it makes sense to ignore city and street, then there is no problem to implement equality solely based on ZIP code and number. (As was pointed out in one of the comments, ZIP ...
88
Defining Equality For Two Objects
Equality can be arbitrarily defined for any two objects. There is no strict rule that forbids someone from defining any way they want. However, equality is often defined when it is meaningful for the domain rules of what is being implemented.
It is expected to follow the equivalence relation contract:
It is reflexive:...
1
Although the given requirement contradicts the human sense it is OK to let only a subset of the objects properties define the meaning of "unique".
Problem here is that there is a technical relationship between equals() and hashcode() so that for two objects a and b of that type is deemed to be:
if a.equals(b) then a.hashcode()==b.hashcode()
If you have a ...
1
Most often I'd do this:
class SpecialDocument {
Document getDocument();
String getField1();
String getField2();
}
The SpecialDocument doesn't extend Document, instead it contains a reference to a Document which is returned upon request.
This avoids creating a complex copy constructor
This avoids creating a bunch of delegation methods
This ...
3
I think it's important to understand proper OOP from a traditional sense, and what is necessary for data binding, etc. Java introduced the JavaBean (POJO with only getters and setters) to bind to the user interface. Most people are not building user interfaces in Java these days, but they still have their place. First, let's distinguish between OOP and ...
6
The class of an object is not supposed to change during the object life-cycle. If you think it should, there must be something wrong in the design.
The kind of challenge that you describe is usually addressed with:
the decorator pattern: a decorator SpecialDocument would add some responsibilities to the base class Document, such as some more methods, ...
5
Truly independent deployment means you can upgrade either service in any order and stay in a working state. Obviously, having no dependencies at all is ideal, but somewhat impractical. If you have dependencies between microservices, you can still deploy them independently:
In your example, microservice 2 can be upgraded at any time, provided it maintains ...
1
To me, this is important because you can release changes in small batches and manage integration regressions much more easily.
With a monolith, you make a change to some feature area, build and deploy the entire thing and hope it goes well. With independent services, it's much easier to roll out small chunks and make sure they continue to play well.
Let'...
5
This characteristic is opposed to a monolith and means that you don't need to deploy two services sie-by-side.
In a case of a monolith, if you want to deploy a change in one part, you have to deploy the whole monolith. This means that you have essentially three problems:
Say you're ready to deploy your change, but the other team working on another part of ...
0
This comes down to the question of
Why do we abstract anyways?
The point of abstraction is to do more with less. When you see code as rules like don't talk to men you don't know who wear dark suits and black hats and don't talk to strangers you have two rules, the latter being more abstract than the former.
So you end up with an abstract rule having ...
2
As a general principle, you should use the smallest amount of information necessary.
In your example, if Orange implements the interface Fruit, and if your code works fine without the knowledge that the object is an Orange object, then it should be declared as a Fruit interface. This means there is no need to change anything if you want to have a ...
3
The coupling here happens between Orange and the rest of your program. If you retain an instance of Orange, then you could conceivably call method specific to Orange and not of Fruit. This is bad for two reasons: A) using methods specific to Orange means you could not act on that instance simply as a Fruit instance (violates Liskov Substitution Principle),...
2
First let's fix a bug. after() is never called.
interface ILaunchInterface {
public void pre();
public void during();
public void after();
}
class Launch implements ILaunchInterface {
public void coreOperation() {
pre();
during();
after(); // <-- note change.
}
@Override
public void pre() {
}
...
3
You need some form of memory on system-A about which records were changed but not yet synchronized, there's no way around it.
Proposed solution:
Let the triggers for database changes insert entries into a CHANGES table instead of trying to synchronize immediately. To handle ordering-sensitive changes these entries should have a sequential ID.
After an ...
Top 50 recent answers are included
