• Register
Welcome to Kodlogs, programming questions and answer website.
0 votes
object oriented design interview questions
by (1.6k points)  
reshown by

5 Answers

0 votes
object-oriented design questions are one

of two types of design questions in a

typical programming interview the other

being system design questions

a typical object-oriented design

question could be something like design

an object-oriented parking large of

course we all know what a parking lot is

but we don't really think of a parking

lot in terms of an object-oriented

system so a question like this can look

very intimidating but the key to an

object-oriented design question is to

realize that object-oriented systems

communicate in ways very similar to how

we human beings communicate in real life

so if you go to a restaurant there's a

server which is a sub who is a sub type

of a human being obviously because as

servers a human being and a server

essentially has all the properties all

the behaviors that any other human would

have and obviously a server has some

special specialized behaviors too like

taking in order bringing you food that a

regular human being would not do you go

to a restaurant you you have this server

here and you place an order to the

server you don't really care how the

server is you know going to get your

food weather is going to go tell the

chaff is going to go do it himself you

don't really care you just wait for the

fridge in fact object-oriented systems

communicate in in very similar ways so

there are classes like human beings sub
by (9.8k points)  
0 votes
classes like server and when classes

communicate with each other they hide

the details that are not necessary that

need not be exposed so a class customer

would call place order on the class

server but what exactly happens after an

order is placed that portion is

abstracted from the class customer isn't

this very similar to how we place the

order food in a restaurant

and this intuition this intuition

between how human beings communicate in

real life and how object-oriented

systems communicate in an

object-oriented paradigm is essentially

the key to cracking a design question

and once you have this intuition once

you're able to see an object-oriented

system in a very natural way questions

like this are just a piece of cake so

let us now look at how we could design

our object-oriented parking large as a

first step when you are presented a

design question you need to ask

clarifying questions it could be

something as simple as what do you want

to park in a parking lot is it a parking

lot for I mean by parking lot is it

something for trucks for cars is it a

public parking lot a private parking lot

verify your assumptions ask clarifying

questions if any the next step would be

to identify the major entities in the

system so in case of a parking lot who

are the major players obviously say let

us say we are just building a parking

lot for cars so the major players would

obviously be cars and where you park

cars in parking spaces so parking spaces

and the parking spaces are a part of the

bigger parking structure so I would I

would say the major entities are

vehicles parking structure parking space

and so on I mean you could add payment

system if it's a private garage maybe

you could have a validation system and

so on but just to keep things simple

vehicle parking structure parking space

or for now the major entities in our

system alright so once you have the

major entities your next step is to

define their behavior or rather just

identify their behavior so what is in

vehicle like what what behavior would

every way you'll have obviously if it's

a vehicle every way

would have a license plate license tag

and it should also have the ability to

move if not I wouldn't call it a vehicle

so the next step is to basically write

down your entities and their high-level

behavior and in this case for vehicles

the high level behavior that we have

defined is to have a license plate and

the ability to move so I use an

interface here because an interface is

very similar to a class but I'm not

actually defining what happens when you

call the gate license plate method all

that I'm saying is a vehicle should have

these properties I'm not really telling

what these properties are so this is why

I use an interface here to just tell

what behaviors my entity should have so

now now if I have all my entities and

their corresponding behavior the next

step is classes where I actually tell

tell what a behavior should do what do

you mean by gate license plate what

exactly is an entity supposed to do for

that particular behavior

so I'm actually defining the behavior

that I have previously identified so for

example there's invited I basically

identified some behavior and car is a

class that implements a vehicle

interface basically I'm saying that car

is a vehicle and car is a class so I can

just get away with identifying the

behavior I actually need to tell what

this behaviors should do so I'm

basically so car basically has all the

behaviors of vehicles it can also have

some additional behaviors but car is

basically a blueprint a concrete

blueprint of a real-life object so if

you if you create a physical object like

this here I'm actually referring to a

car in the physical world

an actual physical tangible physical

entity here and the behaviors of this

tangible physical entity is defined here

in this class so that's pretty much our

basic hierarchy at a very high level we

have interfaces and then classes which

are a concrete blueprint and actual

tangible entities of these classes

called objects so now we have ask

clarifying questions verified our

assumptions and then we identified the

major entities we identified their

behaviors through interfaces and we also

actually define them define them through

classes but some of these entities can

have some specialized behavior like you

know we all are human beings but then a

customer in a restaurant behaves

different differently than a server in a

restaurant so obviously a customer and

server don't exactly have the same

behavior so another example could be say

there's a class vehicle and there are

buses trucks and carts they all have the

