Category Archives: Week 1

THE SOLID

SOLID

 SOLID is an acronym that stands for five key design principles: Single responsibility principle, Open-closed principle, Liskov substitution principle, Interface segregation principle, and Dependency inversion principle. All five are used by software engineers and provide significant benefits to developers.

 

Principles of SOLID:

  • SRP – Single Responsibility Principle

SRP states that, “a class should have one, and only one, reason to change.” Following this principle means that each class does only one thing and each class or module is responsible for only one part of the program functionality. For simplicity, each class should solve only one problem.

Single responsibility principle is a basic principle that many developers already use to create code. It can be used for classes, software components, and sub-services.

Applying this principle simplifies testing and maintaining the code, simplifies software implementation, and helps prevent unintended consequences of future changes.

  • OCP – Open/Closed Principle

OCP states that software entities (classes, modules, methods, etc.) should be open for extension, but closed for modification.

Practically this means creating software entities whose behavior can be changed without the need to edit and compile the code itself. The easiest way to demonstrate this principle is to focus on the way it does one thing.

  • LSP – Liskov Substitution Principle

LSP states that “any subclass object should be substitutable for the superclass object from which it is derived”.

While this may be a difficult principle to put in place, in many ways it is an extension of a closed principle, as it is a way to ensure that the resulting classes expand the primary class without changing behavior.

  • ISP – Interface Segregation Principle

ISP principle states that “clients should not be forced to implement interfaces they do not use.”

Developers do not just have to start with an existing interface and add new techniques. Instead, start by creating a new interface and then let your class implement as many interactions as needed. Minor interactions mean that developers should prefer composition rather than legacy and by separation over merging. According to this principle, engineers should work to have the most specific client interactions, avoiding the temptation to have one large, general purpose interface.

  • DIP – Dependency Inversion Principle

DIP – Dependency Inversion Principle states that “high level modules should not depend on low level modules; both should depend on abstractions. Abstractions should not depend on details.  Details should depend upon abstractions”

This principle offers a way to decouple software modules. Simply put, dependency inversion principle means that developers should “depend on abstractions, not on concretions.”

Benefits of SOLID principle

  • Accessibility
  • Ease of refactoring
  • Extensibility
  • Debugging
  • Readability

REFERENCES:

  1. https://www.bmc.com/blogs/solid-design-principles/

From the blog CS@Worcester – THE SOLID by isaacstephencs and used with permission of the author. All other rights reserved by the author.

From Warcraft III to My PC: My Inevitable Pairing with Polymorphism

The year was 2005. I was a young child in elementary school, and eventually I was exposed to a little-known strategy game known as Warcraft III. As I championed the human race in my epic quest against the Undead Scourge of Lordaeron, I came across a sorceress ability known as “Polymorphism”. This powerful spell allowed its caster to turn an individual target into a harmless sheep. While entertaining and useful to say the least, little did I know that Polymorphism itself would take on a new form in the years to come…

Fast forward to 2021. I am being exposed once again to Polymorphism, this time as an essential feature of Object-Oriented programming. This would mark the third time that I am working with this concept (the other times being 2016-2017, and 2019 respectively). Polymorphism, in theory, isn’t very difficult: we take one idea (such as a function/method), and give it “many forms” (hence the name) among its various classes that use the function/method.

Listed below is an article about polymorphism from GeeksForGeeks, one of my “personal go-tos” when it comes to learning about programming practices. Specifically, “runtime polymorphism” will be more applicable in my software design class, due to its usage of method overriding. When using the “Strategy Design” of refactoring, we will create various interfaces and have them implemented using respective classes; these classes will then create their own version of the method.

Strategy design refactoring seems to provide an edge over “simple inheritance”, which would involve having a single base class (that all subclasses inherit off of). This “edge” is the removal of inherited methods that serve no purpose in certain subclasses; when the interface is implemented by the class, we can choose exactly what we want and don’t want from polymorphism.

However, having too many interfaces, or not enough data within the interface can cause its own problems. In addition, an interface is just that: a “top-down” view, with nothing beneath it; the methods need to be designed by the class using it. Meanwhile, inheritance may have redundant data, but at least you get all that and a bag of chips. In other words, inheritance provides one portion of functioning methods, plus whatever else is added on in the subclass.

