“Find what changes and encapsulate it.”-  This is a different approach from the redesign approach. In simpler words, we are able to consider what we want to change without redesigning, rather than thinking about who might force a change in design.

This principle of encapsulating makes it possible for nothing to affect the rest of your code.

Encapsulation can be found everywhere!

When we turn the steering wheel and the car wheels rotate, we see that there is a variety of moving parts that work together to transform our action into the final effect that the car wheels have, but all these details are encapsulated by us. But this example can never be confused with abstraction. Because they are simply similar and can be true. Just like in the real world but also in the world of Software we have various examples of encapsulation but also of Abstraction that interact together. These are two concepts that are different but that are also related to each other, and that in most cases work together.

The moment we include anything that has the potential for change, we are dealing with time savings. In general, encapsulation has to do with objects which in a way make possible the merging of attributes but also of the methods they have, for the sole reason that they do not have an impact on other objects they have. But it works differently in cases when we are dealing with the design of a program which is mostly object-oriented. This is because the requirements that may most likely change in the future, need to be more concise for one reason only: that the change is likely to occur at the time it is requested. The volume of the code is changed by the summary which minimizes the volume of the code, and which may need to be changed in the future.

When we see that this principle is particularly relevant to the code which changes very often, we are dealing with the benefit of encapsulating the code, regardless of the frequency of the code change. Like what:

The code that is encapsulated has the possibility of reasoning to be separate from the code

• To prevent conjugation summarized with the implementation of the code which is encapsulated, such as when summarizing when the interaction of a downstream system. At this point this replacement is even easier.
• -Other developers can understand from the encapsulation constants, that they are sufficiently connected and have control security in case they have changed or even the way it has changed.

References:

https://genderi.org/encapsulate-what-varies.html

https://alexkondov.com/encapsulate-what-varies/

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

Command-Line is essential to developers and I think every developer should master this skill. In my point of view, the command line is quicker than a regular click which saves developers much time along with effort, and the command line is one of the best tools at our disposal. Recently, I have had more opportunities to practice command-line while learning about Docker. It comes to my sense that using CLI fastens the Docker process than the original clicking method.
Knowing CLI gives you better accessibility to control the system. You can only access these kinds of commands via the shell on Unix/Linux and Power-shell on Windows. The basic commands only involve changing the directory, creating new files, and editing text files. The more advanced techniques could involve managing database systems like Apache/SQL. And elite users could use the command-line to do test penetrating to expose security vulnerabilities.
Developers spend an amount of time in Command Line Interface to execute codes or to run packages. Two essential programs are git and brew was designed exclusively for CLI though there is a way to use it without CLI interference, this is still much quicker and easier to use and work with the code base in it. CLI also allows us to do manipulations with your system internals. It offers better flexibility and control than regular GUI.
Front-end and back-end developers are better off with CLI. Since back-end developers will be dealing with servers, configuration files, and making sure the code for your site is working. Front-end developers don’t need as many CLI skill sets as back-end but knowing CLI serves them .better in the long run. After all, both developers use git and git functional based on CLI.
Talking about the bad stuff, CLI in Linux is popular among penetrating testers, meanwhile, hackers love CLI because of its flexibility. Using CLI to run Nmap to expose vulnerability is a powerful tool. It allows us to scan the network and discover not only everything that is connected to it but also much sensitive information. Besides Nmap is Metasploit, another powerful tool for penetrating testing. The problem with Metasploit is it makes hacking simple than it used to be. Nmap and Metasploit are two powerful for testers and developers and to people who use Linux, these are essentials, not necessarily for regular Linux users.
To summarize, the main advantage of using CLI is if you know the commands, CLI could be faster and efficient than other operations. It can handle repetitive tasks easily and CLI requires less memory than other interfaces.

From the blog CS@Worcester – Nin by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

Christian Shadis, 10/20/2021

In the blog post “Strategy Design Pattern in Python”, Giridhar Talla defines and discusses the Strategy Design Pattern first in a broader object-oriented approach, but then directly with Python implementation. Talla uses the Gang of Four’s definition of the Strategy Design Pattern to first create an abstract implementation of the design pattern, and then using a more concrete example to show the pattern in use. He also includes a UML diagram visualizing the design pattern.

The strategy design pattern was a topic of focus for my CS-343: Software Construction, Design, & Architecture class. We examined the pattern using a simple example in Java called DuckSimulator, which had different Quack and Fly strategies. While the value of the pattern was immediately evident, the concept of the pattern itself still confused me, especially when attempting to implement the design in Java for homework. I chose to study and write about this blog post because it took a straightforward approach like the in-class activity, but it is implemented in Python instead of Java. I decided that the best way to understand the abstract nature of the strategy design pattern was to consider its implementation in other object-oriented languages.

I found the blog post both informative and direct – Talla’s language is easy to follow, and his code snippets are clear and concise. What I found simultaneously helpful and confusing was his abstract implementation of the pattern using not a real-world example, but simply by creating Context and Strategy classes. This made it helpful to see exactly how each component interacts with one another without getting caught up in or confused trying to figure out what part of the example represents a strategy or a context. This abstract code chunk is a solid foundation for building a python script using the design pattern if you it to your specific real-world example.

The article did supplement my understanding of the design pattern by adding extra abstraction. On the other hand, however, I still find myself confused trying to implement the pattern in Java. Because of this, I plan to continue reading about the pattern and practicing implementing it. The code I write is often very dependent on using if/else branches to run algorithms differently based on object attributes, which is a problem this design pattern can mitigate. I plan to read the original Gang of Four chapter on the Strategy Design Pattern to further increase my understanding because being able to implement this pattern will greatly improve the efficiency of programs the pattern would work with.

Source: https://auth0.com/blog/strategy-design-pattern-in-python/

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Source: https://www.geeksforgeeks.org/mvc-design-pattern/

The Model View Controller pattern is a common design pattern used in web development. I chose to write about the MVC design pattern this week, because I have experience using it, but at the time I did not realize that I was using a design pattern. At that point I was not familiar with the idea of a design pattern, or the extent to which they are used in Software Develpment. My thought is that doing some intentional study of the topic will solidify my knowledge. My experience with MVC was in ASP.NET Core. But some other popular MVC frameworks are React, Angular, and Laravel.

With MVC the data model, application data, presentation information, and control information are seperate objects. The Model contains application data, and does not present the data to the user. In my experience these Classes contained data like barcodes and timestamps. But did not have methods that manipulate the data, define API methods, or a present a UI. The Controller Class is an intermediary between the Model classes and the View Class. The Controller Class contains methods that execute on Models. In my experience, I mostly used Controllers for API calls. These API methods uploaded text files to a database with an HTTP post method, and retrieved JSON data with a HTTP get method. The View Class prescents the data to the user. In my experience I used .Vue files to present data. The View files instanced of Models, presented as JSON objects, and the Controller contains API calls that allowed the transfer of data from the Model to the View.

Like all Design Patterns in Software Development there are advnatages and disadvantages to the Model View Controller pattern. Some Advantages are that multiple developers can work simultaneoulsy on the model, controller and views. Another Advantage is the MVC allows for logical grouping of data. And Models can have more than one View. Some disadvantages is the added layer of abstraction can make working on and navigating the service to be complex. I ended up tracing methods from class to class, using built in Visual Studio tools, because remembering where the method I was looking for became cumbersome. Using the MVC design pattern creates many files, because each layer of every feature of the service has a Model, Controller, and View. With all that being said, I still think that the MVC pattern is great for meduim to large scale services.

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

This week, I wanted to read up on code smells. Code smells are conditions of code that indicate problems with code quality.

A great resource I stumbled upon is “Everything you need to know about Code Smells” from Codegrip at https://www.codegrip.tech/productivity/everything-you-need-to-know-about-code-smells/.

Code smells may slow down processing and can make it easier for bugs to develop in the program. There are three levels of smells: application level, class level, and method level smells.

Codegrip lists duplicate code, shotgun surgery, and contrived complexity as application level smells. Duplicate code, of course, is similar code that appears in more than one location. Shotgun surgery is a change that results in the need to change other classes. Contrived complexity is using complex design patterns where a simpler design could be used.

Class level smells are: large class, freeloader, feature envy, divergent code, data clump, inappropriate intimacy, middle man, downcasting, parallel inheritance hierarchy, refused bequest, and cyclomatic complexity.

Large class smells are when a class has too many functions and it has too many instance variables, whereas freeloader is when a class does too little. Feature envy is when a class with a method wants to use features of other classes more than its own. Divergent code smell arises from a class that has to undergo many changes in order to make a change in a system. Inappropriate intimacy is when a class depends too much on the implementation information of other classes. Downcasting is when there’s a typecast that breaks the abstraction model. Parallel inheritance hierarchy smells are present when you make a subclass for a single class, and then a subclass must be made for other classes. Refused bequest is when a subclass does not use the methods and data of the superclass. Cyclomatic complexity smells occur when a class has an excessive amount of branches and loops.

Method level smells are: long method, speculative generality, message chains, too many parameters, oddball solutions, god line, excessive returner, and identifier size.

Speculative generality smells are present when only test cases are users of methods. Message chains are when methods call on other methods and those methods call on additional methods. Oddball solutions occur when multiple methods are used to solve the same problem. God line is when a line of code is unreasonably long. Excessive returner is when a method returns more data than what is actually needed. Identifier size occurs when the identifier is too short or too long.

I selected this source because I liked how it neatly categorized the different levels of code smells and offered an audio version of the post. In addition, I thought it was interesting to see how Codegrip explained code smells as it provides tools to recognize code smells and provides suggestions for how to resolve them. This source helped me learn the code smell types and how to recognize them. I’ll be able to apply this to my code in the future to prevent opportunities for big errors to develop down the line.

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.

For the longest time Java has been an Object Oriented programming language first and foremost however it was never purely Object Oriented in its design. There exists some objects which are immutable and cannot be changed under any circumstances. String is an example of this and works by having a new object instance created whenever changes need to be made rather than altering the object itself. This is a hallmark of Functional Programming and part of the greater trend of java being pushed to be more akin to Functional Programming languages such as C.

This is something that Ian Darwin reviewed in his Java Magazine article going over the changes Java has seen over time. In this article he asks the question “Why is Java making so many things immutable?”. Put simply the answer is a matter of security and performance with immutable objects being more resilient to attacks and better for performance. Darwin provides examples with the String object which has been immutable since the very beginning. Along with this the Date and time API  has been moved to an immutable package since Java 8.

In the early days of Java there existed Java beans which Darwin describes in the article by the original spec which states: “A Java Bean is a reusable software component tat can be manipulated visually in a builder tool”. What does this mean? It means that Java Beans are more or less Java objects with a set of requirements to be classified as such. There include having set and get methods, expecting to be serialized and implementing the Serializable Java package, and it must provide support for design-time customization. The main takeaway is that these were always mutable and ever since then Java has moved away from this as its language has overtaken servers and enterprises alike.

Why has Java attempted to move to a Functional Programming paradigm? In today’s world many businesses and enterprises utilize Java on a large scale and in general and any way to gain more security or performance in a programming language will do a lot for a language as ubiquitous as Java. The creators understood the need for security with the String class as it has been immutable from the start. We can see below an example thread by Ian Darwin that could take advantage of and break Java’s entire security model if Strings could be modified.

Good Thread: Open File xyz.
InputStream Constructor; call security manager.
Security manager – Read file xyz – Permission is OK.
Bad Thread wakes up at just this moment.
Changes file name string from ‘xyz’ to ‘/etc/passwd’
Yields the CPU
Good Thread
InputStream Constructor: pass /etc/passwd to operating system open syscall
Bad Thread examines memory buffer for useful information to steal

Beyond the security benefits that these immutable objects pose there is also a matter of being able to increase performance of Java. Java is constantly being improved and as it’s performance increases it has become apparent that it is faster to create new objects than it is to modify the properties of old ones. Java lacks the ability to use pointers like C and because of this any extra baggage that can be removed to free up resources helps in a language like Java. If you compare Java at release and Java today, you can see that a myriad of new immutable APIs are scattered across the language as it has grown and evolved. This will likely continue so long as Java is a dominant language in the programming field.

Bibliography

Darwin, Ian. “Why Is Java Making so Many Things Immutable?” Blogs.oracle.com, https://blogs.oracle.com/javamagazine/post/java-immutable-objects-strings-date-time-records.

https://blogs.oracle.com/javamagazine/post/java-immutable-objects-strings-date-time-records

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

During the early days of the web, front-end development was less complex focusing mostly on static documents, linking pages, and basic design. As time went on, more and more functionality has been given to the web browser making front-end development a major field. Front-end development is the client-side programming of a web appl

During the early days of the web, front-end development was less complex focusing mostly on static documents, linking pages, and basic design. As time went on, more and more functionality has been given to the web browser making front-end development a major field. Front-end development is the client-side programming of a web application. This type of development focuses on the design, functionality, and interaction of the webpage with the backend components. 

The structural components of front-end development takes place in HTML, which stands for HyperText Markup Language. HTML defines the layout of the webpage elements along with their content and properties. Each html element has its own tag name which separates it from others based on the functionality it provides. For example, a video element will provide different functionality than an image element or a header element.

By default, an html page is very bland. CSS, Cascading Style Sheets, is used to style an html page giving each element or a group of elements custom properties. If the background color of the website needed to be black and the text white, this would be done using CSS. 

Other than some simple animations with css, all front-end functionality of a web page comes from Javascript. A once simple scripting language designed for simple html modifications that evolved into a large front-end and back-end programming language. One use of javascript is to dynamically control html elements on the webpage. It also handles making and receiving requests from web servers. 

Originally, when data was submitted in a web application, the entire page would need to be refreshed to pull an updated html document which was common with PHP. Today, a common design architecture is to have a single page web application where the data is synchronized to the webpage without needing to be reloaded to update. 

Due to the complexity of making a single page web application, many frameworks exist to make development easier. These include react, vue, and angular. These frameworks handle linking data to components and binding the data between the server and the client. This way, only the element with updated data needs to be refreshed rather than the entire page. Handling updates in this way makes working with web applications faster and improves the user experience.

I selected this article to learn a bit more about frontend development and its current features. We will be working on client-side development in this class and I thought it would be a good topic to look into. I find it interesting the history of how the web has developed over the years. I will use this guide with its details to help me structure my projects in the future.

Resource: https://info340.github.io/client-side-development.html

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.