Category Archives: CS-343

Law of Demeter

Todays blog is about the Law of Demeter a.k.a the Principle of Least Knowledge. This information is based off of the article, “Object Oriented Tricks: #2 Law of Demeter”, by Arun Sasidharan on the website “Hackernoon”. The law uses the Tell Don’t Ask principle which states that we may call methods of objects that are: passed as arguments, created locally, instance variables, and globals. In other words, saying that “each unit should only have limited knowledge about other units”, that are closely related to the current unit. Basically the Law of Demeter (LoD) says that it is a bad idea for single functions to know the entire navigation structure of the system, or to have a chain of functions, also known as a “Train Wreck”. The article states, “We want to tell our neighboring objects what we need to have done and depend on them to propagate that message outwards to the appropriate destination”, and that is what we need to do to solve this problem of “Train Wrecks”.

I chose this article because it was one of the first to come up when searching “Law of Demeter”. When I looked into the article it seemed like a reliable source. I also looked up reviews on the website before diving too far into the article. Many people suggested the website in their reviews so I concluded that it was a trustworthy source. The article has paragraphs discussing the law/principle, code snippets to show the before and afters of using the Law of Demeter, and then a final summary at the end to give an overview of everything talked about. I have found that articles with the same elements/structure help me a lot with understanding a new subject.

While reading about the Law of Demeter, it brought me back to a few times where I personally broke the law on projects. There has also been a few times where I have seen people break the Law of Demeter in tutorials, such as the one I watched for the Decorator Pattern. With this article, I learned how to write reliable, clean functions and to use them in a reliable manner. I also learned that it is very difficult to accomplish. As the article states, it is more of a suggestion than a law for that exact reason. Unlike some of the other principles, this is something that we cannot be proficient in in a single day. It is something to set as a longer term goal to improve on. I hope, through practice, to be able to utilize this principle in an efficient manner on future projects.

Source: https://hackernoon.com/object-oriented-tricks-2-law-of-demeter-4ecc9becad85

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

Don’t Spend So Much Time Coding Cleanly!

There comes a point in every developer’s career where they transition from “make it work” to “oh my God I need to make this look decent”. Initially, our goal is to create a functional Hello World program. However, as we develop, we slowly begin to learn proper code styles and naming conventions. After reading enough Stack Overflow Forums, we start to become self aware of how our code looks and we begin to focus on code aesthetics. While there’s merit in that, we often focus on the wrong things.

This video does a great job of explaining just that: there isn’t really any such thing as clean code. Now, that isn’t to say that there aren’t wrong ways to code. I’m sure we can all name plenty. That being said, the main point is that we shouldn’t spend our time trying to code perfectly the first time.

The best way to code is to do so as well as we can without spending too much time overly focused on getting everything right the first time. If you know you have the opportunity to do something right or cut corners, do it right. However, if you’ve spent 10 minutes trying to name a variable, give it some placeholder name and worry about it later. The first priority is functionality. Later on, you can review and refactor your code.

The main goal of refactoring is readability. In a compiled language especially, there is only so much efficiency the programmer can add. Compilers do a remarkable job of optimizing code by themselves, so your main goal should be readability. Make sure that other developers, as well as your future self, can read and understand your code. Add comments where necessary, but aim for self-commenting code. If your code is its own comment, that helps save space.

In conclusion, focus on simple and readable code. Don’t waste your time doing something that can simply refactored later, within reason. With that being said, try to do things right the first time if it’s obvious how to do it right.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

TECHNICAL DEBT

As I was preparing for my exams, I came across the term/topic technical debt as one of the topics under the review topics and this term was seen in one of the class activities. I decided to research on the topic, write a blog post to broaden my understanding for the exams. I came across this blog post that talks about technical debt and chose this blog because the concept has been broken down into topics explaining the term in-depth.