ability to start stop and turn they all

have this ability but the way a car

starts might be different from the way a

truck or a bus starts maybe you know the

engine the mechanical components might

be different the same thing for turning

the ability to turn you know the the

turning radius and stuff like that might

be different so while all of them have

these behaviors the exact behavior may

vary from bus to trot to car so I take

my class vehicle and I use inheritance

to define each of this subtype

of varrock vehicle all of them are

vehicles but each of them can redefine

some of these properties and then again

you could have you know subtypes of

these subtypes we could have an electric

car which has some special properties

like charging which a mechanical car

would not have and a convertible car

which again could have some special

properties like to open its roof so a

convertible car has all the properties

of a regular car in addition it defines

its own properties so that's essentially

the next step is to identify the

subtypes of these entities and we define

these subtypes and their specialized

behavior through inheritance so the

internet the internet is full of

examples of inheritance about you know

animals being the parent class for dogs

and cats or vehicles being the parent

class for buses and cars but for for a

second I wanted to look at a more

concrete example an example that you
by (9.8k points)  
0 votes
would actually use in your professional

coding and how inheritance plays a role

here the code on the top and the code on

the bottom is exactly the same except

for the type of set that's being created

so when you call get sad here on the

code on the top and the code on the

bottom returns to you a set object but

again here is where inheritance and

polymorphism plays a role the actual set

object that's being returned on top is a

tree set while in on the bottom it's a

hat set the actual set object but again

the code otherwise is exactly the same

and it operates on a set object the

coordinate the code is not dependent on

whether it's a tree set or a hat set

however the behaviors exhibited would be

different for example you could you can

see that for the same code depending on


due to polymorphism depending on the

underlying object that said points to

elements could be accessed either in

ascending order or in no particular


likewise looking up an element could

either take log n or constant time again

depending on the underlying set object

that you're calling on so so this is

probably a very classic example of

polymorphism where depending on the

underlying type just the same object the

same set object exhibits different

behaviors so that is a small digression

just to look at a more concrete example

of inheritance so let's move on and

let's continue to identify our other

major entities obviously the parking

space that's where you physically park

your car a parking space could be say of

multiple types like we have a regular

space we have a compact space and then

reserved space for handicapped customers

and so on these are again subtypes of

the parking space entity and as we just

discussed we identify subtypes through

inheritance and then the parking

structure the parking structure is the

overall building that holds these

parking spaces the overall structure and

yeah and that could obviously provide

some functions to like in some parking

structures you go in and the parking

structure would tell you where to park

or if it's a private garage the parking

structure would might need to validate

you before it even lets you inside the


so as we just discussed we have a

parking space and there are two types of

parking spaces say the regular space and

handicapped space so I use inheritance

to identify its subtypes so as you can

see here the parking space provides

some basic methods some behaviors that

let you park a car so when you park a

car you're given a certificate and when

you want to unpack your car you give the

same certificate the digital signature

just to make sure that you don't walk

away with somebody else's car and so on

so these are the behavior is that every

parking space would have however the

exact amount charge the hourly rate that

varies from a regular parking space to a

handicapped space because we are

providing a discount to handicap

customers so we use inheritance and

these the child classes of parking space

they have all the other behaviors as the

parent parking space class but the

hourly rate is different for regular

space and handicapped space so so now

when you want to create an object does

it really make a whole lot of sense to

create an object of the parent class

parking space so you have a parent class

parking space and these two child

classes regular space and handicapped

space so would you ever want to create

an object of the parent class parking

space I would say no because an object

is a physical tangible entity that you

could a physical object in the real

world in the real world could there

actually be a parking space that is

neither regular space non handicapped

space if these are the only two types of

parking spaces that we have no right our

parking space should either be a regular

one or a handicapped space whatever

whatever the hourly rate the hourly rate

is not defined for the parent parking

space class it's it's only defined in

the child regular space class and

handicapped space class so if you have

to create an object of parking space


it's hourly rate so it's not really

appropriate to create an object for the

parent parking space class and here is

where the concept of an abstract class

tamson so now that you have your

entities and their subtypes mapped out

identify classes that are not that are

not ready to be instantiated parking

space is a class that I think should not

have a direct object every object should

either belong to type regular space or a

handicapped space so here is where I

would use the concept of abstract

classes and make parking space and

abstract class just so that we don't

create an object of type parking space

on the other hand you could also prevent

creating an object of type parking space

by making it an interface and not an

abstract class but if you were to make

it an interface all these methods would

have to be dreamed re-implemented in

both the regular space class and a

handicapped space class which i think is

an unnecessary duplication of code

