Hello and welcome to the last post of my blog. I’ve really enjoyed writing these throughout the semester since it helped me learn more about computer science and programming in general. For this last week, I will talk about refactoring. It is one of the most important concepts to grasp in programming because it can greatly improve your code over time. Refactoring is a way of rewriting and improving code without changing the functionality of the original code. Your code may be hard to look at or understand by other programmers so you may want to refactor it to make it easier to read and understand.

Your code should be clean so you don’t end up having technical debt later on. Rushing your coding to meet deadlines will pretty much guarantee messy code and you should start refactoring early on so that the messy code does not keep piling up. When messy code keeps piling up, it becomes more of a burden to refactor and the programmer may become more unmotivated to fix it. When you refactor code, you want to make sure all your variable and method names make sense and provide some context. For example, the variable name “x” does not provide any information about what information it stores or what it is used in. Instead, your variable name should be more specific, like “accountNumber.” Having more specific variable names also helps other programmers identify what your code does exactly.

You want to start looking at refactoring at specific times during your coding process. Refactoring Guru talks about the “Rule of Three” which means when you have to code the same thing for the third time you should consider refactoring. Also consider beginning to refactor when you add a new feature because someone else’s code might be too messy to read and you need to refactor to clean it up. That also makes it easier to implement additional features later down the line. You should also consider refactoring close to the deadline of your project since it will be the last chance to make changes to the code. Your project will become open to the public and you do not want other people to see your messy code.

When you refactor, the code should become cleaner and still maintain its functionality. Sometimes you may have to completely rewrite some parts of your code in order to do this. Other times it may just be as simple as adding some spacing or renaming a variable. All your tests should still pass after refactoring. If a test fails, you messed up somewhere and made an error.

In the past, I have done some refactoring myself and I hope to continue to practice refactoring to keep my code clean, easy to understand, and easy to manage.

https://refactoring.guru/refactoring

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

Hello and welcome to the last post of my blog. I’ve really enjoyed writing these throughout the semester since it helped me learn more about computer science and programming in general. For this last week, I will talk about refactoring. It is one of the most important concepts to grasp in programming because it can greatly improve your code over time. Refactoring is a way of rewriting and improving code without changing the functionality of the original code. Your code may be hard to look at or understand by other programmers so you may want to refactor it to make it easier to read and understand.

Your code should be clean so you don’t end up having technical debt later on. Rushing your coding to meet deadlines will pretty much guarantee messy code and you should start refactoring early on so that the messy code does not keep piling up. When messy code keeps piling up, it becomes more of a burden to refactor and the programmer may become more unmotivated to fix it. When you refactor code, you want to make sure all your variable and method names make sense and provide some context. For example, the variable name “x” does not provide any information about what information it stores or what it is used in. Instead, your variable name should be more specific, like “accountNumber.” Having more specific variable names also helps other programmers identify what your code does exactly.

You want to start looking at refactoring at specific times during your coding process. Refactoring Guru talks about the “Rule of Three” which means when you have to code the same thing for the third time you should consider refactoring. Also consider beginning to refactor when you add a new feature because someone else’s code might be too messy to read and you need to refactor to clean it up. That also makes it easier to implement additional features later down the line. You should also consider refactoring close to the deadline of your project since it will be the last chance to make changes to the code. Your project will become open to the public and you do not want other people to see your messy code.

When you refactor, the code should become cleaner and still maintain its functionality. Sometimes you may have to completely rewrite some parts of your code in order to do this. Other times it may just be as simple as adding some spacing or renaming a variable. All your tests should still pass after refactoring. If a test fails, you messed up somewhere and made an error.

In the past, I have done some refactoring myself and I hope to continue to practice refactoring to keep my code clean, easy to understand, and easy to manage.

https://refactoring.guru/refactoring

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

Hello and welcome to the last post of my blog. I’ve really enjoyed writing these throughout the semester since it helped me learn more about computer science and programming in general. For this last week, I will talk about refactoring. It is one of the most important concepts to grasp in programming because it can greatly improve your code over time. Refactoring is a way of rewriting and improving code without changing the functionality of the original code. Your code may be hard to look at or understand by other programmers so you may want to refactor it to make it easier to read and understand.

