Teach me CS stuff for interviews

[Kibblre]

Re: Teach me CS stuff for interviews

Rubix, my CS professor puts out videos all the time for us on new subjects including all the things you listed. Although it's in Java, you should be able to get something out of it in the very least. Here's the playlist: http://www.youtube.com/watch?v=LWyEN...bu2B5lvxrPuA3E . The videos start about basics of Java, but some of the videos are about topics you've asked for clarification on.

EDIT: Looked up a couple posts and you mentioned OOP. The class is literally called Object Oriented Programming. Most of the stuff he teaches us is through these videos, so you're basically taking the class I'm taking if you watch them.

[Reincarnate]

Re: Teach me CS stuff for interviews

thanks for the link, Kibblre - I'll definitely give those a watch

[Reincarnate]

Re: Teach me CS stuff for interviews

hrrngg

[benguino]

Re: Teach me CS stuff for interviews

I can try to go over those last few topics later today (I'm on my phone atm and won't be on my lappy till a bit later.)

[FissionMailed1]

Re: Teach me CS stuff for interviews

These explanations will use C++. I will use method and function interchangeably.

Polymorphism: Suppose you have a base class that you have other classes inherit from. I will use a C++ snippet as an example.

class Foo {};
class Bar1 : public Foo {};
class Bar2 : public Foo {};

Now, somewhere later in your program lets say you now want to declare a container of "Foo"s, as such:

Foo bunch_of_Foos[100];

And then, after that, you want to now instantiate a bunch of objects in this container. This is the part that gets a little tricky. The following code segments are valid C++:

bunch_of_Foos[0] = new Bar1();
bunch_of_Foos[1] = new Bar2();

Now, if you want access bunch_of_Foos[0] or bunch_of_Foos[1] anywhere in your program, your program uses a virtual table to resolve the address of the derived class. What this means is that if I were to use bunch_of_Foos[0], the type would resolve to be Bar1 because the program keeps a pointer in the virtual table to this class when you instantiated it.

Why is this useful? Now lets say you want to iterate over the bunch_of_Foos container. What you could do is:

for (int i = 0; i < bunch_of_Foos.size(); ++i)
bunch_of_Foos[i]->doWork();

And this will work, assuming bunch_of_Foos is a pointer container and doWork() is in the base class. Now you can iterate over a bunch of different types of objects, as long as they share a common base class.

Interfaces: Interfaces are classes that are not allowed to contain data or state. The purpose of interfaces is to make sure that classes that decide to implement an interface have a conformant set of functions. In C++, there is no interface construct. Interfaces only contain pure virtual functions, nothing else. To use the interface idiom in C++, you just inherit it much like you would any other class.

Abstract classes: An abstract class in C++ is one that contains pure virtual functions. When you declare virtual functions inside of a class, you must have classes that inherit from it. Additionally, you can not instantiate abstract classes unless they are pointers. When you call a pure virtual function anywhere with a program, the program will look at the derived class' implementation of said pure virtual function and execute that. This lends itself well to using polymorphism, as explained above, as do interfaces.

Abstraction and encapsulation: This is a very general term, so I will explain it the best I can. The main idea behind abstraction is hiding away lower level details. Suppose I have a Car class:

class Car {
private:
void do_internal_stuff();
void do_more_internal_stuff();
void do_even_more_internal_stuff();
public:
void drive();
void honk_horn();
void accelerate();
}

The only thing that I need to worry about, as a driver, is being able to drive the car. I don't have to worry about the internals of the car, the drive() method and the accelerate() method will take car of all of the internals by calling do_internal_stuff(), do_more_internal_stuff() etc. The abstraction this idea of being able to drive(), honk_horn(), and accelerate(). The encapsulation is the private methods that are called as a result of calling drive(), honk_horn(), and accelerate() in order to maintain the Car object's state, but won't be called directly.

[Reincarnate]

Re: Teach me CS stuff for interviews

any more detail on polymorphism / interfaces / virtual functions?

[benguino]

Re: Teach me CS stuff for interviews