The term technical debt has been described in this blog as well as the good and bad reasons for technical debt. It also explains and gives examples on the various types of technical debt such as Planned Technical debt, unintentional technical debt, unavoidable technical debt, software entropy. It also explains some identifications of technical debt in a project and various ways on how technical debt can be avoided and managed. A youtube video is provided explaining the term as well.

In this blog I learned that although the term may sound like a financial term, it is defined as the deviation of an application from any nonfunctional requirements. Simply, it is a code you have to work on tomorrow because you took a shortcut to deliver it/software today. Technical debt just like in financial terms can have interests which is the difficulty to implement changes and thus needs to be addressed in order to prevent software entropy and risks that may relate to the source code. Teams may delay better coding and certain pieces which are understood by them to impede future development, however, interests may cumulate if these pieces, mediocre codes and known bugs that were left are not resolved.

Technical debts can be identified when code smells are too subtle than logic errors and when there are higher levels of complexities with technologies overlapping each other. Other warnings signs include product bugs that will cause an entire system crash and issues with coding styles.

I learned in Planned technical debt that organizations make an informed decision to generate technical debt knowing and understanding the risks and cost while Unintentional technical debt occurs as a result of poor practices, inexperience with new coding techniques and rollout issues. Unavoidable technical debt is created due to changes in the business and technology that present better solutions hence, making old code obsolete.

One way of managing technical debt is to assess debts and to acknowledge that technical debts exists and share discovery with stakeholders, explaining the importance of paying off technical debt earlier. Technical debt can also be managed by using Agile methodologies that can ensure that teams are working on technical debt.

I hope others find this blog educative as well.

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

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

RESTful API from another Perspective

A topic that I chose to learn more about for this week is ‘REST API Design’ as listed in our course syllabus. The source that I had used to supplement my learning was a conference talk on REST API called Never RESTing – RESTful API Best Practices using ASP.NET Web API – Spencer Schneidenbach. This source will be linked at the bottom of this post; however, I would like to mention that I enjoyed this conference talk as I found it both informative and insightful.

In the talk, Schneidenbach goes over his experiences and gives insight into building and designing RESTful API’s. He breaks down building/designing restful api into four activities, design, implementation, document, and maintenance; although he mentions that practically all four of these activities or a culmination of the two activities would be performed at once when working on api, he tries to separate the four activities in his talk. Throughout the talk he also brings up other topics such as explaining what REST and api’s are; however, I would rather discuss segments what I found informative or insightful from his talk.

One of the things he brings up when designing api is that ‘restful api != good api’; and this claim that an api that solely follows the constraints imposed for REST API does not solely make that api good; rather he argues that when building api we should be doing what makes sense and ‘throw out the rest’. I really resonated from this statement, as it made the designing process more practical in that when building api we must be flexible and logical with our decisions; and that theoretical rigid constraints are not what always works in real environments.

In conjunction to this statement, he also mentioned two prime rules he kept in mind which were, KISS and be consistent. KISS meant to keep things simple, but an element of KISS that I found insightful, was asking who we are keeping things simple for. He argues that when designing we should always keep in mind the user experience or the consumer who will be using the api. I thought this was interesting perspective to think of how to keep things simple for a consumer to use the api when designing it; in addition to this rule, he also added to not be creative and just provide enough that is necessary and no more or less, which I agreed with. For the consistency principle, it was straightforward strategy to keep things consistent with accepted best practices; however, I also enjoyed his second comment ‘be consistent, but be flexible when it makes sense’. This comment reiterated a theme in design that there is no silver bullet in designing api, and that although there are solid principles that we should follow, we need to be have some sense to find a balance with what our consumers require and want.

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

Facade Design Pattern

This week we practice docker a lot bout docker Activity, but we havent learn all about patterns so I choose to write one more Main Design Pattern call Facade Design Pattern. in my homework 3 I picked Decorated design pattern but I have’t learn more about Facade Design Design Pattern. This is really help full in programing becuse it have high level interface that make subsystem easier to use.

