Earlier this semester, we worked on an assignment regarding design patterns. I found this interesting as I took a deep dive into learning more about facades. As I’ve gotten deeper into the computer science program, assignments and projects have naturally gotten bigger and bigger. I was excited to learn more about facades, because it relies on two aspects important to large scale projects: simplicity, and restriction. It can make complex projects a bit easier to follow, as well as limiting what a client has access to.

While I learned a lot about facades through this assignment, I felt that I didn’t personally study enough about the other gang of four design patterns. To familiarize myself further that what I learned in class, I listened to episode 34 of the “complete developer podcast”, focused on design patterns. It wasn’t a thorough as I would have liked, but I was able to familiarize myself a bit more on behavioral and creational design patterns. Having studied facades closer, I was already a bit familiar with structural patterns. From their explanation, these 3 types of design patterns have a lot of cross over but tend to be categorized separately primarily for human understanding. I would have liked if they discussed some actual pattens within the creational, structural, and behavioral categories, such as certain ones they use more often than others.

One key takeaway I had with this podcast is how universal these object-oriented design patterns are. One of the hosts was appreciatively saying how he’s a .net developer but could talk to a Java or Ruby developer about any of these design patterns. They may not be familiar with the language, but they would be able to follow the structure of the code. The patterns themselves aren’t that complicated, but they’re capable of facilitating much more complicated programs. I also thought it was interesting, they referenced how some languages don’t need these patterns depending on the level of abstraction built into it.

I found their criticisms of design patterns to be the most useful to me. The hosts discussed certain misusages of design patterns, and these are things I can keep in mind going into the future. In particular, as some programs evolve, they may require a different design pattern than what’s originally implemented. What I take away from this is that it’s important to diagram your project before you get too invested in it. A simple UML diagram can likely show you if you’re using the right pattern, or if you’d need to change as you get further into the project.

From the blog CS@Worcester – Derek's Design by dereksspace and used with permission of the author. All other rights reserved by the author.

I have already written two separate blog posts on the topic of Class Diagrams (UML and ER) so it only seems right that I revisit how they relate to hierarchies in programming. During this semester, we transitions from UML Class Diagrams into hierarchies with class assignments and a homework project about ducks. The fact that the assignment was based on a program about ducks sounds funny, but it was actually a great example to work with for learning hierarchies better. Some ducks can fly, swim, quack, or squeak depending on the type of duck (including rubber ducks etc.). This is perfect because although all the duck types are considered “ducks,” they all cannot do the same things. This means that programming classes for the different ducks was extremely efficient if it had a good hierarchy for the classes. Rather than hard-programming what every duck could do one at a time, the hierarchy allows the programmer to write much less (as well as have a much easier time adding or deleting duck types). Obviously since all the ducks where considered “ducks” the main class we had to write was just the duck class. Every other class extended off this class and inherited functions from that class. If some ducks shared similar actions and properties, then they would be grouped together under another class and so on. This often creates a web/tree shape if the program where to be drawn out in a diagram. I have learned about hierarchies and their benefits and importance before this semester, but revisiting it is always good for me, especially since I have a bad habit of trying to hard-program things if I am not getting the hierarchy to work the way I want it to. For this post, I did not use a link, but I certainly would still recommend looking around the internet or in books to find all the information about this very important topic of computer programming. All of the studying, researching, and practicing is valuable!

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.

No one likes messy code, and everyone likes simplified code, so I was interested in learning more about refactoring. While the idea of enhancing code sounds fairly intuitive, I wanted to learn more about tips and practices to use when refactoring code. In the past, I’ve been guilty of leaving my code in rough shape, until after I finished. While my habits have improved, I still have a lot to learn in these regards. To help learn some refactoring methods and practices, I listened to episode of 78 of Full Stack Radio, with guest Ben Orenstein. Orenstein, dubbed “one of the refactoring guys”, formerly worked at Thoughtbot in Boston, and now offers a course on refactoring, as well as gives lectures on the subject.

