Category Archives: CS-343

Keeping It SOLID

SOLID is a popular set of design principles that are often used in object-oriented software development. The acronym stands for five key design principles which are: single responsibility principle, open-closed principle, Liskov substitution principle, interface segregation principle, and dependency inversion principle. Together these principles are intended to reduce dependencies along with making designs easier to understand, maintain, extend, and avoid issues to build an adaptive, effective, and agile software. 

The single responsibility principle is a basic principle that many of us developers are already using daily in our own coding. The idea behind this principle is that every class, module, or function in the program should only have one responsibility or purpose in the program. A commonly used definition to describe this principle is that “every class should have only one reason to change.” Implementing this principle is sure to make your code easier to test, maintain, implement, and can help avoid unanticipated side effects of future changes. 

The Open-Closed Principle in summary, is that you should be able to extend a class’s behavior without modifying it. By following this principle can make our code writing easier to maintain and also revise in the future. Our classes would compile with this principle if it is open for extension and closed for modification. Open for extension means that the class’s behavior can be extended. While on the other hand, closed for modification means that the code is set and cannot be changed. This implies that such entities, like classes, functions, objects and so on, should be created in a way that their core functionalities can be extended to other entities without altering the initial entity’s source code.

The Liskov Substitution Principle is one of the most difficult to understand out of the five SOLID principles. This principle simply requires that every derived class should be substitutable for its parent class. The Liskov substitution principle implies that when an instance of a class is passed/extended to another class, the inheriting class should have a use case for all the properties and behavior of the inherited class. So, if we were to extend a class, if some of the properties of the initial class are not useful for the new class, then the principle will be violated. We can easily fix this though by creating an interface that matches the needs of the inheriting class. Following this principle helps to avoid unexpected consequences of changes and avoids having to open a closed class in order to make changes. It leads to easy extensions of software, and, while it might slow down the development process, following this principle during development can avoid lots of issues during updates and extensions.

The Interface Segregation Principle states that it’s better to have a lot of smaller interfaces than a few bigger ones. This means that you don’t want to just start with an existing interface and add new methods. Instead, start by building a new interface and then let your class implement multiple interfaces as needed. This principle makes us understand that it is unnecessary and unreasonable to create an interface with a lot of methods as some of these methods may be irrelevant to the needs of a particular user when extended. 

The Dependency Inversion Principle, simply put, is that developers should depend more on abstractions, not on concretions. For example we should make our classes rely on properties in our interfaces instead of relying on each other. The implications of violating this principle would result in a rigid system where testing blocks of code independently would be very difficult, reusability of code would be near impossible, and the addition or removal of code would lead to further complexity of the system and introduce bugs. High level modules should not depend upon low level modules. Both should depend on abstractions. Furthermore, abstractions should not depend on details. Details should depend upon abstractions. 

Overall, the goal of the SOLID principles is to reduce dependencies so that we can change one software without impacting others. With the  SOLID principles we can  make our code more maintainable, extensible, and flexible. These principles provide a set of guidelines for object-oriented programming and design, with the aim of making code easier to understand, debug, and modify. By following the SOLID principles, developers can write code that is more cohesive and less prone to errors, and that can be easily adapted to changing requirements or new features. Ultimately, the goal of the SOLID principles is to help developers create software that is of high quality, and that is easy to maintain and evolve over time. 

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

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

The Law of Least Knowledge

The Principle of Least Knowledge can go by many different names but the most common name today is the Law of Demeter. The Law of Demeter for Functions/Methods (LoD-F) is a design principle which is used for designing a system with minimal dependencies. It is typically summarized as “Only talk to your immediate friends.” This principle/law is more of a guideline than anything else. Some of its guidelines may include, each unit only having a limited knowledge about other units or objects and they should only be units or objects that are closely related to the current unit, each unit should communicate with its friends while not “talking to strangers”, and should only communicate with immediate friends.  

