Ftyjtk

As the title suggests, I'm preparing for an upcoming software engineer role at graduate level. I just wanted some feedback to my answers I plan to give if asked about the core aspects of object oriented programming.

Abstraction - only showing relevant information and hiding implementation details. Interfaces and abstract classes are an examples of abstraction. Allows a user to use some form of functionality without knowing the inner workings. For example, the HashSet class provides put() and get() methods... As a user I do not need to know how the HashSet class implements these methods, I just need to know the relevant details such as the method names and parameters. Abstraction reduces overall complexity of a software system.

Encapsulation - the process of binding the data and operations performed on that data into a single unit. OOP classes are a good example of this - all the data and methods performed on that data are contained within the class. Furthermore, encapsulation allows us to hide the state of an object by making attributes of an object private and only allowing the object itself to perform actions on the attributes via public methods. Encapsulation helps with both security and modulisation.

Polymorphism - the ability for an entity to take on multiple different forms, based on the context. Examples of polymorphism are runtime and compile time polymorphism. Runtime polymorphism is achieved by method overriding, while compile time polymorphism is achieved by method overloading.

Inheritance - allows for common attributes and functionality to me shared amongst different entities. This supports code reuse and reduces complexity.

Any feedback much appreciated. Also, any help as to what other questions might arise at a graduate level software engineer interview, that would be a great.

What you wrote sounds very theoretical.

A warning bell goes off in my head when I read a blanket statement like "inheritance... reduces complexity". It shows you haven't dealt with the increased complexity inheritance brings (think about it, inheritance couples classes together, but de-coupling is what we want, right?). This is why composition is sometimes preferred over inheritance.

I'd suggest looking at a book like "Clean Code" to get an idea on how a practitioner would think of OOP. They will probably ask you to design something in an OOP manner. The stuff you said above isn't going to help much if you don't know how to use it.

A lot of OOP (and maybe all) can be understood through a messaging paradigm. I'd chew on that a bit before going into your interview.