What I really liked about this podcast with Orenstein is how direct he was with all his tips. None of his advice sounded complicated, because he used very simple, explicit language. In fact, this type of language demonstrated one of his tips: “make the implicit explicit”. For example, give full words when naming object. If there’s an intermediate equation in the middle of a method, leave comments or naming conventions that clearly state why it’s there and what it leads to. Too often, I’ve used vague abbreviations in my naming conventions. While in most small-scale programs, this isn’t an issue, I realize this could be very problematic on larger projects.

“first make the change easy, then make the easy change.”

One of the best tips I thought Orenstein offered during the podcast was preparatory refactoring, or to refactor code before making changes, rather than refactoring while making changes. In this regard, your preemptive changes can cause you to have to make less changes further down the line. He gave an example of once refactoring code prior to a new feature being implemented. In the end, the new feature was pulled and not implemented, but his refactoring in advance still improved the codes functionality.

I feel like I took a lot away from this, from small tips to things I never thought about. Something that caught me slightly off-guard was when Orenstein talked about not wanting to return null values but replacing them with empty arrays. I don’t recall ever learning about this, and they didn’t go into much detail about it, so I researched it a little further on my own. This podcast helped highlight the importance of refactoring and I’m sure I’ll continue to research more refactoring methods throughout my career.

https://fullstackradio.com/78

From the blog CS@Worcester – Derek's Design by dereksspace and used with permission of the author. All other rights reserved by the author.

The class that I am taking right now goes over database design patterns, so it is only right that I research even more about them for this most recent blog post. I found an incredible website that discusses all sorts of designs, some which that I have never heard of before this. I will attach the link to the website but it was from sourcemaking.com. The examples that the website describes all fall under three different categories: creational, structural, and behavioral design patterns. The creational design patterns are defined as being all about instantiation. There are other subclasses of this design pattern group like class-creational and object-creational patterns. Some examples from the website of patterns in this larger group are builder, singleton, factory method, and more. In contrast, the structural group of patterns are all about class and object composition. Some examples of patterns from this group are adaptor, composite, bridge, decorator method, and more. The last group, behavioral, is defined as patterns for Class’s objects communication. These patterns are mostly concerned with communicating with objects. Some examples of this design pattern group are command, iterator, observer, visitor method, and more. I am very happy that I went back and revisited this topic from my class, especially since I am about to take the final in this class. I recommend taking a look at the same website that I used to research for this blog post, and I genuinely wish I found it earlier in this semester!

https://sourcemaking.com/design_patterns

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.

As I near graduation, many of my courses become more specialized towards my actual major and concentration. This semester, I have been enrolled in two computer science classes that, despite being very different, have help emphasize each other with their abstract similarities. Software Construction, Design, and Architecture repeatedly proved the value and worth of Database Design and Applications time and time again. The same could be easily claimed with the roles reversed. The reason I want to share this in my blog is not to say they are similar classes, but to express how important it is to me that my courses relate. If a class I take relates to something I do in real life or something I want to do later in life, it is easier for me to put effort into getting the most out of the class as I possibly can. Furthermore, I have already stated in previous posts that knowing that something I am learning is usable in real life is very motivating, while not being sure if I will ever use the information I study can be the opposite. So why does this all relate back to my two separate courses in this semester? It is because both classes are for different concentrations of my major but still share conceptual similarities. I chose to be a software development student which relates to Software Construction, Design, and Architecture directly, while Database Design and Applications is geared more toward Big Data Analytics. Seeing the similarities between these two classes helped show me that what I am studying is very worth it and can be used regularly in my life. I was able to use what I learned in one class directly on something I would practice in the other… at similar time periods in the semester no less. I definitely believe that this was somewhat intentional by my school to have classes like these be on similar timeframes, and I am glad to say that it does actually motivate me a bit and validates the concepts in each course. I do not have a source or link for this post, but I did feel like sharing this because of how adamant I am about this being a great and useful tactic of teaching/learning.

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.

