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.

Need for YAGNI

For this weeks topic, something I that I chose to learn more about and get a better understanding behind of is YAGNI; which stands for You Aren’t/Aint Gonna Need It. To supplement my understanding for this topic, I watched a small conference video about a Software Architect, Ian Thomas, who gives a talk about the importance of YAGNI in real world environments. Throughout the talk some of the main points were that YAGNI reduces costs, and he also gave fixes or solutions for promoting YAGNI in work environments; and he also gives examples from his experience to better explain the importance of YAGNI.

Throughout the talk, I enjoyed some of the quotes and references he brings up because I thought they were powerful and changed my perspective of the software industry. In his introduction he brings up a Uncle Bob quote, which was ‘the number of developers in the world doubles every five years’; and then he points out that means half the developers entering the markets have less than 5 years of development. This is actually a worrisome quote when considering that one of the less experienced developers may be working on an airplane or automobile system that I may use in the future; however, Ian brings up this point because it ties to another reason for promoting YAGNI. This benefit of YAGNI is making material easier for new hire ups to understand and pick up; he refers to this as carry costs improvement.

Out of the other costs benefits he covers, he says that reducing carry costs is an important benefit of YAGNI often not acknowledged; it is also one I was not aware about. Carry costs may refer to the impact given from writing a new feature and when YAGNI is not upheld this often means that a new feature is overly complex, which would mean that it would take someone too much time to read before adding on or working in conjunction with that feature; this would also make it harder for new hire ups to pick it up. It appears that the code smells needless complexity and obscurity are byproducts of the absence of YAGNI in code.

Rather Ian mentions something important to think about when writing a new feature. A recurring theme that he brings up is thinking about the future; and so think, about writing/refactoring in a way that it’s not going to be too hard to write later on because you’ve taken the time to leave it in a good state now. And the quote he used for this was “it’s better to do a simple thing today and pay little more tomorrow to change it if if it needs it, than to do a more complicated thing today that may never be used anyway”.

And his takeaways to keep up YAGNI were narrowed down to keep things simple, to change things in small increments and also test them so you get to understand how the system is working and what you’re doing for your customers. Also he advises having courage in being able to stand up and explain why you are doing something and need to take the time to do it.

Link to Video Below

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.

REST API’s

This week on my CS Journey, I want to look closely at the topic of REST API Design. I know We have been doing several activities regarding the topic in class and the homework assignment is associated with it, however, I wanted to be very knowledgeable on the topic, so I decided to do more research. REST is an acronym for Representational State Transfer. A REST API is a way for two computer systems to communicate over HTTP in a similar way to web browsers and servers do. Let start by looking at what An API is, An API is an application programming interface. It is a set of rules that allow programs to talk to each other. The developer generally creates the API on the server and allows the client to talk to it and the REST determines how an API should look like.

Now let’s look at the anatomy of a request is, An API request has four main important parts: The endpoint, The method, The headers, and The data or body. When an API interacts with another system, the touchpoints of that communication are considered endpoints. Each endpoint is the location from which APIs can access the resources they need to carry out to do their function. The way APIs work is using “requests” and “responses.” Meaning that each URL is called a request while the data sent back to you is called a response.

Generally, when it comes to methods it has five types. Which are: GET, POST, PUT, PATCH, and DELETE. These methods provide meaning for the request you’re making. They are also used to perform four possible actions that are Create, Read, Update, and Delete also known as CRUD. Next, the Headers are used to provide information to both the client and the server. It can be used for many purposes, such as authentication and providing information about body content. Lastly, the body or the data is what contains information you want to be sent to the server. This option is only used with POST, PUT, PATCH, or DELETE requests.

Overall, I learned a lot from this blog. The source I used explained the topic very well. I highly recommend everyone to check it out, because it has a variety of examples and documents that you need to know about REST APIs to be able to read the API documentation and use them effectively. It also goes deep into the methods and the request meaning of each of them, I think it is very important to understand those concepts because companies all over the world are using APIs to transfer vital information, processes, transactions, and more.

Source: https://www.smashingmagazine.com/2018/01/understanding-using-rest-api/

https://www.sitepoint.com/developers-rest-api/

From the blog Derin's CS Journey by 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.

What is Rest API

API is short for Application Programming Interface (API), which describes a class library’s characteristics or how to use it. Your personal library may contain “API documentation” of available functionality.

A REST API in API Gateway is a collection of resources and methods integrated with back-end HTTP endpoints, Lambda functions, or other AWS services. You can use API Gateway features to help you with all aspects of the API lifecycle, from creation through monitoring your production APIs.