The main idea behind this principle is that inside of our applications, the code that we write should only express knowledge of its surroundings. The guidelines of LoD promote a notion of Loose Coupling in our codebase, which can lead to cleaner code with more maintainability. 

If we had a class that would implement a method, then the method should only be able to call a few objects. These include:

  1. The object that owns the method.
  2. Objects passed as arguments to the method.
  3. Objects that are dependencies of the owner instance, which are held in instance variables.
  4. Any object which is created locally in the method.
  5. Global objects that can be accessed by the owner instance within the method. 

On the other hand, if an object was to know too much about another, then this could be considered a bad design as the object would then have to traverse from top to bottom of the chain to get actual dependencies it needs to work with. 

Overall, The Law of Demeter gives us a guideline on how to achieve loose coupling in our code and helps to properly encapsulate the knowledge of some complicated operations or logic into the places where they should be. By keeping this law in mind when producing our own codes and programs, it is sure to help us have cleaner code with increased maintainability and can help benefit the code we are producing when running it.

Principle of Least Knowledge

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

Backend developement

Backend development is an essential part of creating a dynamic, interactive website or application. The backend, also known as the server-side, is the part of the website or application that manages the data and logic behind the scenes. It works in conjunction with the frontend, or the client-side, which is what users see and interact with.

There are several components that make up a backend, including a server, an application, a database, and an API. The server is the physical location where the website or application is stored and accessed. The server is responsible for hosting the website or application and delivering it to users when they access it. The application is the actual software that runs on the server and provides the functionality of the website or application. It is typically built using a programming language, such as Java or Python. The database is where the data for the website or application is stored. The database is used by the application to store and retrieve data, such as user accounts, information about products or services, and other data needed by the website or application. The API, or application programming interface, is a set of protocols and tools that allow different software applications to communicate with each other. In the context of backend development, the API is what allows the frontend and the backend to communicate and exchange data. For example, when a user interacts with the frontend of a website or application, the API allows the frontend to send requests to the backend and receive responses with the relevant data.

I selected this post because I am interested in learning more about backend development and how it plays a role in creating interactive websites and applications. Furthermore, a lot of work for this class went into writing code for and experimenting with, the backend code for Thea’s Food Pantry. Working on something actively in use, even without making any changes, was a very interesting experience and will be immensely useful for the capstone class next semester. Understanding the importance of the backend and how it works with the frontend will allow me to better plan and implement the overall architecture of a website or application. Additionally, learning about the various backend components and their functions will allow me to make informed decisions when choosing technologies and frameworks to use in my projects.

 

Source:

https://www.codecademy.com/article/back-end-architecture

 

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

Anti-patterns!

We’ve talked about design patterns, but what about anti-patterns? What even are anti-patterns? Well, anti-patterns are the exact opposite of design patterns! If design patterns are things that we want to do and stay conscious of when we code, anti-patterns are the things we do NOT want to do! These are the little devils on our shoulders, tempting us to produce code that will not be easy to update and maintain! These are the whispers in our ears telling us to take the shortcut, or quickly jam it out! These are anti-patterns!

For some people, it is important to know what things we should do, such as in design patterns, but for others, it is also just as important to know what not to do! In my case, I am one of those people! I learn often from trial and error, so spotting anti-patterns, I realized that, hey! Maybe I don’t have to keep trying different things over and over again. I started looking into a few different anti-patterns, and to my full expectation… Yep! I should’ve looked into these earlier! A few anti-patterns were things that I only learned after the fact, after lots of error, trial, and honestly, guesswork!

From this website , here are some notable anti-patterns that I have found! Some of them are definitely more ‘fun’ than others, and I’m sure you’ve even heard of them, but others are a bit less known, but just as important!

Golden Hammer
The Golden Hammer for example is something that I find really important! It is really tempting to find a solution for one problem and try to apply it to another, but that is a trap! Although a solution might work in one or two instances, to try and use that same solution for all problems is a big no, no! Each problem should be addressed on a case by case basis, and to think that there is a one sized fits all solution is not good! I’ve definitely fallen into this trap before, and eventually had to go back and rework my code, so just don’t do it all together! Spend a bit of extra time to think about the problem at hand, and resolve it accordingly!

Spaghetti Code
Spaghetti code is another anti-pattern that is crucial to know about! Though, it is also pretty well known! Spaghetti code is essentially when code becomes so coupled with each other and connected, that it is practically impossible to unravel. It usually starts small, but over time, it builds up and up and up, until it is a complete mess that even the original creator doesn’t know what is going on! It is crucial to realize that spaghetti code is something that happens over time, so try to keep focus and try not to take the quick and easy way out! It’ll only make things worse for the future!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Week 12- Design Smells

View at Medium.com

The blog I reviewed this week delves deeper on the topic of design smells and the classifications of some of them in different situations, some of which we had discussed in previous classes and some new ones that prove to be important to know in the long run. this article focus on design smells in the UI/UX side of programming and more specific to this side but still very much important.

The first discussed is “Documentation for Power users” which is the separate documentation used on portals to different sights when users click hyperlinks, or the different section on a Website or application. the issue comes from the formating and the flow of said website many look very cluttered and the flow of information is jumbled up. One specific example that is used for this smell is the Use of Microsoft Excel, the main focus being that it is a universally used application and thus has universal tools that the users disposal, the issue with such a great tool as without distinct tools being separated from the ones a user might not use in order to optimize the users experience it overwhelms them. this goes for all users as there is no case by case optimization, one solution brought up would be to dissect the application into separate products in order to better organize the UI for consumers in different situations, such as one made for educational use and one for corporate.

Another Smell that is discussed and closely relates to the previous is “Excessive Iconography”, this smell focuses on the use of unclear icons to display information in large loads, if we look at the example used in the blog of Xcode on Mac with many of the icons and labels out all on the same display to overwhelm the developer, making the tasks more difficult. the issue isn’t that the Labels or the Icons are not clear, but there are to many options and features present on the same screen. one way to combat this is to structure the application into smaller instances including all features that are connected together, allowing for clearer labeling and better overall experience for users. one personal example of this kind of structure I found was on Jira which structured its features according to what the user needed, allowing for a seemless UI and better experience. it did this but hiding features entirely that were not necessary and clearly labeling its tools.

Yodaiken, Aaron. “Ux Smells.” Medium, UX Collective, 7 Feb. 2017, https://medium.com/user-experience-design-1/ux-smells-fa971feef820.

From the blog cs@worcester – Marels Blog by mbeqo and used with permission of the author. All other rights reserved by the author.

All About The Principle of Least Knowledge

The Principle of Least knowledge also called the law of Demeter, as explained in Eric Feminella’s blog “Principle of Least Knowledge”, is a design principle that provides guidelines for designing a system with minimal dependencies.  It is summarized in short as “Only talk to your immediate friends.”

A client should have knowledge of an object’s member, and not have access to properties and methods of other objects via the members.

The example shown in the blog has three classes: ClassA, ClassB, and ClassC. ClassA has an instance member of type ClassB and ClassB has an instance member of type ClassC. This shows that all the classes are connected one by one, and this can be extended further ClassC if need be. Now believe it or not this example violates The Principle of Least Knowledge because it creates multiple dependencies, thus reducing the maintainability because if ClassA needs some work so would all the instances of ClassA. This creates like a domino effect and keeping up with the client could pose some trouble.

Now, like the blog explains, in software development there might be some trade-offs. If the program runs better optimally with the above method, then maintenance might need to be pushed aside for just that. But it’s an important goal for the software developer to minimize dependencies, and by following guidelines provided by The Principle of Least Knowledge this becomes much easier to accomplish.

The Principle of Least knowledge is very important when it comes to coding because when it comes to programming a client itself, it becomes very easy to callback other dependencies to make things easier. But this creates more classes that, in a before blog would be referred to as “master classes” and more redundant code is created, and other dependencies are brought into the mix.