I hope that I can use the idea of polymorphism, alongside interfaces, to reduce the amount of redundancy and complexity in my programs. There is no need to turn a program into a headache with unnecessary amounts of inheritance. In addition, part of this unnecessary material could be redundant – brought along for the ride, but not used during run-time.

Link: https://www.geeksforgeeks.org/polymorphism-in-java/

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

cs@worcester – Dream to Reality 2021-09-26 23:53:59

What are UML Class Diagrams

Foremost, UML diagrams

UML stands for Unified Modeling Language and was invented by Grady Booch, Ivar Jacobson, and James Rumbaugh in 1995 while working at Rational Software. We create UML diagrams to help us comprehend the system more clearly and simply. A single diagram does not represent all aspects of the system. UML defines various kinds of diagrams to cover most of the aspects of a system. UML diagram has two categories of diagrams, Structural Diagrams and Behavioral Diagram. Inside Structural Diagrams, there is Class diagram, Object diagram, Component diagram, and Deployment diagram.

UML class diagrams

Class diagrams are the most common diagrams used in UML. Classes, interfaces, relationships, and collaboration are all represented in class diagrams. The features and activities of a class, as well as the system’s restrictions, are depicted in a class diagram. Class diagrams are often used in the design of object-oriented systems since they are the only UML diagrams that can be directly mapped with object-oriented languages.

What is Class?

A Class is an object’s blueprint. Objects and classes are inextricably linked. We can’t discuss one without discussing the other. And, because we utilize classes to generate objects, the entire objective of Object-Oriented Design is not about objects, but about classes. As a result, while a class describes what an object will be, it is not the object itself. Classes, on the other hand, specify the types of things, whereas objects are useable instances of classes. Each Object was constructed using the same blueprints and so has the same components (properties and methods). An object is a member of a class and has states and behaviors, according to the standard definition.

Examples

An example can be such as there is a base class as an animal dog and we create an instance like Bobby, which is a dog. A dog has properties such as color, eye color, height, weight. And the method example for a dog can be such as a dog can jump, can sit, can eat. And for the object which is Bobby, Bobby has property value. Bobby is a yellow color, he has brown color eye; he is 17 inches tall, and he weights 24 pounds. For the methods Bobby can jump, he can sit, can eat as well.

Why UML class diagrams?

I chose this topic because UML diagrams have always made it easier for me to understand the topic/code. It helps me figure out which classes are inherited from which, which classes are abstract, and so on. For example, a class may override a method, but with the UML diagram/markdown preview, I can easily tell where the original method was created and why I have override that method. Also, since our 1st assignment is about markdown preview and UML diagrams, why not. So far, these two websites have helped me gain a better understanding of UML diagrams. https://www.tutorialspoint.com/uml/uml_standard_diagrams.htm https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

POGIL… the way we’re learning.

POGIL is an acronym which stands for Process Oriented Guided Inquiry Learning.

We’re using this style of teaching in my Computer Architecture and Desig… One of my Software Development courses this semester (the name of the course is significantly long). I can see how this style of teaching can be beneficial to showing how teams get work done in the real world. Each person in the team has a role that they must fulfill. In almost all the groups there are four participants. Each person will have to fill one of four roles; Manager, Recorder, Reflector, and Presenter and be responsible for that role solely. While we are all working as a team to achieve a common goal, I do find it particularly difficult to not impede on my teammates roles and essentially “do their job” for them. I’m not saying that my teammates aren’t doing their jobs adequately. For example, it seems like a far easier task to correct a typo our Recorder has made in our write-ups, but instead I remind myself to tell my teammate “Hey you may have spelled this word wrong, could you go back and fix this please?” While this seems silly the practice makes some type of sense to me.

There’s a joke a friend told me once.

“How many Software devs does it take to fix a light bulb?”

“…”

“None, it’s a hardware problem.”

I must admit he got a hearty chuckle from me when he delivered the corny joke, but there is some truth to this. Each department in a company has a team of people who’s expertise is in a certain area. While they maybe able to fix something that may have gone wrong, their time is a precious resource that they could utilize to focus on other important tasks than to be bogged down by a task that is someone else’s job. While I did highlight a strong point of this type of strategy, I also want to note that I can see how this type of strategy can cause more time to elapse while getting a task completed, but in a sense it is the least complicated way of getting work done I suppose.