API Gateway REST APIs use a request/response model where a client sends a request to a service and responds back synchronously. This kind of model is suitable for many different kinds of applications that depend on synchronous communication.

When many people refer to API documentation these days, they often refer to an HTTP API that might share your application data over the web. For example, Twitter provides an API that allows users to request tweets in a specific format to easily import them into their own applications. This is where the HTTP API is potent. It can mix and match data from multiple applications to a mixed application or create an application that enhances the experience of using other people’s applications.

It is an application that allows us to view, create, edit, and delete parts.

REST is the shorthand for Representational State Transfer, which was proposed by Roy Fielding T to describe the standard way of creating an HTTP API, and he found that the four common behaviors (view, create, edit, and delete) could all be mapped directly to the implementations in HTTP.

The different HTTP methods:

• GET

• POST

• PUT

• DELETE

• OPTIONS

• HEAD

• TRACE

• CONNECT

Most of the time, when you’re looking at your browser’s dots, you’re using the HTTP GET method. The GET method is only used when you request resources from the Internet. When you submit a form, you often use the POST method to send data back to the site. As for the other approaches, some browsers may not fully implement them at all. But that’s fine if it’s for our use. We have many HTTP methods to choose from to help describe these four behaviors, and we will use client libraries that already know how to use these different HTTP methods.

Rest API benefits:

• Resource oriented, easy to see

• To GET something, you need to GET (GET is safe, does not modify the service resource), you need to POST (POST is unsafe), you need to PUT (PUT is idempotent), and DELETE (DELETE is idempotent).

• Traditional CRUD requires four different interfaces, but the REST API requires only one. (Distinguish between different requests)

Source:

https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-create-api-from-example.html

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

What is Rest API

It is an application that allows us to view, create, edit, and delete parts.

The different HTTP methods:

• GET

• POST

• PUT

• DELETE

• OPTIONS

• HEAD

• TRACE

• CONNECT

Rest API benefits:

• Resource oriented, easy to see

• To GET something, you need to GET (GET is safe, does not modify the service resource), you need to POST (POST is unsafe), you need to PUT (PUT is idempotent), and DELETE (DELETE is idempotent).

• Traditional CRUD requires four different interfaces, but the REST API requires only one. (Distinguish between different requests)

Source:

https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-create-api-from-example.html

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

What is Rest API

It is an application that allows us to view, create, edit, and delete parts.

The different HTTP methods:

• GET

• POST

• PUT

• DELETE

• OPTIONS

• HEAD

• TRACE

• CONNECT

Rest API benefits:

• Resource oriented, easy to see

• To GET something, you need to GET (GET is safe, does not modify the service resource), you need to POST (POST is unsafe), you need to PUT (PUT is idempotent), and DELETE (DELETE is idempotent).

• Traditional CRUD requires four different interfaces, but the REST API requires only one. (Distinguish between different requests)

Source:

https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-create-api-from-example.html

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

GRASP (General Responsibility Assignment Software Patterns)

Hello everyone and welcome to week 11 of the coding journey blog. In this week’s post I will be talking about the design pattern acronym GRASP. This acronym is short for general responsibility assignment software patterns. Design patterns are essential for software developers, and we will dive more deep into the benefits of using GRASP.

Originally, the GRASP design patterns were introduced after gang of four book, which has details on commonly used software design patterns. The GRASP design pattern is answering what each certain role each aspect plays in the software. There is the controller whose essential role is to take responsibility to encapsulate a system operation, which is something the user is trying to process such as purchasing an item. The system operation is achieved by calling one or more method calls between the software objects. Also the controller is responsible for providing a layer between the UI and the domain model. Then there is the creator which is responsible to help decide which class going to be responsible for creating a new instance of a class. There is a pattern known as high cohesion which is essentially responsible to keep objects understandable and more manageable. An example of this is breaking classes down and different subclasses for different roles making it easier in the bigger picture. Then there is the indirection principle which is responsible for low coupling and gives interaction responsibility to an intermediate object. Another part of GRASP is the information expert which gives guidelines about giving responsibilities to classes and one example would be methods.

Also in the GRASP design pattern there is the pattern of low coupling which decides how to assign responsibilities to lower dependency of classes and the change in classes impacting on another as well as the higher reuse potential. Polymorphism is a concept most of us know about because it is one of the principles of objected oriented programming. In brief to recap the concept, polymorphism provides guidelines on how to use the object oriented feature in your design. Then there is protected variation which protects elements from the variation on other elements by wrapping it with an interface and using polymorphism for many other implementations. The last part of the GRASP principles is pure fabrication which is made up to achieve low coupling and high cohesion with a class that does not represent a concept in the problem domain.