Your code should be clean so you don’t end up having technical debt later on. Rushing your coding to meet deadlines will pretty much guarantee messy code and you should start refactoring early on so that the messy code does not keep piling up. When messy code keeps piling up, it becomes more of a burden to refactor and the programmer may become more unmotivated to fix it. When you refactor code, you want to make sure all your variable and method names make sense and provide some context. For example, the variable name “x” does not provide any information about what information it stores or what it is used in. Instead, your variable name should be more specific, like “accountNumber.” Having more specific variable names also helps other programmers identify what your code does exactly.

You want to start looking at refactoring at specific times during your coding process. Refactoring Guru talks about the “Rule of Three” which means when you have to code the same thing for the third time you should consider refactoring. Also consider beginning to refactor when you add a new feature because someone else’s code might be too messy to read and you need to refactor to clean it up. That also makes it easier to implement additional features later down the line. You should also consider refactoring close to the deadline of your project since it will be the last chance to make changes to the code. Your project will become open to the public and you do not want other people to see your messy code.

When you refactor, the code should become cleaner and still maintain its functionality. Sometimes you may have to completely rewrite some parts of your code in order to do this. Other times it may just be as simple as adding some spacing or renaming a variable. All your tests should still pass after refactoring. If a test fails, you messed up somewhere and made an error.

In the past, I have done some refactoring myself and I hope to continue to practice refactoring to keep my code clean, easy to understand, and easy to manage.

https://refactoring.guru/refactoring

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

Hello and welcome to the last post of my blog. I’ve really enjoyed writing these throughout the semester since it helped me learn more about computer science and programming in general. For this last week, I will talk about refactoring. It is one of the most important concepts to grasp in programming because it can greatly improve your code over time. Refactoring is a way of rewriting and improving code without changing the functionality of the original code. Your code may be hard to look at or understand by other programmers so you may want to refactor it to make it easier to read and understand.

Your code should be clean so you don’t end up having technical debt later on. Rushing your coding to meet deadlines will pretty much guarantee messy code and you should start refactoring early on so that the messy code does not keep piling up. When messy code keeps piling up, it becomes more of a burden to refactor and the programmer may become more unmotivated to fix it. When you refactor code, you want to make sure all your variable and method names make sense and provide some context. For example, the variable name “x” does not provide any information about what information it stores or what it is used in. Instead, your variable name should be more specific, like “accountNumber.” Having more specific variable names also helps other programmers identify what your code does exactly.

You want to start looking at refactoring at specific times during your coding process. Refactoring Guru talks about the “Rule of Three” which means when you have to code the same thing for the third time you should consider refactoring. Also consider beginning to refactor when you add a new feature because someone else’s code might be too messy to read and you need to refactor to clean it up. That also makes it easier to implement additional features later down the line. You should also consider refactoring close to the deadline of your project since it will be the last chance to make changes to the code. Your project will become open to the public and you do not want other people to see your messy code.

When you refactor, the code should become cleaner and still maintain its functionality. Sometimes you may have to completely rewrite some parts of your code in order to do this. Other times it may just be as simple as adding some spacing or renaming a variable. All your tests should still pass after refactoring. If a test fails, you messed up somewhere and made an error.

In the past, I have done some refactoring myself and I hope to continue to practice refactoring to keep my code clean, easy to understand, and easy to manage.

https://refactoring.guru/refactoring

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

Hello and welcome to the last post of my blog. I’ve really enjoyed writing these throughout the semester since it helped me learn more about computer science and programming in general. For this last week, I will talk about refactoring. It is one of the most important concepts to grasp in programming because it can greatly improve your code over time. Refactoring is a way of rewriting and improving code without changing the functionality of the original code. Your code may be hard to look at or understand by other programmers so you may want to refactor it to make it easier to read and understand.

Your code should be clean so you don’t end up having technical debt later on. Rushing your coding to meet deadlines will pretty much guarantee messy code and you should start refactoring early on so that the messy code does not keep piling up. When messy code keeps piling up, it becomes more of a burden to refactor and the programmer may become more unmotivated to fix it. When you refactor code, you want to make sure all your variable and method names make sense and provide some context. For example, the variable name “x” does not provide any information about what information it stores or what it is used in. Instead, your variable name should be more specific, like “accountNumber.” Having more specific variable names also helps other programmers identify what your code does exactly.