Facade design pattern provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.Facade pattern is one of structural design pattern among other Gang of Four design pattern. The facade pattern is appropriate when we have a complex system that we want to expose to clients in a simplified way. Its purpose is to hide internal complexity behind a single interface that appears simple from the outside. Facade also decouples the code that uses the system from the details of the subsystems, making it easier to modify the system later.

To understand the facade, let’s take a very simple example of a desktop computer machine. When we have to start a computer, all we have to do is press the start button. We really do not care what all things go inside the computer hardware and software. It is an example of Facade pattern.

In Java programming, we must have connected to a database to fetch some data. We simply call the method dataSource.getConnection() to get the connection but internally a lot of things happen such as loading the driver, creating connection or fetching connection from pool, update stats and then return the connection reference to caller method. It is another example of Facade pattern in the programming world. Similarly, we can find a lot of more examples which hide lots of internal complexities and provide simple to use interface to the programmer to work with the system. All such are facade examples.

Remember facade does not reduce the complexity. It only hides it from external systems and clients. So the primary beneficiary of facade patterns are client applications and other systems only. It provides a simple interface to clients i.e. instead of presenting complex subsystems, we present one simplified interface to clients. It can also help us to reduce the number of objects that a client needs to deal with.

When you call a shop to place a phone order, an operator is your facade to all services and departments of the shop. The operator provides you with a simple voice interface to the ordering system, payment gateways, and various delivery services.

Source:

https://refactoring.guru/design-patterns/facade

https://www.tutorialspoint.com/design_pattern/facade_pattern.htm

From the blog CS@Worcester – </electrons> by 3electrones and used with permission of the author. All other rights reserved by the author.

Adapter Design Pattern

 

    This week On my Blog, I want to talk about a design pattern. The One I want to focus on is Adapter Design Pattern. Adapter design pattern Convert an interface of a class into another interface clients expect. The adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. The adapter design pattern is a structural design pattern that allows two unrelated/uncommon interfaces to work together. In other words, the adapter pattern makes two incompatible interfaces compatible without changing their existing code. Now Let’s take a look at an example that shows how the design works. From the blog, I used it provided a diagram that I think is helpful to understand the design pattern. In this diagram, Socket wrenches provide an example of the Adapter. A socket attaches to a ratchet, provided that the size of the drive is the same. Here a Ratchet is ½ in size and the socket is ¼ without using an adapter you cannot connect the ratchet and socket together. 



    Now let us take a look at the benefits and liabilities of using the adapter design pattern. The first benefit is that you can let any two unrelated classes run together. Second, Improved the reuse of classes, it Increased the transparency of classes and it has Good flexibility. Now for the Liabilities, the Adapter design pattern takes Too much use of adapters will make the system very messy and difficult to master as a whole. For example, if an interface A and B are implemented and interface B is adapted internally. If too many tasks are running in A system, it will be A disaster. So, if it’s not necessary, you can simply refactor the system without using an adapter. Also, in object-oriented programming especially in JAVA it inherits at most one class, it can only adapt to one adapter class at most, and the target class must be an abstract class.

    A real-life example that I found was about the card reader ACTS as an adapter between the memory card and the laptop. You insert the memory card into the card reader and insert the card reader into the portable computer. The memory card can be read from the portable computer.

    This source is helpful to understand the design pattern even more. I would suggest you take a look at the website because it goes into further detail about the Adapter design pattern, including various examples using diagrams and JAVA codes. 

 

Source: https://sourcemaking.com/design_patterns/adapter#:~:text=Intent,class%20with%20a%20new%20interface

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

Rest API Design

https://www.mulesoft.com/resources/api/what-is-rest-api-design

https://restfulapi.net/