In code it seems like it’s better off if some classes don’t know the inner working of their other class, I’ve seen many programs break entirely because of one class. These classes are dependent of other classes. When one class falls all the other classes fall with it. So, It’s important to implement these dependencies so that they can be changed easily. And it’s also remembered to implement in such a way that they don’t require these chains of dependencies involved. All in all, it’s best to create a program that easy to modify and refactor so that the code is easy to work with in future development.

Link to Blog: http://www.ericfeminella.com/blog/2008/02/02/principle-of-least-knowledge/

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Refactoring

Refactoring is an important concept in software development that refers to the process of modifying and improving the internal structure of existing code without changing its external behavior. This can be a useful technique for improving the readability, maintainability, and performance of a codebase, and it is often an essential part of the software development process.

There are many reasons why a developer might choose to refactor their code. One common reason is to improve the readability and understandability of the code. Over time, as a codebase grows and evolves, it can become difficult to understand and maintain. Refactoring can help to clean up the code and make it more organized and easier to read. Another reason to refactor code is to improve its maintainability. As a codebase grows and changes, it can become more difficult to make updates and modifications without introducing bugs or breaking existing functionality. Refactoring can help to make the code more modular and flexible, which can make it easier to make changes and updates without breaking the code. Refactoring can also be used to improve the performance of a codebase. As code is written and optimized, it can sometimes become inefficient or slow. Refactoring can help to identify and remove bottlenecks, and to optimize the code for better performance.

I chose this blog post on refactoring because it is a crucial concept in the field of computer science. As I read through the post, I found it to be very informative and well-written. The post clearly explained what refactoring is and described the various benefits it offers, such as improving readability, maintainability, and performance. I found the discussion of different techniques for refactoring code particularly interesting. Techniques like extracting methods or functions, renaming variables and functions, and restructuring code can all be effective ways to make code more modular, readable, and maintainable. I also appreciated the emphasis on maintaining the external behavior of the code during refactoring. This is something I will keep in mind as I continue to learn software development. Although refactoring wasn’t required in this class, I plan to use what I learned on future projects and when working with others on a team. I will refer to this resource as I continue to improve my skills and knowledge in the field.

Source:

https://maddevs.io/blog/code-refactoring/

 

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

Week 11-Software Architecture patterns

The Blog I read this week focusses on the the different Types of software architecture that we had discussed in previous classes as well as the different situations that these different patterns are useful and for what type of situation they would be ideal for. One of the important ones discussed and the most interesting ones that applies to my everyday life is the client server pattern.

In this pattern a central server offers one or more services are offered to one or more clients, allowing for all of the work to be done at the central server while all of the users can use the Data independently. This is very relevant for the world at large as many of the sites that we use on a day to day basis use this type of pattern such as twitter, where the Application provided the under interface for the user and the servers to interact. this type of pattern is used for many different applications we use today such as facebook and many other types of social media, where the user takes the information from the server and the selections made on the users side will then be sent to the server and update the information on that side of it. it is interesting how our small interaction impacts the overall system as a whole and how the entire process occurs for something so simple as updating your twitter bio.

Another pattern discussed in the blog is the layers pattern, which we discussed in both classes related to Cohesion as well as design patterns. it is described as the most widely used and promotes low coupling and high cohesion, much of what we discussed before hand in class is gone over such is how it is utilized for the most part smaller projects with different teams working on different parts of the project in parallel with other departments in order to keep the system active for users as well as allowing for updates to be spit out more often without shutting down the rest of the system. this was an important aspect of release principles as allowing for these releases to happen frequently in order to push updates to users as often as possible while other developments were also in progressed proved beneficial to the user but strained the developers, with the different teams it allows for less stress on devs to release patches or updates in select parts of the projects.

View at Medium.com

O, Williams. “Fundamental Software Architectural Patterns.” Medium, Medium, 14 June 2022, https://medium.com/@liams_o/fundamental-software-architectural-patterns-663440c5f9a5.

From the blog cs@worcester – Marels Blog by mbeqo and used with permission of the author. All other rights reserved by the author.