For the last month, including the our class’s most recent homework assignment, we have been working on Rest APIs. In the last assignment, we had to construct different Rest API Endpoints. For this blog, I wanted to learn a lot more about Rest APIs and try to master them better. I found a great blog about it all on stackoverflow.blog, and I will attach a link to that blog at the bottom of this post. I definitely recommend checking it out to learn more on this subject like I did. Rest APIs are among some of the most popular available web services that is used to allow clients and browser applications to communicate with a server. These APIs must be designed in a way that keep in mind account security, performance, and easy usability. An important thing for Rest APIs is JSON. Almost all networked technologies can use JSON as it is the standard for transferring data, and it is accepted by Rest APIs for request payloads. A lot of what the blog I read goes over is how to write Rest API Endpoints and coding. It explains the importance of including error handling, filtering, sorting, and nesting resources. It shows even more specifics like how collections should be named using plural nouns rather than verbs. This blog is super great for helping with every single specific when writing these endpoints, even down to the exact code to use for all the different common HTTP errors. It later goes on to explain using cache data to improve performance as well as specifics for versioning APIs. Overall, this blog taught me a lot more about writing these API Endpoints, and the best part is it helped show how it all is done with clear examples of actual code. It even came in helpful during my homework assignment earlier this week. Anyone looking to learn about or brush up on this topic should follow the link to see the blog that I used to research for Rest APIs, and I guarantee it will be extremely educational!

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.

In a previous blog post, I did a little research on UML and ER diagrams, and tried to express how valuable I believe they are in the real world. Today, I plan to dig deeper into the specifics of these diagrams like their formatting and meanings (if one were to look at a finished diagram. There are many specifics for a great UML Class Diagram that help to make it even more useful than simply drawing it out to represent different programs or databases. The example I discussed in my previous post when I referenced this was how the difference between a plus or minus sign before variable names shows how the variable can be public or private (plus being public and minus being private). The next thing I would like to attempt to explain is the importance of how the lines between boxes on the diagram are drawn. Each is specific enough to show exactly what type of relationship is being made between the boxes using arrows, triangles, dashes, strikethroughs, and more. If there is a full line between two boxes then it is a relationship and having a triangle at one or more of the boxes demonstrates that that box or those boxes are providing many things to the relationship. If it has a strikethrough instead, then it is providing one thing (two strikethroughs means one and only one). The boxes can have one-to-one, one-to-many, and many-to-many relationships depending on how the line between them is drawn. These rules apply more toward ER diagrams, but there are many similarities to common UML diagrams. For UML diagrams, we often use open or closed arrows or diamonds at the end of our lines that help indicate the hierarchal relationship between the boxes. Using these symbols, along with changing whether the line is dashed or solid, we can demonstrate inheritance, association, and much more. So we already can see that the format of these diagrams can show more than just the basics, but let me continue to explain even more. Before I continue though, I would like to say that visual-paradigm.com is an extremely useful website that describes all of this even better than I can. I accessed it to help me research these diagrams for two different blog posts now, and I definitely recommend giving it a look. I will leave the link to it at the bottom of this post as usual. Anyways, I want to describe the formatting of the boxes themselves next. This is for UML Class diagrams more than it is for ER diagrams, but it could be applied to both. In general, each box will represent a class in some program (or a table in a SQL database), and they are often separated into three rows. The first row is the name of the class, the second row is for the variables, and the third row is for methods (or functions, operations, etc.). Each variable and method can be public or private as I already discussed, and the methods can include the parameters in the parentheses as well as the return type at the end of the line. There is much more that can be explained, but I would like to end this post by expressing that these diagrams can be made however seems most fit for us. If we do not need to know all of the details of methods and variables, we can simply make our diagram as straight forward as we want by just putting names for the boxes. This is for looking at the diagrams conceptually rather than getting stuck in the details of each class. If we want to show a lot of the class, but not all the nitty-gritty details, we can use the specification approach, which shows details of the classes, but not all. Lastly, if we want our diagram to include all parts of the classes, we can do that as well, and it is called implementation. These are all valuable methods and designs, and it is up to the user to decide what is the best for them.

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.

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.

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.

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.