Category Archives: CS-343

Object Oriented Programming

OOP is used to structure a software program into simple, reusable pieces of code blueprints (usually called classes), which are used to create individual instances of objects.

Building blocks of OOP:

Classes are where we create a blueprint for the structure of methods and attributes. Individual objects are instantiated or created from this blueprint. For example, we can look at Duck class covered in class activity.
Objects are instances of classes created with specific data, for example rubber duck is an instance of duck class. It is crucial to remember that class is a template for modeling (a duck in our example), and an object is instantiated from the class representing an individual real-world thing (a rubber duck in our example).
Methods perform actions; methods might return information about an object or update an object’s data. The method’s code is defined in the class definition. In simple terms, methods represent behavior. For our Duck example, ducks had methods like fly() and quack(). Duck’s had different behavior. Rubber duck did not fly and did not quack but squeaked. These behaviors are specified in methods.
When objects are instantiated, individual objects contain data stored in the Attributes. State of objects depend on data in attribute. For example, Rubber duck is handled differently than a mallard duck based on the information in attributes.

The four principles of OOP:

Inheritance allows classes to inherit features of other classes. Basically, child classes inherit data and behaviors from parent class. In our example, Rubber duck inherited display() from duck class.

Encapsulation is containing information in an object and exposing only selected information to other classes. Private methods and properties are accessible by other methods of the same class. Public methods and properties are accessible by methods of other classes too.

Abstraction is using simple classes to represent complexity. It uses simple things to reduce complexity. Abstraction means that the user interacts with only selected attributes and methods of an object. Abstraction is used in interface. In FlyBehavior we had abstract fly() which was defined in concrete classes as flyWithWings or flyNoWay.

Polymorphism uses inheritance. Objects can override shared parent behaviors, with specific child behaviors. In method overriding, a child class can provide a different implementation than its parent class. In method overloading methods or functions may have the same name, but a different number of parameters passed into the method call.

Abstraction reduces complexity and constant overriding of method. Inheritance gives reusable structure across program. Polymorphism allows for class-specific behavior and objects of different types to be passed through the same interface. Encapsulation helps us prevent unwarranted change of important data by developers. Also, Prevents greater security risks like phishing that we face today.Advantages of OOP will never die out. Therefore, I have written this blog explaining OOP and I hope it has been useful.

Sources

https://codecoda.com/en/blog/entry/object-oriented-programming

What is Object-Oriented Programming? OOP Explained

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Understanding Docker Compose and its Benefits

Recently, I worked with bash scripts and docker-compose files in order to run a set of containers. While both seemed to be valid ways of running multiple containers in Docker, I wanted to look into docker-compose files further to understand the possible advantages and use cases. A resource that I found quite helpful was The Definitive Guide to Docker compose, a blog post by Gabriel Tanner. Inside, he explains why we should care about Docker-compose and the potential use cases.

Docker Compose

Let us first go over what Docker Compose is. According to the Docker Compose documentation, “Compose is a tool for defining and running multi-container Docker applications. With Compose, you use a YAML file to configure your application’s services. Then, with a single command, you create and start all the services from your configuration.” Instead of listing each docker run command in a script, Compose utilizes a docker-compose.yml file to handle multiple docker containers at once.

Here’s a sample docker-compose.yml file:

You might be able to recognize some of the labels such as image, ports, and volumes. All of which would normally be specified in a docker run command. And as you can see, each individual container is listed under the services tag. The docker command equivalent to run web1 would be something like: docker run -it –name web1 -p 10000:80 -v ${PWD}/web1:/usr/share/nginx/html -d nginx:mainline

Tanner explains that almost every compose file should include:

The version of the compose file
The services which will be built
All used volumes
The networks which connect the different services

Now that we have a brief understanding of the docker-compose file structure, let’s talk about the use cases for Compose and their benefits.

Portable Development Environments

As opposed to running multiple containers with a separate docker run command, you can simply use docker-compose up to deploy all the containers specified in your docker-compose.yml file. And it is just as easy to stop all of the containers by running docker-compose down. This provides developers the ability to run an application and configure the services all within a single environment. Since the compose file manages all of the dependencies, it is possible to run an application on any machine with Docker installed.

Automated Testing

A beneficial use case of a docker-compose file is with automated testing environments. Compose offers an isolated testing environment that closely resembles your local OS that can easily be created or destroyed.

Single Host Deployments

Compose can be used to deploy and manage multiple containers on a single system. Because applications are maintained in an isolated environment, it is possible to run multiple copies of the same environment on one machine. And when running through Docker Compose, interference between different projects are prevented.

Conclusion

Hopefully this blog post helped you learn more about Docker Compose as much as it helped me. For the most part, docker-compose files make it possible to run multi-container applications with a single command. While researching this topic, I’ve come to believe that docker compose files will be the standard for running applications through Docker if it isn’t already. I’d like to write more about this topic, and I think a blog post going in-depth on the structure of docker-compose files would be useful.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Code Smells

Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue.

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell.

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem.

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.