Restful APIs!

Since we’ve been doing a lot of work with REST APIs, I thought I would look into them more and see what kind of other uses for them there are! Some things that I was interested in, was to look and see if I could brainstorm any uses for them, and through a few different websites

Here, here, and here

I found that REST APIs can be used in a variety of different ways! Some of them are things that I wouldn’t think about, while others are more in line with what I expect.

For example, there’s more obvious situations where you can use REST APIs in Twitter’s case that allows people to read certain data. This allows people to do more extensive research with Twitter and create other interesting data points that such as in-depth analysis.

Then, there are other cases that might not be as obvious. REST APIs can also be used in cases like Spotify. I wouldn’t have thought about it in such a way, but pulling information such as song artist and shuffle systems can be developed with REST APIs as well. On first thought, I was curious to see how Spotify would use REST APIs, but it does make a lot of sense when you think about it.

To break it down in it’s basic form, Spotify uses a variety of different endpoints to return all kinds of different information. Some are more obvious, like artist, alum, and tracks, but there are also endpoints for markets and even playlist!

Honestly, I think it’s really clever to set it up that way, and it makes it very easy for third party developers to work on these types of systems. Since many websites use REST as a foundation, if you’re familiar with how REST APIs are set up in one form or another, you can probably quickly learn it in other situations as well. It is certainly much easier to get a hang of than if every single API was different from one another, but I think that goes without saying.

Overall, I think that if I wanted to use REST APIs for my own project, I’d have some difficulties. There’s not a lot of things that I have that can use REST API, so I’ll have to think of a whole new project to make. For basic start, I’d probably make something with a lot of different data or categories, since I think REST APIs are best at that!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

What are Anti-patterns?

Anti-patterns are on the opposite side of the design pattern and are undesirable according to the blog “Anti-Patterns in Software Development That You Should Avoid”. Another term to describe Anti-patterns are called Design Smells.

The blog goes over the concept of the Golden Hammer anti pattern which occurs when using a familiar solution to attack an unfamiliar problem. Sometime it might work out, but most of the time it’s an inefficient way to solve problems.

The Golden Hammer anti-pattern is a concept that can shared in every aspect of life. Like for example, as mentioned in the blog some people tend to have their solution ready before understanding the problem like a doctor prescribing while the patient is still telling about the symptoms.

In software development, each design pattern is basically suited for its targeted problem. But it’s really easy to use the same framework, the same programming language, and the same design pattern for almost every problem. Like similar to the doctors example, some doctors might prescribe Ibuprofen to help a certain health but it might not completely relieve or heal that issue completely.

And so the Golden hammer could lead to; Poorly performing code, Overly complicated code, Redundant code. To avoid this anti-pattern it is best to find all potential solutions for one problem and benchmark them. List down all PROS and CONS for each solution then choose the better one.

Another anti-pattern is the God Class which for the most part controls many other classes, takes many responsibilities as well as lots of dependencies. An application could be well designed at the beginning so that there aren’t God classes but eventually dominant, very well specified classes will turn into God classes at some point.

The big ball of mud is a very common anti-pattern that happens when the solutions/application lacks a perceivable, flexible, suitable architecture as defined in the blog. A ball of mud will have, haphazardly and sloppy structure without coding comments, contains many God classes with more than 6000 lines of code, static variables/functions everywhere, methods being overloaded several times, and code duplications.

This anti-pattern is dangerous because it could happen while writing the application. Once we can’t refactor the code anymore, then we have to rewrite the entire thing. There are many reason why this anti-pattern could be brought up. It could be due to the frequent changes and requirements that the application might need, the deadline is near and the project is rushed, new developer are being brought in, or being too narrow minded about the design architecture that was initially brought in.

There are many more anti-patterns when it comes to the software development process, these are just the most common ones to date.

Link to blog: https://medium.com/geekculture/anti-patterns-in-software-development-that-you-should-avoid-780841ce4f1d

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.