Category Archives: CS-343

Why Encapsulation Matters

Summary:

In this article, they don’t show us examples of encapsulation but instead explain to us the importance of it and why we do it as software engineers. Initially, they start off with how encapsulation helps us hide the complexity of our code. The beauty of hiding our code is not having to understand all the details in order to be able to use it, we just need to understand a broader abstract concept and how it works and how we interact with it. They also explain to us what happens when are not able to achieve the proper levels of encapsulation in our design. That article continues as to why we need accessor and mutator methods in Java.

Reason:

The reason why I chose this article was because in class we have done a lot coding in regards to encapsulation and I thought that this would help me fully grasp the purpose and meaning of encapsulation. Encapsulation is the very essence of API’s and how they work and being able to understand this is very important since we may be creating API’s in the future.

What I’ve Learned:

Encapsulation is more than just defining accessor and mutator methods for a class. It is a broader concept of programming, not necessarily object-oriented programming, that consists in minimizing the interdependence between modules and it’s typically implemented through information hiding. Our software designs the visible parts of our modules/classes constitute their public interface, and this is exposed to the outside world, the rest of it should be hidden to the naked eye. With encapsulation us as humans deal with complexity by defining abstractions with public interfaces so that we are able to interact with them and all of the code that lies beneath it is unnecessary in order for use it. It is like an iceberg, only a small portion of it is visible on the surface, but most of its true size is hidden underwater where we cannot see it. Changes can we made in directional systems because internal implementation is encapsulated and because of that, changes can we safely done without affecting it’ public interface. By minimizing the impact of changes and independence of modules, we can achieve proper levels of encapsulation in our software that can handle change without breaking its users. Information hiding is important because it decouples modules that compromise a system and it allows for them to be tested, optimized, used, understood, and modified in isolation. This allows for other modules to be developed in parallel and eases the burden of maintenance without the fear of affecting other modules. Encapsulation is a desirable attribute that allows for the evolution of APIs and as long as we respect public interfaces of our abstractions, we are free to change whatever has been encapsulated. Failing to define proper abstraction with proper levels of encapsulation will end up causing difficulties when change happens. There is no way to change the public interface of an abstraction without breaking its users. Encapsulation is one of the tools we use that help us create good abstractions, but no level of encapsulation is going to make bad abstraction work.

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

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

CS-343 Post #1

After the past few activities in class I was trying to think of what I wanted to look for to do my first blog post on. The one topic that caught my attention and I wanted to look more into was Design Patterns from activity 4. The strategy design pattern that we used in model 8 to improve the DuckSimulator seemed very effective to me, and I wanted to look more into design patterns after reading a bit about them in models 8 and 9. I found a blog post that goes over the strategy design pattern and when reading it, it went more in depth with the pattern than I thought it would based on the title of the post, “Keeping it Simple with the Strategy Design Pattern”, from Bits and Pieces.

The post briefly goes over Object Oriented Programming, then it focuses on the different aspects of the strategy design pattern. The parts of the pattern that the post goes over are its basic idea, structure, examples, authentication strategy, the problems it solves, SOLID principles, how it’s used in JavaScript, and when to use it.

Some of the material was familiar to me from previous courses that I didn’t think would show up, but it made sense that it did, such as the sorting algorithms, such as bubble sort and linear search, being used for the strategies being represented based on the data and objects in the program. Diagrams used for the pattern also were very similar to the ones used in the activity to show the structure of the pattern with the implementation of context, interface, strategy, and concrete strategy.

What was less familiar to me where the authentication schemes and strategies, such as basic and digest, that are brought up later on in the post. I did not know the specific schemes brought up, but I got the idea behind their usage for authenticating data in the program. The schemes were also used in examples for the strategy design pattern by showing an interface being used to have an authentication method that is implemented by the schemes.

The main problem resolved by the pattern is the hardcoding of the program, which can make in run less smooth and more complex/complicated than it needs to be. Using a pattern prevents this by breaking down the program into different tasks and classes that keeps the algorithms more understandable and usable. This is reflected in another example with a given Printer class with multiple classes, but is also shown in the final DuckSimulator version.

In conclusion, the strategy design pattern is effective at improving complex programs, keeping the classes manageable, and keeping the methods and algorithms separated from each other.

Link: https://blog.bitsrc.io/keep-it-simple-with-the-strategy-design-pattern-c36a14c985e9

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

          YAGNI