because these these behaviors are

exactly the same for regular space and

handicapped space so we have identified

our major entities defined their

behaviors identified subclasses for

these entities like parking space and

you know regular parking space handicaps

parking space and so on and we are

defined the behavior for each of these

subclasses and so on so the next

question is how do these entities

interact with each other right what is

the relationship between all these

different entities how do they all come

together to interact with each other to

form the overall object-oriented parking

lot so there are essentially two types

of relationship is a relationship and

has a relationship s a relation

is what we have been seeing all this

while that's inheritance so ACA

relationship is the relationship between

parent classes and it's child classes

it's essentially used for entities there

are subtypes of of the parent entity

like regular space is a subtype of

parking space and handicapped space is

also a subtype of a parking space so we

use easy relationship or inheritance but

how about parking structure and a

parking space the parking space is not a

subtype of parking structure rather a

parking structure contains parking

spaces so when a class just contains a

reference to another class we use a

relationship pad called has a

relationship because it has a reference

has their relationship and typically

classes are not subtypes of each other

for example parking structure is not a

subtype of a parking space one

instructor just has a reference to

parking space so it could cause it could

pass some messages to parking space it

could invoke some behaviors on parking

space and let's actually see how this

looks in some basic Java code so as a

first step here I have parking structure

and it has references to a list of

available parking spaces so here as the

has a relationship between parking

structure and the parking spaces at this

point this is a very simple garage so I

just have a very simple linear list of

spaces you could divide it into levels

and so on and once a once a vehicle is

parked I try to keep the mapping between

I try to keep a mapping of my new spaces

just so that whenever somebody comes

over and tries to remove the vehicle the

I I could identify that parking space

and parkway vehicle and then add it to

my available space and these are all

some generic methods my parking

structure provides so this would be a

parking structure at a high level and

note that when I say parking space I'm

using the abstract class parking space

or even better we did not really have an

interface for simplicity but if you had

an interface it would be even better to

use an interface there but for

simplicity we just started with an

abstract class for parking space so

let's just stick with it by using an

abstract class for parking space

I don't really specify whether it's a

regular parking space or a handicapped

parking space so the exact behavior of

the parking space would depend on the

actual concrete class in that object so

we now have the parking space class

which could either be handicap space or

a regular space and and handicapped

space extends parking space likewise

regular parking space to what extent

parking space and each one of them

concretely defines the get hourly rate

so it's the has a relationship between

parking structure and a parking space

and is a relationship or inheritance

between parking space and handicap

parking space and regular parking space

so um it helps to take a quick look

between interfaces in abstract classes

because they are sort of similar and

could be a little bit confusing on when

to use what I would use abstract class

basically to provide skeletal

implementations and I would try to use

abstract classes to avoid duplication of

scored because if methods like in a park
by (9.8k points)  
0 votes
and unpark

were to be implemented in both regular

parking space

and handicapped parking space it would

be a duplication of code so I use

parking space as an abstract class which

has all these common methods and

specialized methods that inherit from

this abstract class on the other hand I

would use interface for basically as a

first step to identify the behavior of

my major classes so I would rather first

have an parking space interface that

identifies the high-level behaviors of a

parking space and then an abstract class

for parking space where I actually

provide skeletal implementations for

these methods and then concrete classes

of regular parking space and handicapped

parking space which have all the

behaviors defined and an interface can

also be used to enforce some behaviors

as we can see for example if I only want

to work with cars which have an auto

parking feature I could use an interface

to enforce this for example in my garage

I only want cards which have an auto

parking feature this basically means

that any car that wants to park in my

garage should have the ability to a park

and unpark on its own so I define this

interface called auto parking car which

would have the park and unpark method

and whoever wants to work with me would

now have to implement this interface

because my my method only accepts an

auto parking car it just doesn't accept

a regular car so whoever wants to work

with me has to implement the method

parking and park this way I could be

sure that they're going to work with me

your car will have the park and unpark

behavior so now when I say parking space

dat park of BMW it's it works because


implements the auto parking car method

the auto parking car interface so BMW is

an utter bucking car on the other hand

you can also see that the Honda guys

haven't implemented the auto parking car

interface so it is not an auto parking

car and that would be an error so this

witness helps this helps ensure that any

car that tries to park in my space has

the a part method and I could just call

in a BMW dirt park so here's the

high-level overview of all that we have

had so far we didn't know I did not

really show some of these interfaces in

the code just for simplicity but we have

interfaces for all our high-level

entities parking structure parking space

cars and so on and as the next step to

interfaces we have classes or abstract

classes that come up from these