I can give additional examples and clarification after classes today (I got class in 5 minutes so I don't have any time to type up anything right now)

[FissionMailed1]

Re: Teach me CS stuff for interviews

any more detail on polymorphism / interfaces / virtual functions?

Virtual functions are essentially those which make use of the virtual keyword. The virtual keyword does two different things in C++. If your function is not pure virtual (i.e. it has an implementation), but simply virtual, then it will use the implementation of the function in the base class if there is no class that inherits from it. Otherwise, if you have classes that inherit from this class that decide to implement this function, the base class' implementation will be overridden by the derived class' implementation. Pure virtual functions are ones that do not have any implementation in the base class, make the class unable to be instantiated unless it is a pointer, and require any derived classes to implement them.

With that definition of pure virtual, interfaces should make more sense. As I explained before, interfaces only contain pure virtual functions, they do not contain any data members.

Polymorphism is hard to wrap your head around at first, but I will try to give another example to explain it.

Suppose you have a base class called "Animal".

class Animal {
public:
virtual void make_sound {};
}

Now suppose you have 3 more classes that inherit from animal.

class Dog : public Animal {
public:
void make_sound {};
}

class Cat : public Animal {
public:
void make_sound {};
}

class Pig : public Animal {
public:
void make_sound {};
}

Finally, I will create an array of 3 Animal pointers and instantiate a Dog, Cat, and Pig.

Animal** animal_array = new Animal*[3];

animal_array[0] = new Dog();
animal_array[1] = new Cat();
animal_array[2] = new Pig();

And the following code segment will demonstrate polymorphism:

for (int i = 0; i < 3; ++i)
animal_array[i]->make_sound();

What happens here is that at run-time, your program will look at the virtual function table for your Animal class and then it will find out what the derived class types are in order to execute their implementations. In other words, your program will now cause an object of type Dog, Cat, and Pig to make a sound. The polymorphic behavior here is that instead of causing three Animal objects to make sounds, more specific types of animals make sounds instead.

[Reincarnate]

Re: Teach me CS stuff for interviews

I guess I am still a little lost.

Why bother having


public:
void make_sound {};


in the subclasses at all? They already inherit from Animal -- so couldn't calling make_sound just call the function from the Animal class?

[FissionMailed1]

Re: Teach me CS stuff for interviews

If you just call make_sound() from the Animal class and you don't declare make_sound() in your subclasses, your program will execute Animal's make_sound() function. Sometimes this isn't the behavior you want. The make_sound() function isn't pure virtual, so I could do something like this:

Animal* animal_array_2 = new Animal[3];

animal_array_2[0] = new Dog();
animal_array_2[1] = new Cat();
animal_array_2[2] = new Pig();

for (int i = 0; i < 3; ++i)
animal_array[i].make_sound();

And this code won't compile. The reason being is that you are trying to use Dog, Cat, and Pigs constructors for an Animal object, which isn't valid C++, unless animal_array_2 is a pointer array. I could, however, do this:

animal_array_2[0] = new Animal();
animal_array_2[1] = new Animal();
animal_array_2[2] = new Animal();

and execute that same loop. This would be valid C++. But now, you aren't calling the subclasses make_sound() function, just Animal's.

[Reincarnate]

Re: Teach me CS stuff for interviews

So to take it to the other side: if I am calling the subclass' make_sound(), why have it present in animal?

[FissionMailed1]

Re: Teach me CS stuff for interviews

If you don't have a make_sound() function in the Animal class, you will not be able to iterate over a container of generic Animal objects. You would only be able to call make_sound() for one type on animal, not multiple types.

[Reincarnate]

Re: Teach me CS stuff for interviews

Sorry I am at work at the moment so I'm reading these posts at light speed, so I may be asking dumb questions here.

Does this polymorphism concept only apply to iteration? For instance if I instantiated a Cat inheriting from Animal and simply called make_sound() from it, which one does it invoke? What differentiates whether I call animal's make_sound() or the cat's?

[UserNameGoesHere]

Re: Teach me CS stuff for interviews

If the Cat class implements a make_sound function, and you call make_sound on a Cat object, you are calling the make_sound from the Cat class unless you first cast the Cat object to be of type Animal (assuming Cat class inherits from Animal class), in which case you'd be calling the make_sound from Animal class.

If the Cat class does not implement a make_sound function, but inherits from an Animal class which does, and you call the make_sound function, you are calling the one from the Animal class.

[FissionMailed1]

Re: Teach me CS stuff for interviews

Sorry I am at work at the moment so I'm reading these posts at light speed, so I may be asking dumb questions here.

Does this polymorphism concept only apply to iteration? For instance if I instantiated a Cat inheriting from Animal and simply called make_sound() from it, which one does it invoke? What differentiates whether I call animal's make_sound() or the cat's?

No, polymorphism doesn't apply to just iteration. I think it is the best example to explain it though, so that's why I used it. In regards to which make_sound() is called, it depends on whether make_sound in Animal is virtual or pure virtual. If it is either one, Cat's make_sound() will always be called. If make_sound() is not virtual, then the make_sound() that is called depends on the type that was initially declare, or if Cat declared make_sound() at all. For example:

Animal generic_animal = new Animal();
Cat generic_cat = new Cat();

generic_animal.make_sound();
generic_cat.make_sound();

This will behave exactly as you expect it to behave, and generic_animal's make_sound() will be called, followed by generic_cat's make_sound().