YAGNI has two different meanings: You Ain’t Gonna Need It or in other words, You Aren’t Gonna Need It. YAGNI has appeared differently as the main principle that has been used in the extreme program. This principle stated in a different interpretation is:

“Always implement things when you really need them, never when you just anticipate that you might need them.”

The reasons why this principle exists are various. As a start, it makes it possible to maximize the amount of unnecessary work that remains unfinished. This is a very good way to improve the productivity of the developer, but also the simplicity of the product. One thing to keep in mind, these features are very expensive, both for development and maintenance. It is also important for users, so that they have the opportunity to learn, but also to navigate around. But those features seemingly are not necessary, in fact, they are a very large source of waste.

 Yagni Advantages

Here are some reasons why YAGNI should be used:

-Save time in the same amount of money (saving time and money is equal), and this is the main factor but also the most important

-gives you the opportunity to use a much easier code, good but most importantly “thoughtless”

-makes available the deadlines

-ensures that the client is happy with the very frequent but also obvious changes that are in line with the specifications

-code has better quality, notice this from the fact that many developers focus on just one even smaller task they may be doing (tasks which are more important at the moment)

last but not least, that code has the property to be more extensible.

Yagni design principle

We will not need this program much. Extreme Programming (XP) says that a programmer should not add the functionality he has until it is considered necessary. So YAGNI translates differently – You will not need it. Extreme software is generally used in the Agile software development process. According to this principle, we should not add any functionality until the moment when it is deemed necessary, in other words, to write the code which we need in the current situation.

YAGNI in Agile/XP

Many people may remember that this principle is called “stupid” and that the requirements it has should be prepared even better. But those people who work in the slightly more advanced methodology or, as they say, “agile” should take into account the possible changes that the client’s requirements may have. For this reason, the subsequent tasks in most cases depend on the results of the current status of this project, but that over time this result may change.

If at the same time we develop many features that “maybe needed” as a start, we lose not only the time but also the effort that has been needed to complete it. There are also cases when we waste the time we spend refactoring or fixing them as these interventions may be redundant.

In general, developers should never rely on different assumptions because they are likely to prove that they are not worthy and capable of the effort and time a programmer needs.

Refereces:

https://www.plutora.com/blog/you-aint-gonna-need-it-yagni

https://jasonmccreary.me/articles/practicing-yagni/

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

Improve Your Code with Design Patterns

This week, I wanted to learn more about the design patterns we discussed in class. After completing the homework, I saw how each of the design patterns we had used could be stacked on top of each other to make more efficient programs and find solutions to common programming problems. So naturally, I decided to seek out a comprehensive list of the Gang of Four design patterns to learn more about them. While looking into this, I found a blog post by Madhura Oak entitled Design Patterns – Revisiting Gang of Four that seemed to fit the bill.

In this post, Oak explains how the “Gang of Four” came up with a list of design patterns that solve common issues within programming, and laid out these patterns so they could be used in any language, and could help software designers write maintainable and easily readable code. In this, he explains the SOLID principles by Robert Martin, and uses these 5 design principles to help explain the usefulness of each pattern. The author also breaks down the 23 Gang of Four design patterns into categories depending on how they are used and gives examples of their use, which helps put into context why we would use these patterns in the first place.

After reading about all 23 of the design patterns, and having used both the singleton and factory patterns in the homework, I feel like I have a far deeper understanding of how these patterns can be used to create more efficient and readable code. They provide a framework for so many different types of abstraction, showing ways to structure your class hierarchies to improve your ability to modify, extend, and test code without having to slog through massive classes that are full of specific use-case scenarios. Using encapsulation and inheritance in the way they are used in these design patterns, code can become so much easier to document, test, and build upon. It becomes so much cleaner and more readable.

So far in class, we have only looked at what Oak classified as “creational” design patterns, as they mainly have to do with the creation and encapsulation of objects. However both “behavioral” and “structural” design patterns are also listed here, to help bring the same principles to the structure and behavior of the programs. Mixing these together within the full structure of a project would provide great benefit to the maintainability of code in the future, one of the most important parts of software design.

Overall, this blog post was a good introduction to design patterns and the principles that they help to achieve. In the future, I hope to use these patterns to help design code that is far more abstracted, and hopefully far easier to follow than code I’ve written in the past. I really like how easily followed the patterns are, and the way the post is organized makes it easy to find what you are looking for. If you are interested in further reading about more design patterns, I would highly recommend looking through this post, at least for a general outline of what they do and how they work.