I personally think that the design concepts of GRASP have many essential components of programming and creating real world software. Many of these components are used in our everyday world and features we see without even recognizing. As I learn more in my coding journey and take in more concepts, I will most certainly take into account GRASP principles in my future projects to make it easier.

For more resources on this topic check out these links:

https://dzone.com/articles/solid-grasp-and-other-basic-principles-of-object-o https://medium.com/@ReganKoopmans/understanding-the-grasp-design-patterns-2cab23c7226e

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Angular: What and Why

For this blog post I chose to focus on something I have used multiple times but still did not fully understand, this being Angular. I have been using it only on my own personal project to build a web application, but have not actually sat down and researched what I was using. Thus for this blog post I will explore exactly what Angular is, and specify some situations where it could be useful to implement. To begin, I will try to define exactly what Angular is.

Since, as stated, I do not have much knowledge about exactly what angular is, I found some other posts to reference. The first of which is Angular Introduction, written by an experienced programmer Ilya Bodrov-Krukowski. I would highly recommend checking out this blog post, as it goes far more in depth than I will be able to. From my relatively brief time with Angular, I assumed it was just a web application development and hosting platform, but the answer is not this simple. This initial assumption was not entirely wrong, just missing some parts. As stated in Angular Introduction, Angular is really more like a collection of tools that can be used to develop a web application and it defines how the app should be designed and organized. Essentially, Angular sort of guides you on exactly how to go about making the app, which would explain why I had a relatively easy time working with it. Some other important features Angular provides is data binding and dependency injection, both mentioned in Ilya Bodrov-Kurkowski’s blog post. Data binding essentially meant that you could see changed data in a view in real time and dependency injection, “allowed application components to be wired together in a way that facilitated reusable and testable code”(Angular Introduction). These are extremely useful, as databases are used on a variety of applications, and being able to reuse code is always helpful. But why should you use Angular?

To answer this I am going to discuss my own experience with it. Before this, I wanted to give the reasons listed by Agular’s own blog, Angular University. I do not want to spend too much time on this, as there are many visuals on this post that help put this into perspective, but Angular handles a lot of backend work that I never even knew about. Essentially a jQuery application is compared to an Angular application, and the jQuery app has much more code with fewer efficiencies. As always I will leave the links for each post below, but I would recommend just scrolling through this one to understand the difference. As for my own experience, Angular was surprisingly straightforward to use. After getting it installed, it is as simple as adding some html for your web app and some components, using JavaScript code, and inputting a few command prompt lines. If you are developing a web application, I would highly recommend considering this framework.

Links:

https://www.sitepoint.com/angular-introduction/

https://blog.angular-university.io/why-angular-angular-vs-jquery-a-beginner-friendly-explanation-on-the-advantages-of-angular-and-mvc/

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Docker Simplified

Despite the fact that I have been using docker containers for multiple weeks now, I still find the concept of docker containers to be a bit more mystical than I would like. Thus, I chose to try and find some good sources that break down this concept, which led me to a podcast on Spotify of all places. To begin however, I wanted to give a summary of what is stated on Docker’s own website. These containers are called a standardized unit of software, sort of like a big zip file containing the program, relevant libraries, dependencies, etc.. This allows containers to be used across any system, as normally you would have to ensure that the systems utilizing your program have all relevant data before using your program.

The podcast I found gives a more general overview of Docker as a whole and, if you are still a little hazy on exactly what it does, I would highly recommend giving it a listen. Essentially, docker containers are much faster than utilizing a virtual machine, as they do not require an entire image of an operating system to run on. Having used some virtual machines, such as VMWare, in the past, I can definitely confirm that Docker is significantly faster, and easier to install. You can also run multiple containers simultaneously that are all self contained. This could be useful for larger projects, as you could have one facet that has different dependencies or requirements, or maybe one is required to run in a different language than another. These containers are all “wrapped” into an image that will run these containers, but also has all of the other important information, as was listed above. These programs can be even further customized through creating your own docker file. This could allow you to specify, for example, one image to use node and java whereas you have another utilizing bash and python, and much more.

To summarize, Docker containers essentially act as their own self contained systems, in a similar conceptual manner to a virtual machine. Its core function is to give each user their own environment to run certain software, but removing the issue of varying operating systems. The amount of containers you may want will vary, depending on the scope of your program. These containers are unique in that they are both more lightweight than a virtual machine and allow great consistency in terms of normalizing system to system deployment for users. Additionally, multiple containers can be combined into an image, which is a collection of containers to be run together. Thus you can see the reasons why Docker containers, and Docker as a whole, are so interesting.

Sources:

https://www.docker.com/resources/what-container

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this: