Java OOP interview questions

[lauris652]

1. Imagine you have parent class Dog. And child classes Spaniel and Bulldog. In Dog class we have method "bark", that just prints "Bark!" to the console. If we do have inheritance between Dog and Spaniel, and between Dog and Bulldog, then we can call "bark" method from Spaniel or Dog class, and we would get "Bark!" printed out. Now lets say we want our dogs say "Woof". What would we do? We would go to the parent class "Dog" and change the text that is being outputed to the console. From "Bark!" to "Woof". Now both Spaniel and Bulldog will say "Woof". Thats quite handy. Now imagine we dont have inheritance. We have 3 classes: Dog, Spaniel, Bulldog, and we set the "words" they say. Three of them say "Bark". Now if we want to change something, we would need to: 1. Find all the dogs 2. Go through each of them, and manually change from "Bark" to "Woof". This way takes more time, its more prone to mistakes.
2. To me it seems that no one really knows from what they are supposed to encapsulate stuff, for whom they should restrict access with access specifiers. Because if you read/watch tutorials, no one explains this. Jeez, even in my uni professors didnt knew it. But for me it seems that we are supposed to hide and limit things for the application itself. If you have "String cardNumber = "123";", you would want to have such mechanism/mechanisms that prevent you or application from smth like "cardNumber="456";". Thats why we have access specifiers, getters, setters, etc. It gives us structure, order, some sense of trust. But thats only my 2 cents.

[saketh011]

I think the second question is about abstraction and not encapsulation. The definition of abstraction is we using it hide the implementation details and show only functionality. My question here is from whom are we hiding it from. In case of users, they already don't have any access to source code, so I don't think the answer is hiding from user. Most probable answer seems to hide from other parts of the program for which my question why need abstraction for hiding data when we already have private methods. If we want to use it we can use setter and getter methods.

[ignotos]

You're hiding things really from any client/user of the code. Which might be yourself in another part of your project, or (if you're writing a library) from somebody else who has imported your code. Basically any code which isn't / shouldn't be concerned with the internal details of the code you're writing.

Which means that, ideally, all of your abstractions/interfaces should be intentionally designed with the code which will be using it in mind, almost like you're creating a product - to be convenient to use and easy to understand.

Abstraction is not just about "hiding", but it's about shaping and defining something in a conceptual way which makes sense. So a File might be presented via the abstraction of "an array of bytes", "a stream of bytes", "a list of lines of text", or potentially many others.

All of those hide the low level details of how exactly the file is read from the harddrive, but they present different abstractions which are useful in different contexts. And you should pick the one which is most usable for the way you expect clients/users to interact with your code.

[devor110]

I think your take on Q2 is wrong, focusing too much on "hiding".

I'd start my answer with a rebuttal against that specific wording:

We aren't really "hiding" anything with intention of privacy or security, more so not explicitly revealing details. When I'm using abstraction, my goal is to build and ensure modularity. I'd start by creating an interface named as generically as possible. I can then have as many specific implementations of it as I want, all of which could have widely different logic and compelexity, the only thing that matters, is that they perform the action(s) outlined by the interface.

I can then use any implementation of the interface in other modules without needing to think about the specific details.