Source:

https://madhuraoakblog.wordpress.com/2017/03/01/design-patterns-revisiting-gang-of-four/

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

Self-Directed Professional Development Post #4

For this week’s blog post, I’ve decided to watch a video titled, “Object Oriented Design Tutorial: Creating a UML Design from Scratch” by Derek Banas. The reason I picked this video is because 1. it directly relates to one of our course topics, “Modeling: Unified Modeling Language (UML)” and 2. because it teaches a methodical process to creating UML diagrams. This video is actually part of a series titled, “Object Oriented Design” and in the next video Derek shows how to create code from the UML design he’s created. Since I will likely be making more UML diagrams in my educational/professional life, I figured it would be good to further develop this skill.

One of the first things Derek mentions in this video is that he will be showing both the analysis and design stages for this process. The program that Derek is tasked to create for this video is a coin flipping program for two individuals. One player selects heads or tails, the other player gets assigned the other coin side, and the winner and loser is selected. Derek starts this process with something called a Use Case Description. For this description, Derek has a basic text editor open with the following categories: description, triggers, actors, preconditions, goals, not available, and steps of execution. Derek goes through each of these categories and writes in the relevant information for the program he needs to create:

  1. The description describes what happens in the program.
  2. Triggers mention how the program/game starts.
  3. Actors include the two players, the coin, and coin game.  
  4. Preconditions lists the things that need to be true for this program to run (i.e. 2 players are available, a coin is available).
  5. Goals list the outcome of the program (i.e. one player wins and the other loses).
  6. Not available references potential invalid inputs and extensions on how to make the program better in the future.
  7. Steps of execution describes what the program will do in a numbered list (each number represents a specific task).

Although this was only one part of the 30 minute tutorial, this was still an extremely useful process for me to observe Derek do. I learned how important it is to critically think about what you want your program to do before you jump into programming. I am definitely guilty of trying to jump into coding sometimes but I can see how cleaner and clearer code can be written by thinking and mapping things out in advance.

The thing I’m happiest about from this blog entry is finding this series and Derek’s YouTube channel. He has multiple tutorials on his channel that I can see myself learning a lot from. His videos are educational and thorough (many of them are 20-30 minutes long). As I continue growing as a programmer, I will definitely be referencing him to learn more useful information, techniques, and procedures.

Tutorial link: https://www.youtube.com/watch?v=fJW65Wo7IHI&list=PLGLfVvz_LVvS5P7khyR4xDp7T9lCk9PgE&index=3

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

UML Diagrams

Why do we need to know UML Diagrams?

UML diagrams can be used as a way to visualize a project before it takes place or as documentation for a project afterward. Seeing what you are doing and being able to measure where you are at in your project can help simplify the workloads and decrease the amount of stress that you may have. But the overall goal of UML diagrams is to allow teams to visualize how a project is or will be working.  

We have heard people say this word a lot: a picture is worth a thousand words. That’s why visualizing a process, especially during the development phase, is crucial for team communication and collaboration. The software development industry in the past has used dozens of ways to model and visualize development. 

We probably might ask what is exactly a UML? UML stands for Unified Modeling Language. It is a modeling language that is most often used for software engineering but has extended its use to business processes and other project workflows. Essentially, UML is visualizing software through diagrams. 

 Three software engineers at the company Rational Software for their projects have created this modeling language, and since it has become the standard with very few changes over the years. 

Software engineering and other business processes use UML diagrams to modeling their work which is a big part of today’s world.  

There are two main ways UML diagrams can be used:

  • Forward design. The modeling and design are all done before coding the software application. Usually, forward design is used to help developers better see the system they are trying to create. 
  • Backward design. The modeling is done after the code has been written, and the UML diagrams act as documentation for the workflow of the project. This can help developers see the project development as it was, in reality, to improve in the future.

Whether UML diagrams are used before or after the coding or project, they provide a way to visualize many aspects of a project and who is responsible for what activity.

I found that UML diagrams, help me to improve my coding skills. Being able to look at every aspect of my project design not only makes it easy but, also faster, especially when it comes to Object Oriented Programming. UML diagrams can be used as a way to visualize a project before it takes place or as documentation for a project afterward. 

From the blog CS@Worcester – Site Title by proctech21 and used with permission of the author. All other rights reserved by the author.

JavaScript and JavaScript Frameworks

Source: https://trio.dev/blog/javascript-framework

I chose to write about JavaScript frameworks this week, because they are so common in development today. And we will be covering Vue.js in this course. JavaScript is the most popular programming language. And it has been that way for many years. Web browsers can compile JavaScript natively so a user does not need to download a seperate piece of software to view the website. Because JavaScript is so ubiquitous, and building websites can be very time consuming, developers started to create JavaScript libraries and frameworks to make the process easier. Frameworks are so prevalent that using JavaScript without a framework is commonly referred to as “Vanilla” JavaScript.

I spend time every week looking at Software Engineer roles on linkedIn, and most companies want candidates to know JavaScript. Many companies mention React, Angular, or Vue. Some posts simply say JavaScript. But I suspect that some of these companies also use a JS framework, but the person that wrote the posting may not know the nuances of Software Development.

A JavaScipt framework contains pre-written JavaScipt code that is commonly used across many web applications. Some examples are creating a header, or accessing an API with HTTP methods and Axios. The terms JavaScript library and framework are at times used interchangeably. But there are some differences. A JavaScript library uses specific functions from parent code. But a framework defines the structure of an application using already written, reusable code. JavaScript frameworks have become popular because they save teams time, which saves money.

The JavaScript framwork I am most familiar with is Vue.js. I used Vue to create a dynamic web page for my internship. I am not very experienced with front end web development, and mostly worked independently. So this was quite challenging. But using a framework made things easier. with Vue I displayed JavaScript Objects or JSON data with V-for and V-if statements. Anybody that knows how to use for loops and conditionals could figure these out. But what is different about V-for is that I could conditionally render HTML elements. A good example would be if an array’s length is not zero, display the array. And with V-for you can dynamically diplay elements, from an array or an object in Key value pairs, just keys, or just values. Vue allowed me to display an HTTP in response in JSON format using V-if and V-for loops. This would not be possible using just HTML and CSS.

Companies are trying to find ways to create software and web applications faster. And JavaScript frameworks can help them achieve this. Personally, I am looking forward to learning more about JavaScript frameworks in the next two semetsers, and in my career.

From the blog CS@Worcester – Jim Spisto by jspisto and used with permission of the author. All other rights reserved by the author.

REST API, you keep hearing about it, but what is it?

Throughout my time in college, I like many others have heard plenty of different terms related to computer science. REST API was one of those terms. Now I was familiar with what an API was, but I did not know what the distinction is between that and REST. With a little research I was able to find out that the difference is that REST APIs are just normal APIs that follow the REST architectural style. REST stands for representational state transfer, which was developed by Dr. Roy Fielding in 2000 and provides six API design principals that should developers choose to follow would give them a relatively high level of freedom and flexibility. These six design principals are:

  • Uniform Interface:
    • This design principle ensures that all requests for the same resources need to look the same in order to ensure that data can only belong to one URI or Uniform Recourse Identifier
  • Client-Server decoupling
    • This design principal exists to ensure that the client apps and server apps remain independent of each other
  • Statelessness
    • Statelessness allows REST APIs to disregard the need to requests to be processed through an independent server session, and instead ensures that all requests contain all the information needed to process it
  • Cache-ability:
    • Cache-ability ensures that resources can be cached either on the client or server side. This is intended to help improve performance on the client side, while simultaneously improving scalability on the server side
  • Layered system architecture
    • The design of a REST API should make sure that the requests to the API go through multiple layers, in order to prevent the client and server from knowing whether they are communicating directly with an intermediary or the end application
  • Code on Demand
    • This is an optional step, and if the developer elects to include it it should allow the API to send back executable code in its responses, as opposed to the static responses that it usually send

Now all this may seem like a bunch of rules that need to be followed and it may not immediately be obvious as to the benefits that REST gives developers. I recommend you watch this video which goes into detail on what a REST API is and its benefits https: //www.youtube.com/watch?v=lsMQRaeKNDk; but in summary the main benefits are that it it simple to use and standardize, scalable, and they tend to be high performance. REST allows developers to not need to worry about the state of the data and how the requests need to be formatted for different situations. It eliminates some headaches that come with working with other non standardized APIs, allowing them to simply focus on getting the necessary information from the API and applying it to their application. I would also recommend you read this short article from IBM which includes the information found in this blog post, as well as more detail about the best practices with REST APIs as well as their use cases https://www.ibm.com/cloud/learn/rest-apis.

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

Interface

Abstraction is the most essential piece of object-oriented design. It allows the client peace of mind when it comes to the implementation details of functionality. In Java, abstraction is achieved through abstract classes and interfaces. This post will find the idea of the Interface Segregation Principle.

An Interface is a set of abstractions that an implementing class must follow. We define the behavior but don’t implement it:
in the example below, we will find how that is being written.
interface Car {
void break();
}
Using the interface as a template that actually can help us to implement the behavior:
class Toyota implements Car {
public void break(){
// Toyota-specific implementation
}
}
What Is the Interface Segregation Principle?
The Interface Segregation Principle (ISP) states that a client should not be exposed to methods it doesn’t need. Declaring methods in an interface that the client doesn’t need is problematic for several reasons.
Let’s look at an example to understand why the Interface Segregation Principle is helpful.
By creating these codes below you will be able to analyze how the methods are being called. Let’s formed an order service place where a customer can order an oil change, change tires, or basic tuneup:

interface OrderService {
void oilchange(int quantity);
void tirerotation(string front, string back);
void basictuneup(int quantity, string front, string back);
}

Since a customer has the opportunity to order an oil change, or tire rotation, or both, it will make sense to put all order methods in a single interface which be seen in the codes below.

class OilchangeOrderService implements OrderService {
@Override
public void oil-change(int quantity) {
System.out.println(“Received order of “+quantity+” oil change”);
}

@Override
public void ordertireroation(string front, string back) {
throw new UnsupportedOperationException(“No tirerotation in oil change only order”);
}

@Override
public void ordertuneup(int quantity, string tireration) {
throw new UnsupportedOperationException(“No tirerotation in oilchange only order”);
}
}
Similarly, for a tirerotation-only order, we’d also need to throw an exception in orderOilchange() method.
And this is not the only downside of this design. The OilchangeOrderService and TirerotationOrderService classes will also have unwanted side effects whenever we make changes to our abstraction.

This change will also affect oilchangeOrderService even though it’s not implementing this method!
By violating the ISP, we face the following problems in our code:
• Client developers are confused by the methods they don’t need.
• Maintenance becomes harder because of side effects: a change in an interface forces us to change classes that don’t implement the interface.

From the blog CS@Worcester – Site Title by proctech21 and used with permission of the author. All other rights reserved by the author.

Technical Debt

This weekend, I decided to research technical debt. I wanted to look further into this topic because one of my classes had activity introducing the term. I came across a wonderful blog discussing the different types of technical debt and how to manage them.

The blog: https://www.bmc.com/blogs/technical-debt-explained-the-complete-guide-to-understanding-and-dealing-with-technical-debt/#ref4

The blog lists four types of technical debt: planned technical debt, unintentional technical debt, unavoidable technical debt, and software entropy.

Planned technical debt: when a team has to compromise on the code but knows the risks and damages collecting the debt will have. An example is a team not spending time coding smaller aspects of a project in order to meet a deadline. The blog advises to keep a detailed record of the compromises to help the team keep track of what to address in the future.

Unintentional technical debt: arises from struggles with new coding techniques and problems from rollouts. An example of unintentional technical debt occurring is a design having many errors due to miscommunication between different teams working on a project.

Unavoidable technical debt: arises from changes in technology and business. A business may suddenly change its views on what features a project should have, and new technology may come out that can perform the functions more smoothly. This would make old code defunct.

Software entropy: occurs as software quality degrades. This can be caused by the changes developers (who do not fully understand the purpose of some code) make that yield more complex code. Overtime, the software will be riddled with errors and will be difficult to use.

The blog discusses three ways to manage technical debt, which are: assessing debt, communicating debt, and paying off debt.

Assessing debt: technical debt can be measured by how many days it would take developers to refactor or make changes to the target project, and the monetary value of that time can be calculated. This data could then be compared to upcoming significant events to help with cost analysis.

Communicating debt: it is important to properly convey the existence and impacts of technical debt to stakeholders so that fixes can be accounted for later.

Paying off debt: there are three ways to pay off technical debt: waive the requirement, refactor the application, or replace the application. Waiving the requirement would not set the team back in creating new features. Refactoring would help improve the structure of the code without changing program behavior. Replacing the application would result in new technical debt, but it should be limited and dealt with quickly.

This blog post taught me about technical debt in more depth, with the different types and different management aspects. I was curious on how technical debt could be calculated, but I’ve learned it can be measured by time spent to make the changes. Going forward, this information can help me understand what technical debt a project has and how to help deal with it. The graphics and the video the blog attached discussing debt was pleasant to view.

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.