Category Archives: CS343

Blog #2: UML Diagrams

Fairly earlier in this semester we worked with Unified Modeling Language (UML) and Entity Relationship (ER) diagrams. These tools are both extremely useful in representing databases. I often find that the way these diagrams show databases without coding is similar to how pseudocode shows how a program or method works without explicitly coding. In this way, like pseudocode, these diagrams are perfect for putting together a project before actually programming it like brainstorming. For my final project this semester in a separate class, I had to make a database for an ice hockey program using SQL queries. Before I even started writing queries for that project, I started putting it together in an ER diagram without even thinking about it. This made the actual programming for that project ten times easier. For the purposes of this blog, I decided to dive deeper into studying UML and ER diagrams to try to learn even more about them. I found an awesome article about UML Class Diagrams at visual-paradigm.com that tried to be a tutorial on how they work. I will leave the link to it at the bottom. It backs up my claims that they diagram is used primarily for visualization of projects after, during, and most importantly before they are programmed. It also went over a ton of specifics and formatting for the diagrams that we went over in class this semester like the layout of the tables or boxes and the different arrows that showed relationships in the model database. It gets way more in depth than I plan on being in this blog post like when to use a plus sign instead of a minus sign for variables in the tables (for private and public variables). I definitely recommend checking it out yourself as it taught me a lot, not just now, but at the beginning of the semester itself. Similar to the situation with Docker for me, I found that it was supper awesome that I was able to see that learning these diagrams in class would prove useful in real life. When I used a diagram for my final project in my other class (which was not required), I knew that these were very important tools in the real world. For that reason, I am especially happy that it was one of the topics that we covered this semester.

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Blog #1: Docker Platform

A large topic that we covered this semester has been Docker. For that reason, I decided to do a bit of outside research on what it does well and how to use it as best as possible. Most of the helpful information that I found for this topic came directly from Docker’s website in the Docker Overview section. I will put the link to that at the end of this post. The website claims that Docker is used mainly for enabling the user to separate their applications from their infrastructure so software can be delivered quickly. This definitely holds true with what we have learned in class and with what we have used Docker for specifically during this semester. It is a free platform that thrives off of helping users develop, ship, and run applications. Its biggest strength is that is shortens the time it takes to go from writing code to running it in a production. Docker containers are indubitably important because they allow many developers to edit and program locally while being able to share their work with others. Containers, to put it simply, are runnable images. Images are templates that have instructions to help build containers and are read-only. A lot of work for docker actually is done in command prompt applications like Git Bash or Terminal. For this class, I used Terminal because I have a MacBook. At first, when using Docker in this class, it was very unclear to me how it all functioned or what the point of using it was. After some time, I began to realize the importance of it as it made connecting programs easy and quick for me. It has come to my attention that the Computer Science department at Worcester State is actually trying to create an entire database for the cafeteria workers with the help of undergraduate students. This was very exciting for me to hear for many reasons. I always am appreciative when I know that what I am learning in school has real life implications and uses, and this motivated me to want to learn it even more. Not to mention, it might be a specific platform that I will need to use in my Capstone for my last semester here before graduating. This blog post has been an extra excuse to take some time to research Docker even more than before and dive deeper into learning what it is for/why we use it rather than simply how to use it. This is not to say that I would not have done more research on Docker outside of class in general (especially with the Capstone next semester), but more to say that this blog is in some way motivating me to get the research done and helping me understand the platform even more by allowing me to discuss my findings. I definitely recommend anyone wondering about Docker to read the information I studied before this blog post by using the link I will put at the bottom. Coming from the Docker website itself, I believe it is a great reference to learn about the free platform and extremely helpful when trying to discover how it works and why we use it.

https://docs.docker.com/get-started/overview/

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Don’t Talk to Strangers

The Law of Demeter was proposed by Ian Holland in 1987. During the development of a system called Demeter using oriented object programming, Holland and his colleagues realized that the code that fulfilled a series of rules was less coupled. Although it is called The Law of Demeter, it is not really a law, but more of a guideline to help reduce coupling between components. When applying LoD to object orientated design, there is a set of four rules that formalizes the “Tell Don’t Ask” principle;

You may call methods of objects that are:
1. Passed as arguments
2. Created locally
3. Instance variables
4. Globals