In certain settings there may only be one answer to getting a problem correct. But the pathways that lead towards that answer may be limitless. This is where the POGIL approach seems to put its emphasis on its effectiveness of getting students/participants to realize that “logical thinking and teamwork are prized above simply getting the ‘right’ answer”.

You can read more about POGIL here. https://pogil.org/about-pogil/what-is-pogil

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

Blog Discovery

Michael Feathers is a software developer, founder, and director of R7K Research & Conveyance. R7K Research & Conveyance is a company located in Miami Florida. Specializing in software design, they use the importance of the need of the business and intensive planning to meet company demands, plus on top of that to be able to design software where you are aware of the code to make adaptable adjustments in the long run such as, adding new features that are newly needed vs features that are easily removed to make room for new upcoming changes which is referred to as planning. 

He helps other teams and developers to refactor code to improve its performance without rewriting the existing code. Gives best practices to maintain their software with ease such as making test programs as you can optimize it at the same time to keep tabs on it. 

I chose this blog because he provides helpful tips whether they are in Java, Python, C++, etc. and leaks information from his Book “Legacy Code”. Also mentions UML which I could learn more in depth of when we progress further into CS-343. 

In one of his blogs about code refactoring, he discusses that before we make tests for our own code we write, we must evaluate and rethink towards ourselves whether if it is going to fail. He stated, “As you make any change, know with every edit whether that edit changes behavior.” https://michaelfeathers.silvrback.com/testing-yourself, meaning we can’t compile code if it is incomplete, if there is something going wrong, we must figure out the missing piece of the puzzle. I could’ve used this type of thinking back in my other core classes like Data structures, or intro to programming class, because it can only take a small mistake to make your entire code and/or program to fail. Another reason is that Michael gives an example about when working in groups, and the type of challenges you may face such as having trouble putting heads together, not seeing each other’s perspectives. Providing tips and trick to get around obstacles like these. In CS-343, we do POGIL activities when we come into class, each member has roles of their own to keep the teamwork intact, but as he exemplified before we may also “glitch” and we have to figure out why and what can do about it. Depending on how we think and how we get ideas.

Reference blog resource: https://michaelfeathers.silvrback.com , https://www.r7krecon.com

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

Design Principles

The four fundamental ideas of Object-Oriented Programming are Encapsulation, Abstraction, Inheritance, and Polymorphism. OOP allows programmers to approach software development as if they were dealing with real-world objects. People in real life have the skills and expertise to do a variety of tasks. Objects in OOP feature fields for storing knowledge, state, and data, as well as the ability to perform a variety of operations. The basic terms we need to know before getting more into OOP are Object, Class, Method, and Instance.

Object – A class’s instance

Class – A model that describes an object’s functionality

Method – Changing the state of a class applies to all other instances of the class

Instance – Is similar to an object. The blueprint used to build the product is an instance of the class.

Let’s move on to the four fundamental ideas of Object-Oriented Programming:

Encapsulation

When objects are encapsulated inside a class, they each have a private state. Other objects can’t directly access this state, but they can only use a list of public functions to get at it. These functions allow the object to control its own state and no other class has access to it unless access is granted. As a developer, you must use the given ways to communicate with the object. The state of a class invoked by a method created a bond between the private state and public methods.

Abstraction

Abstraction is a continuation of encapsulation. To show just relevant information to an object, data is selected from a large pool. Abstraction is the technique used to get, remove, or select user data from a bigger pool. In the case of abstraction, you can use the same info gathered for a different app to power other programs with little or no coding changes.

Inheritance

Inheritance is the process through which one object gains access to all of the properties of another without actually changing anything about the original. For instance, a child gets personality qualities from both of their parents. Reusability is a significant benefit of inheritance. The existing class’s fields and methods can be reused. Inheritance might be single, multiple, multilevel, hierarchical and hybrid, in Java.

Polymorphism

Polymorphism makes it possible to utilize a class in the same way as its parent, which eliminates the possibility of confusion. As a result, each child sub-class retains its own functions and methods. Each of the child sub-classes should have unique variations.

In a conclusion, Object-Oriented Programming refers to programming languages that use objects. The goal is to implement real-world concepts, keep data and the functions that operate on it separate such that no other part of the code may access it, except for that function.

References:

https://info.keylimeinteractive.com/the-four-pillars-of-object-oriented-programming

https://www.geeksforgeeks.org/understanding-encapsulation-inheritance-polymorphism-abstraction-in-oops/

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

REST Introduction

APIs play an integral role in the development of modern-day applications. Whether you are writing your API or integrating someone else’s, it is crucial to understand their functioning. There are many APIs, but the most common types are REST APIs that operate using HTTP and HTTPS. I chose to write about REST APIs because we will be working with them in this class. They are essential to understand for most development projects. The blog post “Best practices for REST API design” discusses the basics of a REST API, how they work, and development practices. The post also provides code examples using NodeJS with the ExpressJS library showing how the concept of a REST API is implemented.

According to the article, a REST API follows a set of standard design principles that allow users to quickly be able to work with the API. For example, a REST API should include method endpoints such as /GET /POST /PUT and /DELETE. These endpoints are used to send and receive data between the server and the client. The difference between the endpoints is the operations they perform. Sending a request to a GET endpoint will send the client data, a POST request will add data, and a DELETE request will remove data.

Although there are a set of rules a REST API must follow, there are many best practices left up to the developer that they should follow. For example, a REST API should send and receive data in JSON. JSON makes working with data simpler because it is in an easily transferable and structured format. The API should also run over HTTPS rather than HTTP to add an extra level of security between communication.

A REST API closely resembles the structure of a URL where each method is separated by a forward slash. To pass a parameter, a question mark is used followed by the variable name equal to a value. In order to be readable, the developer must name and structure the API paths wisely, based on the function an endpoint is responsible for. For example, a GET request to find a user by ID could look something like /user/findOne?id=120. In this example, the findOne method is prefaced by /user/, and we know the user id we are finding is 120. If the API replaced the word user for record, then the developer using the API would not know what type of data to receive in the request.

Finally, a REST API should be versioned, meaning the highest level path of the URL structure should be the API’s version number. Using the find user example, a versioned API would read /v1/user/findOne?id=120. If we made a change to our API, we could modify that in the v2 API without breaking the code written using the v1 API.

I will definitely use these tips while developing a REST API in the future. One of the most important guidelines I learned was to always send and receive data in JSON. In the past, I have made a REST endpoint return a single value such as a number. Without any context, the data from the API would be hard to understand. If the values were named in JSON then it would be easier to work with and manipulate.

Reference blog resource: stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.

Just A Refresher For OOP Concepts

Hello and welcome back to my blog! I had a really fun time during the first few weeks of the semester and I am looking forward to the rest of it. The first POGIL group activity we did caught me off guard since I did not remember what the terms abstraction, encapsulation, polymorphism, and inheritance meant. These concepts were taught in one of the earlier programming classes and I have done school projects and labs that involved these concepts in the past. But I don’t actually remember the terms or the clear cut definitions of them. Maybe part of the reason why I did not remember them is because we briefly went over those topics and we were also not forced to remember them since those classes were more about if you could write the code correctly. So that is why I decided to focus my blog around those four concepts. The in-class activity was a good refresher but I wanted to do research to fully have a firm understanding of them. Having a strong understanding of these concepts will help me later on in my computer science journey since these concepts are going to be seen over and over again in object orientated programming.

Let’s start with abstraction. Abstraction is basically hiding unnecessary details and leaving only the necessary and relevant details. Hiding unnecessary information is useful because, well, it is not needed to show that information to the user. An example in real life is your smart phone. All that’s important to the user is the screen and they do not need to know what processor or how much RAM the phone has.

Encapsulation is bundling data with the code that modifies the data and it can also prevent outside sources from accessing that data. In Java, encapsulation is used in classes where data can be declared as private and outside methods cannot access that data.

Polymorphism is the ability to take on many forms. In Java, that means you can perform one tank many ways. An example of that is calculating the area of a shape. You can use the same method area() to calculate the area of a triangle, octagon, or any other shape. There’s also overriding methods where the child class has the same method as the parent class.

Inheritance is gaining the properties of one class to another class. It’s like a parent-child relationship. In Java, a child class inherits all the methods and attributes from its parent class. The vehicle example is a really good one. Vehicle would be the parent class and car and truck would be the child classes. Both car and truck would share the same attributes from vehicle but also have their own attributes as well.

This has been a good review for me and the website really helped me understand what the four OOP concepts are. In the future I hope to apply all of these concepts into my work.

Site used: https://www.nerd.vision/post/polymorphism-encapsulation-data-abstraction-and-inheritance-in-object-oriented-programming

 

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Just A Refresher For OOP Concepts