You want to start looking at refactoring at specific times during your coding process. Refactoring Guru talks about the “Rule of Three” which means when you have to code the same thing for the third time you should consider refactoring. Also consider beginning to refactor when you add a new feature because someone else’s code might be too messy to read and you need to refactor to clean it up. That also makes it easier to implement additional features later down the line. You should also consider refactoring close to the deadline of your project since it will be the last chance to make changes to the code. Your project will become open to the public and you do not want other people to see your messy code.

When you refactor, the code should become cleaner and still maintain its functionality. Sometimes you may have to completely rewrite some parts of your code in order to do this. Other times it may just be as simple as adding some spacing or renaming a variable. All your tests should still pass after refactoring. If a test fails, you messed up somewhere and made an error.

In the past, I have done some refactoring myself and I hope to continue to practice refactoring to keep my code clean, easy to understand, and easy to manage.

https://refactoring.guru/refactoring

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

Hello and welcome to the last post of my blog. I’ve really enjoyed writing these throughout the semester since it helped me learn more about computer science and programming in general. For this last week, I will talk about refactoring. It is one of the most important concepts to grasp in programming because it can greatly improve your code over time. Refactoring is a way of rewriting and improving code without changing the functionality of the original code. Your code may be hard to look at or understand by other programmers so you may want to refactor it to make it easier to read and understand.

Your code should be clean so you don’t end up having technical debt later on. Rushing your coding to meet deadlines will pretty much guarantee messy code and you should start refactoring early on so that the messy code does not keep piling up. When messy code keeps piling up, it becomes more of a burden to refactor and the programmer may become more unmotivated to fix it. When you refactor code, you want to make sure all your variable and method names make sense and provide some context. For example, the variable name “x” does not provide any information about what information it stores or what it is used in. Instead, your variable name should be more specific, like “accountNumber.” Having more specific variable names also helps other programmers identify what your code does exactly.

You want to start looking at refactoring at specific times during your coding process. Refactoring Guru talks about the “Rule of Three” which means when you have to code the same thing for the third time you should consider refactoring. Also consider beginning to refactor when you add a new feature because someone else’s code might be too messy to read and you need to refactor to clean it up. That also makes it easier to implement additional features later down the line. You should also consider refactoring close to the deadline of your project since it will be the last chance to make changes to the code. Your project will become open to the public and you do not want other people to see your messy code.

When you refactor, the code should become cleaner and still maintain its functionality. Sometimes you may have to completely rewrite some parts of your code in order to do this. Other times it may just be as simple as adding some spacing or renaming a variable. All your tests should still pass after refactoring. If a test fails, you messed up somewhere and made an error.

In the past, I have done some refactoring myself and I hope to continue to practice refactoring to keep my code clean, easy to understand, and easy to manage.

https://refactoring.guru/refactoring

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

Looking at more frontend frameworks, this blog post was originally going to be used to take a look at Angular.js, but with its EOL soon approaching on December 31, 2021, I thought it may be better to look at a framework that is still receiving support from its developers. Angular (No js) is another type of framework that allows you to develop front-end applications. Angular works off of four main concepts : Components, Templates, Directives, and Dependency Injection. 

Components in Angular (like other frameworks and libraries) are the bread and butter of the framework. You need them in order to design your application. Every component in Angular has three pieces that make it whole. The first piece is an HTML template which is responsible for what can be seen on the page. The second piece involves the use of TypeScript. TypeScript works like JavaScript but has added support to work with types like in object-oriented programming. A class is written in TypeScript and it then defines the behavior of the component. The third piece is a CSS selector which determines how the component should be used.

Templates are the working parts of HTML in your application. They can be present in a component in one of two ways: “template” which allows you to define the content that goes in the component, or “templateUrl” which allows you to define the content of the component using a reference to another file. It’s important to note that only one of these declarations can be used in a component at a time. Because a template represents the HTML element it refers to, it allows the developer to omit the use of HTML tags while creating it.

Directives are like classes that allow you to add extra functionality to the elements in your application. Angular currently uses three types of directives. Components are the first type of directive which is defined as a directive with a template. The second directive is an attribute directive. This directive’s purpose is to change the appearance and or behavior of an entity within the application. The third directive is a structural directive. This directive allows you to change the Document Object Model (DOM) layout by adding or removing DOM elements.

Dependency Injection is a design pattern. Angular uses this pattern whenever a class needs an outside service in order to be able to carry out its functions. Instead of creating a new instance every time a service is needed which can be resource deficient, during runtime, the needed service(s) can be called upon and referred to.