The topic I’ll be writing about this week is Rest API design which is one of the topics listed to be covered in the class syllabus, though we haven’t covered it yet if at all. It’s also worth noting that the following information is taken from the websites linked above. Rest API design or simply Rest stands for REpresentational State Transfer and is an architectural style for distributed hypermedia systems. The purpose of Rest is to create web services that have reliability, fast performance, and the ability to grow by reusing components that are managed and updated without affecting the larger system. There are six guiding restraints that an API must follow to implement Rest. The first is “client-server” which states that the client and server should be completely separate in order to improve scalability and portability. The second is “stateless” which means that each call should contain all the data needed to complete itself. The third is “cacheable” which means that the storage of cacheable data should be encouraged. The fourth is “uniform interface” which means the interface should follow four constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state. The fifth is “layered system” which means ordering components in a layered system. The sixth and optional constraint is “code on demand” which means REST allows code or applets to be transmitted via API for use within the application.

            Rest API design is generally used to increase performance and make web services that implement is easier to use. For example, the first constraint “client-server” as I already mentioned earlier increases scalability and portability. The second constraint “stateless” reduces the amount of work a server or a client needs to do depending on which is calling. The same applies to the other constraints; they all improve on a web service in some way or another. Of the sources I’ve looked at, I could only find one major drawback which is that you can lose the ability to maintain state in REST, such as in between session. But even then, it’s not that big of a drawback since one of the constraints of REST is refraining to use states so it’s an intentional design choice. So overall, Rest API design is an architectural style that sets out to accomplish a specific goal and does it well with minimal drawbacks. And from what I’ve read, there is really no reason to not use it if states aren’t required and the goal of the designer is to save resources.

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

Adapter Design Pattern

I’ve always found Derek Banas’ channel really useful. In late middle school, I started watching his tutorials for how to code. So it’s really interesting to go back and watch his videos, to say the least.

I feel like the adapter design pattern is something that shouldn’t really need to be used. Don’t get me wrong, it’s very useful. Like real adapters, however, the problem itself shouldn’t really exist. That’s especially true with code; it seems as though adapters become required when interfaces aren’t abstracted well enough. In his video, for example, he has an EnemyAttacker interface that represents some kind of enemy. However, the methods are very specific and presume certain characteristics about the attacker. We then need to use an adapter to get around that specificity. It seems to me that writing the interface more generally to begin with would be more ideal. But given that it’s a bad idea to modify old working code, an adapter is a great solution.

In principle, an adapter does exactly what you expect it to: it adapts code. It takes one “interface” and connects it to another “interface”. That’s the colloquial interface as opposed to a coding specific interface. We use adapters every day. The best example is a phone charger. It converts (or adapts) 120V AC power to a low DC voltage. It also adapts the physical plug into USB type-c. All of the functionality is hidden inside of the charger and from the perspective of a user, it’s literally plug and play.

An adapter in code acts the same. I honestly like the example he gave so if you want to see an example of actual code, check out his video. Conceptually, one description of an adapter is the following: We have two interfaces A and B that have many differences, but are conceptually similar. We can create an adapter so we can use any A as a B, or vice versa. It’s okay because of their similarity (or perhaps they need not even be similar!). Really, it’s an incredibly basic pattern so the specifics aren’t that important.

Fundamentally, an adapter is just code that allows other code to operate together. Again, I think the best way to conceptualize it is through the imagery of any real life adapters. However, it should ideally not be necessary in scenarios such as the one from the video. Abstraction, within reason of course, should be prioritized ahead of time.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Design Patterns: Useful Tools for Structure & Organization

When I was first learning about programming and writing code, I never stopped to consider issues like effective layout, efficiency, or structure in my programs. At these early stages, it was enough for me that the code worked and ran without crashing. Now, as I have been studying design patterns in one of my University classes, I have seen the value that design patterns, and taking consideration to layout and structure can bring to a program.

I think that following a structure or a framework of some kind can definitely bring some much-needed order to what would previously have been organized solely by necessity and convenience. Without a design pattern, my code would often be organized based purely on instinct and whatever seemed easiest in relation to the particular functionality I was currently in the process of implementing, without taking into account the effects this would have on the rest of the project.