A great example of this is:

    class User {
        Account account;
        ...
        double discountedPlanPrice(String discountCode) {
            Coupon coupon = Coupon.create(discountCode);
            return coupon.discount(account.getPlan().getPrice());
        }
   }
   class Account {
       Plan plan;
       ...
   }

Here account.getPlan( ).getPrice( ) violated the LoD. The most obvious fix is to delegate/tell:

    class User {
        Account account;
        ...
        double discountedPlanPrice(String discountCode) {
            // delegate
            return account.discountedPlanPrice(discountCode);
         }
     }
     class Account {
         Plan plan;
         ...
         double discountedPlanPrice(String discountCode) {
             Coupon coupon = Coupon.create(discountCode);
             return coupon.discount(plan.getPrice());
         }
      }

Each function should have a limited amount of knowledge as opposed to knowing about the whole object map so our neighboring objects need to know what we have done in order to depend on them to propagate that message to the correct location. Following this rule is hard, which is why it is called the “Suggestion of Demeter” by many because it is so easy to violate. Following this rule, though, is extremely beneficial because any function that “tells” instead of “asks” is decoupled from the rest of the code around it.

The blog I retrieved this information from was https://hackernoon.com/object-oriented-tricks-2-law-of-demeter-4ecc9becad85. The information was extremely easy to follow and understand. The coding examples given to show the difference between following the LoD and not following it were simple and clear. I also found the explanation of LoD given to be simple and to the point. Going forward with coding, although understanding that following LoD can be hard, I plan to utilize this guideline in order to enhance and simplify all of my future codes.

By following the LoD in future coding endeavors, my code will be easier to test, I can reuse classes more easily, the amount of coupling and dependencies between classes will be reduced, my code will more flexible when I make changes to it and it will be more maintainable.

Information gathered for this blog:
https://medium.com/better-programming/demeters-law-don-t-talk-to-strangers-87bb4af11694
https://hackernoon.com/object-oriented-tricks-2-law-of-demeter-4ecc9becad85
https://en.wikipedia.org/wiki/Law_of_Demeter

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

“Encapsulate what varies”

When asked the question “Which object-oriented design principle do you think is most important?” a Software Architect named Nicholas Cloud answered, “Encapsulate what varies”. I must say, I couldn’t agree more. In his blog, DeveolpIntelligence, Nicholas writes about his desire to constantly look for ways to utilize this principle to make writing expressive and maintainable code easier. He gives a lot of great examples and breaks them down, explaining each way they can be changed and why that change makes the code better.

Encapsulation means to bundle data with methods that operate on that data, or to restrict the direct access to some of an objects components. There has been some debate between programming language researches on which meaning they prefer to use. The Gang of Four suggests that we consider what should be variable in our designs. This approach is the opposite of focusing on the cause of redesign. Many design patterns use encapsulation to create layers between objects, making it easy to change things on different sides of the layers without negatively affecting the other side. There are so many advantages of encapsulation, from data hiding, to reusability, to making testing your code easier.

As one of the fundamentals of OOP, it is arguably one of the most important due to the number of advantages it brings. I found all the information I obtained from a few different blog posts and articles, all of which had almost the exact same information. Having read just the definition, understanding the true essence of encapsulation was difficult, but the code examples I found were extremely helpful and made things clearer. I thought the manner in which the information was presented was easy to follow and the use of real-life examples and comparisons kept me interested enough to stay focused on the subject. Below is an example I found easy to understand;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16		 class Person {
String name;
int age;

 void talk() {
}
 
void think() {
}
 
void work() {
}
 
void play() {
}
}
The common characteristics and behaviors of a person are packaged into a single unit: the Personclass. The Person class is an encapsulation unit and the Person object exposes its attributes and behaviors to the outside world:
1
2
3		 Person you = new Person();
you.name = "John";
you.work();
Here, encapsulation hides implementation details of the Person class from other objects. Likewise, creating an interface is also the process of encapsulation:
1
2
3
4
5		 interface Human {
void eat();
void talk();
void think();
}
This interface groups the essential behaviors of human-being in a single unit.

The rest of the examples can be found at https://www.codejava.net/java-core/the-java-language/what-is-encapsulation-in-java-the-what-why-and-how.

