I notice that line 13 in the first if-group and line 20 in the second if-group are identical. So you're not going to add any records unless office.getFacility().equals(dropdownChangeFacility) is true. So you could pull that out and wrap it around the two if-groups, reducing their if-conditions accordingly.
But there's something which bothers me about that idea: if the first if-group you're concerned about whether dropdownChangeFacility is null and in the second if-group you aren't concerned about it. Is it actually true that office.getFacility() might return null, but sometimes that excludes the office from being in the list and other times it doesn't? I'm suggesting that maybe the if-test made up of lines 11 and 16 might be unnecessary, or alternatively that it could be pulled out to the higher level as well.
It would also help a lot to include some comments which explain why those particular tests are being made. My interpretation, based on staring at the code for a quite a while, is something like this:
1. If the office's facility matches the dropdown change facility, and there's no dropdown change floor, then the office goes in the list.
2. If the office's facility matches the dropdown change facility, and the office's floor matches the dropdown change floor, and the office has workspaces, then the office goes in the list.
When I write it that way it becomes clearer that matching the dropdown change facility can perhaps be done up front, which simplifies the two tests there.
Does that help?
As far as formatting goes, I'd get rid of most of the double-spacing, since it spreads the logic out and makes it harder to see all of it in a single glance. Not to mention makes it less likely to all fit on the screen at the same time.
As far as logic goes, Paul has given some guidelines.
I've always sneered at the assertion of the ignorant that you have to know mathematics inside and out to do programming (unless you're programming for math), but there is one branch of mathematics that all good programmers would be well-advised to be fluent in, and that's the Calculus of Propositions.
Propositional Calculus (PC, for short) is nothing like numerical calculus. Instead it deals with the rules that allow rewriting logical expressions into other, equivalent (and hopefully simpler) logical expressions just like you would simplify algebraic expressions. These rules are named (de Morgan's Theorem, modus ponens, modus tollens) and have been mathematically proven.
Not only can you use them to simplify statements and expressions, but you can also invert logic to make it more understandable. Several years ago, I read that a college professor dedicated an entire term to "not", because negation throws up a mental "speed bump" when trying to comprehend things.
IBM was a bad offender. The original OS/360 mainframe Job Control Language managed conditional execution of job steps using expressions that basically were coded in the form "if x is true then do not execute y".
The downside being that you have to know and be willing to hard-code a suitable datatype for the declared variable officeRoom.
I generally like to make my collection objects be always empty instead of null, also variables and lists you get from GUIs are often never null. But admittedly it never hurts to be paranoid. Not only can unexpected data be encountered, but overly-optimistic assumptions can be exploited by attackers.
Look at this code:
you should recognize that it's functionally equivalent to this:
Why? The if statement on line 11 is unnecessary because by contract equals(null) always returns false. So right there, you can eliminate one level of nesting.
Looking at the code some more, I would probably try refactoring that code to something like this (assuming Java 8):
This points to a subtle code smell in your code: the mixing of concerns.
You have two major concerns in this method: 1) Selecting Office objects that match the filter criteria and 2) excluding duplicate values returned by getRoom(). Your conditional logic becomes more complicated because it incorporates the two concerns. A better separation of the two concerns simplifies your conditional selection logic. By using a Set to collect values returned by getRoom(), you move the responsibility of eliminating duplicates to an object that already inherently does that.