This brings me to an article I found relevant to the topic, a post from the personal blog of a software developer (https://madhuraoakblog.wordpress.com/2017/03/01/design-patterns-revisiting-gang-of-four/) which talks about each of the different Gang of Four design patterns, (of which I was surprised to learn there are a total of 23). This post goes into sufficient detail for each of the different design patterns, without inundating the reader with excessive information. The author provides a simple explanation of each of the design patterns originally presented in the book Design Patterns: Elements of Reusable Object Oriented Software. Many of these patterns were unfamiliar to me with the exception of the creational patterns and maybe half of the structural patterns, which I had worked with for class assignments prior.

Of these 23 design patterns, I want to highlight one specifically which stood out to me in terms of versatility and overall usefulness.

Bridge pattern

Photo by Pixabay on Pexels.com

The bridge pattern is used to separate an abstract class or method from the class implementing it, by using inheritance/hierarchies. The example given by the author is of an abstract feedback class, with two sub-classes: questionnaire and comment, with each utilizing the same variable reviewable which was previously defined by the parent class, thereby acting as a bridge to separate the sub-classes from each other (both can be changed without it having any effect on the other as a result of the separation). I think this concept is useful because it keeps sub-classes notably separate from each other, while allowing them to each retain important aspects from the parent abstract class, so you can have each subclass be completely different besides the bridge aspects of the program which link them together.

I can see this being especially useful in programs where there are large amounts of specific functionalities added on to more centralized base abstract classes which define boilerplate functions and basic attributes.

Overall, I think that the Bridge pattern will likely be useful to me in the future, and combined with another pattern like decorator could be used to build a program with highly specific sub-classes which elaborate on functionalities defined in a central base abstract class. I believe this combination would be helpful in building GUI style projects, word processing applications, or anything where high flexibility and customizability is warranted.

Post Referenced:

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

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

DOCKER

We have been working on Docker doing some activities in class for some time now so I decided to look for more resources on that talks more about Docker. I finally settled on this blog that gives tutorials on Docker. I chose this blog because it talks about some topics and defines some terms relevant to know when working with Docker. Links to some concepts and to some Docker commands are provided to explore the concept further.

In this blog, Docker has been defined with some examples, and reason for its popularity. It also talks about the difference between virtualization and containerization. Advantages and disadvantages of each of these concepts have been provided. A youtube tutorial is also provided to explain the concept further. It also talks about the benefits of using Docker and explains some other concepts such as Dockerfile, Image, Container, DockerHub, Architecture and Docker Compose. Some diagrams have been provided to help visualize some of the concepts being talk about. As I was reading through, I came across a link to a page that talks about Docker and Containers, explaining with examples and I found that very helpful.

I learned in this blog that Docker is a containerization platform that packages application and all of its dependencies together in the form of a docker container to ensure that application works well in all environment. A docker container is a standardized unit that can be created on the fly to deploy a particular application or environment. Docker have functionalities that are useful to both developers and system administrators.

Virtual machines and docker container are similar in the sense that they both allow running of multiple operating system inside a host machine.  However, Docker unlike Virtual Machine, allocates exactly the amount of memory required by a container which helps to create additional containers from any leftovers of allocated memory which by so doing, increase productivity. Docker saves a lot of time to start since the container runs on host operating system unlike Virtual Machine which runs on guest operating system, so it takes a lot of time to boot up.  Docker containers are also lightweight and faster because containers created are run from the host operating system.

In addition, I learned that multiple containers in docker can be run as a single server by using Docker compose. Also, Docker engine is an application installed in the host system that uses a server, a command line interface and a REST API. Images are built and containers are run by passing commands from the command line interface and the server. Docker images are also the building blocks of a Docker container and these images are stored in Docker Registry.

https://www.edureka.co/blog/docker-tutorial

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