I enjoyed learning about this principle and I feel more confident going forth in this field knowing yet another way to make writing code neater, more maintainable, flexible and easier to read.

Knowledge obtained for this blog post:
https://www.informit.com/articles/article.aspx?p=167890&seqNum=4
https://www.developintelligence.com/blog/2013/04/encapsulate-what-varies/
https://levelup.gitconnected.com/object-oriented-design-principles-bb6daf98b185
https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)
https://www.geeksforgeeks.org/encapsulation-in-java/

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

The Power of Functional Programming

As I have started to learn some about Javascript, I am very intrigued by the new territory and the strangeness that comes with it, at least for someone like myself, with most of my experience coming from object oriented programming languages like Java and C. As I now know, Javascript is a functional programming language, which has some fundamentally different structures and uses. For this reason, I have started to looked into the usefulness of functional programming, as languages like Javascript and Python are quickly on the rise. I found an article on Xiaoyun Yang’s personal blog entitled Why Functional Programming From A Developer Productivity Perspective which has helped me make some more sense of the intent and uses of functional programming. The article starts with basic info on FP, stating how object oriented programming came to popularity in the 80s with the use of GUIs and how, “it’s easier to program things that use a fixed number of operations for an unlimited number of operation,” but how now, “stateful programming is more of a liability” since, “there is an increasing emphasis on asynchronous, distributed, multi-core and cloud computing.” The article then dives into FP design patterns, which explain its usefulness. The intent is for functions to act as, “pipes for data to travel through,” with Higher Order Functions taking functions as input, and polymorphic function adding to reusability and versatility. The first pattern is the Loop Pattern. The emphasis is on abstraction. In the example, for loops are used for arrays of different types, and the goal is to get rid of the type by, “[parameterizing] the loop action as a function parameter and the initial value as a data parameter.” This provides for the reusability of the function in different contexts. The next pattern is Types. The article compares Scala being type-safe to Javascript. This means, “you can impose the argument type and return type when you first define your function in Scala.” This means for non-type-safe languages like Javascript, the onus is on the programmer to ensure clashing types do not lead to errors. While sometimes type inference in Javascript can be convenient, it can create problems when working with different types. The third pattern is Monads. This means that one can use monads instead of, “hard coding error handlers,” with a monad essentially being a wrapper. There are so many errors to worry about when handling user input, so this is advantageous. The last pattern is Monoid. An example is given for a function to find is any strings in array(s) are not empty. It shows that whatever order the arrays are given to the function, or wherever the unempty string exists, the function still works, preserving associativity and commutativity. Monoid laws help verify correctness. The article finishes by stating that FP promotes reusability and modularity through abstracting functions. This is all new to me and I hope this knowledge helps me soon, as the next language I intend to learn will be a FP language like Javascript or Python. It is essential to keep up with the fast-paced world of computer science.

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

Anti-Patterns

