Christian Shadis, 10/20/2021

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

Our first programming language can be similar to the first language we learn to speak or our native tongue. What this pattern talks about is to first pick a language and start to master that language by practicing and solve problems in the specific language. It also talks about having some mentor or asking questions to someone more experienced so they can help guide you along the way of learning the programming language, but also at the same time not becoming dependent on them to solve your problems.

I found this chapter to be very interesting because whenever I think about coding and solving problems, the first syntax or code to use that comes in my mind is Java. The reason for this is because it is my first programming language that I learned and I have the most experience with it. This pattern has led me to confirm my belief that we need to first become better programmers in a specific language. A lot of people try to jump from one language to another and think it will be more beneficial. However, what this results to is not thorough understanding of a programming language, and more simple knowledge of each one. It is much more efficient to pick up a specific language based on your preference, and broaden your knowledge with it. Try out different problems to solve and keep on practicing. Once you feel you are at a level that you are content with, then move on to another language and broaden your knowledge about different types of programming. If you started with an object-oriented language, then learn about a functional programming language. Also, what this does is help moving from one language to another a lot better as well as understand the differences of each. With more experience in languages, we can start to see what languages are better for certain tasks and can examine advantages and disadvantages. In essence, the goal of this pattern is to take things a lot more slowly and in a more efficient way. It will be much better taking time to learn critical details then having front level knowledge. Overall, be open minded when it comes to languages as well and don’t just stick to one and decide that is it.

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.

In software development/programming related projects, much of the time making a mistake can feel like the end of the world, or at the very least a major inconvenience to everyone else around you. Yet by failing we often tend to learn more than we do by succeeding, since success seems to come most often from familiar and comfortable subjects or ideas which we might already have preexisting experience working with.

This is why I find the Breakable Toys pattern, described in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman as a way to work within a “safe space for failure” to be an interesting and largely relevant idea in the context of software development. The pattern describes the practice of building “breakable toys”, these being smaller, self-contained projects making use of the same toolsets you might use during professional or otherwise high-stakes development.

The pattern suggest building simple games or programs as a way of learning a new programming language. Building simple games such as Tetris or Checkers in order to get to grips with the language seems like it would be a fun experience, I think game development is an extremely interesting field, and focusing on your interests is an effective way to speed up familiarization with a new language by making use of something fun and engaging as a sort of “practice project”.

I have always enjoyed the idea of self-building software; the idea of having a usable program or application which is self-built is appealing. Similar to how a woodworker might feel sitting in a rocking-chair hand built from their own shop, the idea of building something which is demonstrably useful, or even just as an experiment to see what happens is a great opportunity to express creativity and explore a new topic. The added benefit of experience and potential to learn something new makes it a worthwhile experience in my opinion.

In terms of putting this particular pattern into practice, my first course of action would most definitely be to make a few simple games and applications, an image editing program or simple web browser seem like reasonable small-scale projects to work on as a learning experience.

Building something out of personal interest can make learning the required skillset a relatively painless experience, as by the end of it you will likely have something which you can be proud of and enjoy for many years to come.

Text Referenced: https://learning.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s03.html

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