Angular even has its own Command Line Interface(CLI) to help make the use of the framework more simplistic for the developer. 

I learned about the Angular framework in the link below. You can use it to find out more about things I didn’t get to mention in this post.

https://angular.io/guide/understanding-angular-overview

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.

For this week’s blog post, I have found an article about encapsulation. Encapsulation is more than defining accessor and mutator methods. It also follows two main objectives hiding complexity and hiding the sources of change. To understand more about encapsulation, we will first need to understand the two concepts of modularity and abstraction. In the article, Edwin Dalorzo, the author of the article, uses the example of a car to understand abstraction. He says on this, “A car is complex in its internal working. They have several subsystems, like the transmission system, the break system, the fuel system, etc. However, we have simplified its abstraction, … we know that all cars have a steering wheel through which we control direction, they have a pedal that when we press it we accelerate the car and control speed, … These features constitute the public interface of the car abstraction” (Edwin Dalorzo). This is a great example because we can use abstraction to simplify unnecessary parts that the users would not need to understand. This concept is similar to modularity. In his book Code Complete, Steve McConnell said on complexity “ the interface should reveal as little possible about its inner workings”. So now that we understand the two concepts, the idea of encapsulation starts to unravel.

One of the things that we want to always encapsulate in Java is the state of a class. This should only be accessed through its public interface. Edwin says on encapsulation in Java, “In a object-oriented programming language like Java, we achieve encapsulation by hiding details using the accessibility modifiers … With these levels of accessibility we control the level of encapsulation, the less restrictive the level, the more expensive change is when it happens and the more coupled the class is with other dependent classes (i.e. user classes, subclasses, etc.).” (Edwin Dalorzo).  It is crucial that we keep this idea in mind while we design encapsulation for these public interfaces so that we can foster evolution of our APIs.

As talked about in the article, it is often wondered why we need to use accessor and mutator methods in Java, aka getters and setters. With encapsulation in mind, it is not there to hide the data itself but the implementation details on how the data is being manipulated. So once again we would need a public interface to gain access to this data. However, by exposing this data we risk losing encapsulation. So this is why we would need to encapsulate this information.

https://dzone.com/articles/why-encapsulation-matters

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

In this final week of blogging for CS-343, I wanted to look over the General Responsibility Assignment Software Principles, or GRASP.

I took to learning about GRASP from Code Specialist at https://code-specialist.com/code-principles/grasp/, which discussed all nine GRASP principles and provided diagrams and code examples.

I’ve learned that the nine principles are: controller, creator, indirection, information expert, low coupling, high cohesion, polymorphism, protected variations, and pure fabrication.

Controller: helps “control” (not implement) events indirectly related to the user interface. It acts as a mediator between signals from the user interface and the backend.

Creator: a class responsible for the creation of certain objects, such as object A. This principle has a few rules for the creator, which are: creator B aggregates instances of A, B contains A objects, B records instances of A objects, B closely uses A objects, and B has the inputs for when A is created.

Indirection: is an idea that works with other concepts, like low coupling. It serves to avoid direct coupling. For example, the controller is an indirection between the UI and backend.

Information expert: a class containing the information needed to decide where an operation should occur. The operation should occur where most of the input needed for it is stored.

Low coupling: the idea of little interdependency between modules. By having few dependencies between modules, it would be less complicated to make changes to the code.

High Cohesion: describes the flow inside modules, not between them. High cohesion mainly helps to reduce complexity. Classes should be made to only fit their purposes and not go beyond that scope. We should not have large classes that do not really relate and are hard to work with.

Polymorphism: there are many variations of the same method and they work differently in different classes.

Protected variations: wrap unstable code with a stable environment. The unstable code can be wrapped with an interface that creates multiple implementations of that code.

Pure fabrication: creating a class that does not represent a real-world problem, but serves to support low coupling and high cohesion.

I thought this was a nice source to learn from because the page has neat orientation and provides diagrams and some sample code. Many of these principles seem interconnected with other principles to help reduce the complexity of code. High cohesion reminded me of the SOLID design principle single-responsibility principle in which classes have one responsibility and should not cover more than that responsibility. It would make the classes easier to understand, and less changes would need to be made to the class if it covers less functions. All of these principles I have learned will help me write neater code in the future as I keep in mind the need to reduce interdependence and complexity.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.