interfaces so here we have some parking

structure based methods we have parking

space and abstract class parking space

we have a couple of more abstract

classes here and from these abstract

classes we have you know classes

concrete classes that further inherit

from these abstract classes right here

and so on and few more concrete classes

that inherit from these abstract classes

and lastly related classes or inherited

or related by inheritance and unrelated

classes like parking structure and

parking space they are related to each

other using Association

so this would be our high-level design

so far so our next step is to you know

try to refine this model sharpen it and

see if you could use any design patterns

to make the model better so let's

quickly look at a few design patterns so

what exactly are design patterns in the

first place these are solutions to

common problems that we encounter in

articulated paradigms for example here

we have a parking structure but do we

really want everybody to be able to

create a parking structure probably not

in our city or in our system we just

have one parking structure which we want

people to use to park their cars right I

suppose we don't want every car to

create its own parking structure we just

want one parking structure where people

park their cars so how could you ensure

that there is just one parking structure

so one way to do it is through a design

pattern called singleton the key

features of this parameter are you make

the constructor private and you have a

referenced to a object here and a small

typo this object should have been static

this object needs to be static so now

you also have a static method that would

be called by anyone who wants to get the

parking structure object you call get

parking structure and you can see that

the only object that this method would

return is this PS it's only the first

time would you create a new object and

we will always be running the same

object so this way you could make sure

that there is just one parking structure

object in the entire system so

in your Mongolia model identified

classes that you don't want to have

multiple instances off and make them

single term likewise it's also possible

to restrict some classes just to have

you know K objects where I mean where

this is a specialized case where K is

one and then there's the concept of

static factory methods that's

essentially the static method that we

just saw to create a singleton object

but there could be reasons to use the

static method even if you don't want to

restrict the number of objects being

created for example here depending on

the license somebody has we give them a

public parking structure or a private

parking structure object and whatever so

the user or the third party using your

parking structure class they don't
by (9.8k points)  
0 votes
really need to know this entire

hierarchy of public parking structure

private parking structure and so on so

you have a public parking structure

object you have a private parking

structure and and maybe your hierarchy

is much much longer so they don't really

need to know all these details so by

just providing this method parking

structure or get parking structure all

they need to do is get call the get

parking structure object and and they

get a parking structure object the exact

type of the object depends on this

license it could either be a public

parking structure a private parking

structure or whatever the behavior the

runtime behavior would depend on that

license but they are totally transparent

to it they just all that they need to

know is to use the behavior defined in

the interface or abstract class parking

structure it's very similar to the

earlier example that we saw for

inheritance where and you just call the

get set method and

the actual set that's being written to

you could be a hatch set or a tree set

and then we have the strategy pattern so

let us say in our parking structure we

have a calculate payment system and

algorithm to calculate payment and we

would like to use different algorithms

to calculate payments on different days

of the week for example on weekends the

night maybe we don't charge we don't

charge our customers for overnight

parking and maybe during the day for

weekends we charge them a higher rate on

weekends and weekdays and so on so one

way to do this would be you know you

have a lot of a felt classes where you

say if you are using this algorithm you

know use a calculate payment using this

formula if you would like to use the

deccan algorithm use this formula if you

want to use the winter algorithm foil

algorithm use this formula whatever you

could use you could have a bunch of

if-else statements to enforce or to

choose between a bunch of algorithms

however another option could be to use

the strategy pattern here what I do is

instead of I totally avoid the AFL's

plots as you can see here all that I

need to do is I just say I'll go dot

calculate payment and depending on the

algorithm object this could be a big day

algorithm this could be a vacant

algorithm the calculate payment behavior

depends on the underlying algorithm

object the calculate pay model the

behavior of the calculate payment could

either be a big deal with them where

they can algorithm or whatever but I

have totally avoided the if/else part

here by just having an algorithm object

which could be one of the many different

and by using by you setting the right

type of the algorithm object so instead

of having all these if-else I just said

the right type of the algorithm object

so the advantage of doing this is not

just to avoid the if-else statement it

also separates the code better it it has

low coupling because the payment

algorithm class can be in a compiled

separately and you can easily introduce

new air payment newer payment algorithm

classes it can be compiled separately

and so on so the code overall the code

has less coupling and it's a lot easier

to maintain and it's more object

oriented than having a bunch of if-else

statements so go to your design look at

any places where you have multiple

options that you might want to change at

runtime and replace them with the

strategy pattern

so let us essentially have a very basic

version of coming up with an object

oriented parking lot so now I would ask

that you follow these steps and try to

come up with an object-oriented fridge
by (9.8k points)