Week 28 – Polymorphism

This week I’ve decided to change the format a bit, and just answer the questions straight, rather than answer them in the essay format I’ve been using. Lets see how it all works out!

Give an example of polymorphism and what what be inherited between classes.

For a simple example, the constructors we have been working on are one of the definitions of polymorphism. Having a function with the same name but that takes a different set of parameters and uses Static Binding for the function resolution.

For a different concrete example, take a class such as Class Weather with a function public bool setConditions(int pressure, float temperature). If the class is extended, we may need to change those conditions to depending on the weather type. For instance a Class SeaWeather may need to include wind direction as a relevant factor: bool setConditions(int pres, float temp, char windDirection), while an astronaut using the Class SpaceWeather may only care about temperature to ensure instruments work bool setConditions(int temp).

After the learning this week, can you identify the difference between Abstract classes and Interfaces?  Be specific:

Abstract classes are classes that cannot be instantiated. They are usually used as a the base class to be inherited from. However, they can often implement common functionality, or define variables or behavior that will be used by the children classes. An abstract class is not implemented. The intention of an abstract class is often to provide a basic foundation for the children and to centralized the common functionality, and provide the minimum parameters required for all the children to work. Additionally, an abstract class can itself implement interfaces or extend classes.

A common example is a abstract class Vehicle {} which could implement things like speedUp() or have a variable int numWheels. The vehicle is just the idea to be implemented by children such as class bycicle or class train which have common functionality or implementations.

Interfaces on the other hand are not extended but implemented. Unlike abstract classes, all methods are abstract and the interface cannot have implementations of any of the methods. Additionally, any variables must be final. The main intention of an interface is to define the minimum implementation required by the implementing classes to have. It’s often used as a contract to ensure that programs know what the functionality is available. It specifies not common implementations or common functionality or behaviors, but rather the required functions that need to be implemented to honor the contract.

A common case for interfaces are database connectors, where different databases may have different underlying mechanisms to extract, create or update data. However, an interface may require that all connectors should implement the GetValue(String Key) function. A SQL connector my run a SELECT statement, while a redis connector would run a GET statement. In this case, the implementations would be very different. But because the contract is honored, a program can rely on the function to be present and work seamlessly regardless of what datastore is used.

Update your learning journal from what you experienced this week with class. 

This week has been fairly challenging. As assignments get more complicated, we also have had to look for ways to collaborate with each other, and make sure we deliver quality code. As a group, we have been trying to implement a bit more formal code reviews through pull requests. This is the first week trying it and so it will be a bit of a learning curve, but I’m hoping the small growing pain will make future projects and classes a bit more successful (I’m looking at capstone for instance).

The work however has been very interesting. I always wanted to know how QR Codes work, but always found myself a bit too lazy to find out. Having this small project does put some of this technology in perspective and it’s pretty neat solution! I’d love to do more work around the camera and and capturing real data to see how the thing actually works beyond the “star-and-space” examples we’re using.

On the other hand, I found the fact that we’re learning a little about UML super amusing, specially since I wrote about me wanting to learn it better just a few weeks ago! I still wish we dove a little deeper but I’ll settle for getting my toes wet and hopefully not making any more rookie mistakes when i have to create diagrams anymore!

This entry was posted in CST-338, CSUMB. Bookmark the permalink.