Anti-patterns are patterns in software development that are considered bad programming practices. The exact definition is “An Anti-pattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences.” More understandably put, an anti-pattern is a way of not solving a problem. Anti-Patterns are said to be the opposite of Design Patterns, for instance, with Design Patterns, users usually start with a well-defined problem and identify the best path to take to the solution, whereas with Anti-Patterns, they begin with a failed solution, which can be challenging and usually further complicate matters.
(http://antipatterns.com/EdJs_Paper/Antipatterns.html)

I found a video online that I found easy to follow along to by Andy Sterkowitz on 5 programming anti-patterns that was specifically geared towards beginners. The first anti-pattern he spoke about was ambiguous naming; ambiguous naming of variables, functions and classes. He explains that when you’re writing code, your variables should be well named, to make your ( or another’s) comprehension of your code easy. He suggests really thinking about what you’re planning on naming things within your code to simplify things. The second anti-pattern he spoke about was magic strings and numbers.
Example:

if (age > 21) {
// do something
}
By the context of this, obviously you’d be checking for the legal age.. but you can’t assume that this information is known.

The third anti-pattern is called lava flow. He compared this anti-pattern to how lava flows continuously and hardens along the way, saying that as a programmer early on, you think you’re just creating all these small little apps you might need but you’re actually making parts of your application warped or hard to develop. He suggests to use Git to modify and make changes to your code instead of building a whole bunch of different sections. The fourth anti-pattern he talked about was cut and paste. What that means, he says, is when you see a code and there are ten or so different functions that all just say the same thing basically. He suggests to instead make one function that does everything or even one class. Doing this will save you time from having to go back through each and every function and modify one thing. The fifth anti-pattern he talked about is called the poltergeist pattern. Andy explained that this is basically just code that doesn’t serve a true purpose, like a class that just calls upon another class.

Through this video, I learned that the best way to write code is to not have a lot of code and to really make sure you have strict guidelines about when it is appropriate to make a new class, method or function. Andy gave a lot of useful and helpful tips on how to improve my coding skills and what common mistakes I should avoid doing in the future. He used easy to grasp and very relatable metaphors and comparisons to real life that made understanding his explanations of the patterns easy and interesting. While watching this video I had quite a few “wow, that’s really helpful.” moments and I realized there are a few things I should and will be changing from here on out to tidy up my code.

Video used for this entry:
https://www.youtube.com/watch?v=lQ_rGCL17EE

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

What’s that smell?

In computer programming, a code smell is any characteristic in the source code of a program that possibly indicates a deeper problem.[1][2] Determining what is and is not a code smell is subjective, and varies by language, developer, and development methodology.
The term was popularized by Kent Beck on WardsWiki in the late 1990s.[3] Usage of the term increased after it was featured in the 1999 book Refactoring: Improving the Design of Existing Code by Martin Fowler.[4] It is also a term used by agile programmers.[5]
(From Wikipedia, the free encyclopedia)

During her presentation at RailsConf in 2016 called Get a Whiff of This, Sandi Metz talks in depth about code smells, the practical effect of recognizing them and doing refactoring. My reason for choosing this particular source of information was because she gave real life examples and comparisons that helped me to better understand problems within codes that were humorous and I found her explanation of the types of code smells and how to fix them entertaining, easy to understand and very useful. Sandi presented examples of code she herself had written and demonstrated through diagrams and easy to follow steps how to refactor the code to make it neater. At the end of her presentation Sandi gives reference to a static analysis tool called Reek that you can run on your code and it will tell you what to go look at, so you don’t even need to go figure it out yourself.
This presentation really boosted my confidence as a programming student and gave me higher hopes as a future programmer. While watching this presentation video, I learned that most code is a mess, even the best coders can have messy code, and when given difficult or complex code, it can be broken down and easily fixed even if I am not able to understand everything within the given code. Going forward, I will definitely be referring back to this video to help me spot and correct any imperfections within my own code or any code I am given.

The 5 different categories of code smells are:

  1. The Bloaters – these make code bigger than they should or need to be.
  2. The Object Orientation Abusers/Tool Abusers – these are ideas that are available that you can misuse.
  3. The Change Preventers – these make change hard.
  4. The Dispensables – these represent something unnecessary that should be removed from the source code.
  5. The Couplers – these come as a bundle, they represent the attraction behavior of two classes which could be called excessive.

    (https://youtu.be/D4auWwMsEnY)

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

Let’s talk about adapters

This week I will be touching base on a structural design pattern called the adapter pattern. This pattern has two different versions, the class adapter – which implements the adapter using inheritance and can only be used in C++, and the object adapter – which uses composition to reference an instance of the wrapped class within the adapter. For the purpose of this blog post, I will be speaking only of the object adapter pattern.

Structural design patters are supposed to simplify your design, the adapter pattern in particular makes doing so easy as pie. The adapter pattern reuses old interfaces and provides different interfaces to its subject in order to make things work after they’ve been designed, even if the previous interfaces were incompatible. So what can this pattern do? Let’s break it down a bit:

– Change the interface of an existing object.
– Provide a different interface to its subject.
– Make things work after they’ve been designed.
– Reuse old interfaces.

The adapter pattern addresses incompatible interfaces and lets classes work together that previously could not due to incompatibility by converting the interface of a class into another interface that the clients expect. This conversion process allows software to exchange and make use of information. When you are dealing with different interfaces with similar behaviors, it is best to use this design pattern to help develop a clearer, more easily understandable code. A brief list of some of the benefits of using adapter patterns are:

– It is a low-cost solution.
– It is easy to understand.
– Incompatible code can communicate with each other.
– It makes things work after they’re designed.
– Helps to reuse existing code.

Information gathered for this blog post:
https://stacktraceguru.com/adapter-design-pattern
https://www.geeksforgeeks.org/adapter-pattern/
https://www.java2novice.com/java-design-patterns/adapter-pattern/
https://sourcemaking.com/design_patterns/adapter

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

Facade Design Pattern

This week on my CS Journey, I want to talk about the design patterns, Especially the Facade design pattern. In class, we also learned about other designs which are helpful. However, I wanted to focus on the Facade design pattern. To start of Facade is a structural design pattern that adds an interface to an existing system to hide its complexities. In other words, it provides a simple interface that can be used to manipulate more complex logic behind the scenes, that are hidden from the main user. According to the Gang of Four, the Facade pattern intends to “Provide a unified interface to a set of interfaces in a subsystem” From the blog I used it provided a diagram that I think is helpful to understand the design pattern. In the diagram, we can see that Facade is acting as an interface for the complex Subsystems that are hidden from the main clients. 



Now let’s take a look at a real-life example. A good example that I found was When a computer starts up, it involves the work of CPU, memory, hard drive, and other subsystems. To make it easy to use for users we can add a Facade that wraps the complexity of the task and provide one simple interface instead. This applies to the Facade design pattern because it hides the complexities of the system and provides an easy interface to the users. 

 

One of the liabilities is that a Facade might provide limited functionality in comparison to working with the subsystem directly. Does not prevent applications from using subsystems classes if they need to. Also, it can increase the number of wrapper classes. Another liability is that Facade can perform way too many tasks. One of the benefits is that it reduces compilation dependencies is vital in large software systems. Overall, The Facade design pattern is helpful when dealing with the complex system because It enables us to use the complex system much more easily.

 

There are a lot of examples, diagrams, and Java Codes, readings and a link to a GitHub resource that are provided in the blog I used. I would suggest you to take a look at the website because it goes into further detail about the facade design pattern, including various examples using diagrams and also this reference contains a lot of information that is broken down into easy steps which are user friendly.

 

Source : https://www.baeldung.com/java-facade-pattern

















From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

YAGNI

Welcome back!

This week in Coding Kitchen, we explore one of the key principles of Extreme Programming, YAGNI (You Ain’t Gonna Need It). This principle states that some capability we think our software will need in the future should not be built now because “you aren’t gonna need it“, or as XP co-founder Ron Jeffries put it, “Always implement things when you actually need them, never when you just foresee that you need them.”

The YAGNI principle is to be used in conjunction with other practices, such as continuous integration, continuous refactoring and continuous automated unit testing. Without the additional use of any of these other practices, your code could go into Technical Debt, which means it could become disorganized and need to be reworked. Using the YAGNI principle saves you time by helping you to avoid writing code that you do not end up needing and by making your code better because you did not have to fill it with guesses that turned out to be wrong.

In an article posted by Martin Fowler, he uses an example about selling insurance for the shipping business. His example states that an insurance company’s software system is broken into two components, pricing and sales and that the dependencies cannot usefully build sales software until the relevant pricing software is completed. His example also states that while the company works on updating the pricing component to add support for risks from storms, they consider working on a feature they will not need for another six months for piracy pricing. By adding on this additional feature now, Fowler declares that doing so would incur three classes of presumptive features, and four kinds of costs that occur by neglecting YAGNI for them.

1) Wrong feature — Cost of building, cost of carry + cost of delay
2) Right feature, built wrong — Cost of repair, cost of carry + cost of delay
3) Right feature, built right — Cost of carry + cost of delay

I chose this article because this particular example given by Fowler highlights the benefits of using YAGNI and why neglecting to do so would inherently cause many issues and become costly. As a future software engineer, I would prefer having to write less code that is easier to understand rather than have lines of useless, possibly obsolete code. I found Fowlers explanation of YAGNI and his further explanation of the many ways applying this principle could cause problems in comparison to the very few ways it could be of benefit easy to understand and useful. Having knowledge of this principle as a programmer will make writing and editing code in my future professional endeavors much more time and cost effective.

Inspiration and information gathered for this blog post :

https://dzone.com/articles/martin-fowlerbliki-yagni-youre-not-gonna-need-it

https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

http://c2.com/xp/YouArentGonnaNeedIt.html

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.