Hello and welcome back to my blog! I had a really fun time during the first few weeks of the semester and I am looking forward to the rest of it. The first POGIL group activity we did caught me off guard since I did not remember what the terms abstraction, encapsulation, polymorphism, and inheritance meant. These concepts were taught in one of the earlier programming classes and I have done school projects and labs that involved these concepts in the past. But I don’t actually remember the terms or the clear cut definitions of them. Maybe part of the reason why I did not remember them is because we briefly went over those topics and we were also not forced to remember them since those classes were more about if you could write the code correctly. So that is why I decided to focus my blog around those four concepts. The in-class activity was a good refresher but I wanted to do research to fully have a firm understanding of them. Having a strong understanding of these concepts will help me later on in my computer science journey since these concepts are going to be seen over and over again in object orientated programming.

Let’s start with abstraction. Abstraction is basically hiding unnecessary details and leaving only the necessary and relevant details. Hiding unnecessary information is useful because, well, it is not needed to show that information to the user. An example in real life is your smart phone. All that’s important to the user is the screen and they do not need to know what processor or how much RAM the phone has.

Encapsulation is bundling data with the code that modifies the data and it can also prevent outside sources from accessing that data. In Java, encapsulation is used in classes where data can be declared as private and outside methods cannot access that data.

Polymorphism is the ability to take on many forms. In Java, that means you can perform one tank many ways. An example of that is calculating the area of a shape. You can use the same method area() to calculate the area of a triangle, octagon, or any other shape. There’s also overriding methods where the child class has the same method as the parent class.

Inheritance is gaining the properties of one class to another class. It’s like a parent-child relationship. In Java, a child class inherits all the methods and attributes from its parent class. The vehicle example is a really good one. Vehicle would be the parent class and car and truck would be the child classes. Both car and truck would share the same attributes from vehicle but also have their own attributes as well.

This has been a good review for me and the website really helped me understand what the four OOP concepts are. In the future I hope to apply all of these concepts into my work.

Site used: https://www.nerd.vision/post/polymorphism-encapsulation-data-abstraction-and-inheritance-in-object-oriented-programming

 

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Just A Refresher For OOP Concepts

Hello and welcome back to my blog! I had a really fun time during the first few weeks of the semester and I am looking forward to the rest of it. The first POGIL group activity we did caught me off guard since I did not remember what the terms abstraction, encapsulation, polymorphism, and inheritance meant. These concepts were taught in one of the earlier programming classes and I have done school projects and labs that involved these concepts in the past. But I don’t actually remember the terms or the clear cut definitions of them. Maybe part of the reason why I did not remember them is because we briefly went over those topics and we were also not forced to remember them since those classes were more about if you could write the code correctly. So that is why I decided to focus my blog around those four concepts. The in-class activity was a good refresher but I wanted to do research to fully have a firm understanding of them. Having a strong understanding of these concepts will help me later on in my computer science journey since these concepts are going to be seen over and over again in object orientated programming.

Let’s start with abstraction. Abstraction is basically hiding unnecessary details and leaving only the necessary and relevant details. Hiding unnecessary information is useful because, well, it is not needed to show that information to the user. An example in real life is your smart phone. All that’s important to the user is the screen and they do not need to know what processor or how much RAM the phone has.

Encapsulation is bundling data with the code that modifies the data and it can also prevent outside sources from accessing that data. In Java, encapsulation is used in classes where data can be declared as private and outside methods cannot access that data.

Polymorphism is the ability to take on many forms. In Java, that means you can perform one tank many ways. An example of that is calculating the area of a shape. You can use the same method area() to calculate the area of a triangle, octagon, or any other shape. There’s also overriding methods where the child class has the same method as the parent class.

Inheritance is gaining the properties of one class to another class. It’s like a parent-child relationship. In Java, a child class inherits all the methods and attributes from its parent class. The vehicle example is a really good one. Vehicle would be the parent class and car and truck would be the child classes. Both car and truck would share the same attributes from vehicle but also have their own attributes as well.

This has been a good review for me and the website really helped me understand what the four OOP concepts are. In the future I hope to apply all of these concepts into my work.

Site used: https://www.nerd.vision/post/polymorphism-encapsulation-data-abstraction-and-inheritance-in-object-oriented-programming

 

From the blog Comfy Blog by and used with permission of the author. All other rights reserved by the author.