This week, I am going to discuss the function and design of a Simple Factory pattern in Object Oriented Programming. At a very high level, this allows a programmer to centralize and encapsulate instance creation functionality into one class, as opposed to having many different classes (or your main class) depend on a large number of different classes. In my opinion, this is particularly useful when designing code that uses the strategy design pattern, as there will be objects for every concrete strategy, and many dependencies will be created. It is much easier (in at least those instances) to encapsulate all of those dependencies and creations into one class, a factory, and have that factory be dependent on all of the classes instead.

These principles are highlighted well in this blog, which provides a use case to demonstrate the usefulness of a factory. In this post, the example used is an implementation of a creature factory (admittedly less cool than a duck factory). Before implementing a simple factory, the main class is responsible to create and instantiate different creatures, and they can be created from anywhere in the code. This works, but is poorly designed, as we have discussed in class. Any time you want to make a change to the way a creature functions, for example, you might have to go edit the code in a ton of different places, and your UML diagram might just look atrocious. To address these design flaws, we can introduce the Simple Factory pattern, which centralizes creature creation logic into one dedicated class. This factory handles the instantiation of various creature types, simplifying our main class instead of scattering creation logic throughout the code. Whenever we need a creature, we call a method on the factory, which returns an instance of the requested object.

The blog example creates a CreatureFactory class with a method create(CreatureType type), which accepts the desired creature type. Inside this method, we use a conditional statement to return the appropriate creature object based on the input. For example, if we get WEREWOLF we instantiate a Werewolf object. If we want to add a new creature type, like Phoenix, we just create a new class for it and update the factory method. There’s no need to search through the entire codebase for instances where creatures are instantiated.

I admittedly don’t do a lot of object oriented programming, but the principle of using a factory makes perfect sense to me, and is something that I do and will continue to do going forward. Centralization of creation looks clean, performs clean, and makes sense. I didn’t really get into this, but it also may be extremely useful for OOP languages that do not have automatic memory management like Java does. You could also centralize the destruction of objects, possibly allowing for efficient tracking and memory allocation/deallocation.

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

This week, I am going to discuss the importance of licensing your code – something that I did not know was important until this week. The blog post I will be referencing can be found here. I chose it because it provides both a simple explanation of the importance of licensing and it explicitly describes the fallacy that causes most developers (myself included) to not license their code. The blog also references some of the same specific licenses we discussed in class, which (along with some research) indicated to me that there is a small set of very popular licenses that can serve a variety of purposes and target a variety of different intents and audiences.

After reading this blog post, reading others, looking at different open source projects on GitHub, and having discussions in class, the conclusion I’ve come to is this: the top reason people don’t license their code is because they don’t understand that licensing actually gives people more rights, not less. Many (again, my prior self included) likely think that if you just code something and throw it onto GitHub, that anybody can use it as open-source. This is not the case; that is actually incredibly restrictive, because you own the copyright to that work, and nobody can use that code without running into some legal barriers. Whether those barriers will ever be realized is another question, but not including a license may be enough to deter people from expanding on your work. A well-chosen license clearly communicates how others can use, modify, and distribute your work. This not only protects the rights of the original creator, but also allows others to expand on the work without the constant worry of stepping on legal toes. Licensing is better thought of as a way to invite others to engage with your code, rather than a barrier that restricts access.

The MIT License, to give an example, is concise and straightforward, allowing users to do almost anything with the code, as long as they include the original license and copyright notice. This simplicity has made it a favorite in the open-source community, encouraging collaboration and making it easier for developers to share their projects without too many legal constraints.

Understanding code licensing not only protects your work but also leads to a more collaborative and innovative development environment. Whether you want to encourage broad usage with an MIT license or ensure that your project remains open-source with a GPL, the right license can significantly impact how your code is shared and utilized. Moving forward, I plan to include licenses in any open source code I write. Though I never thought it was important before, I’ve learned now that it actually is critical if I want my code to actually be usable by others.

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

The blog post I’ve chosen is all about PlantUML diagrams and how they can be used in ways to help your coding. The author writes about why diagrams can be useful for seeing things visually in a text heavy environment like coding is. There are many advantages to representing code in a diagram. Making the program abstract and only focusing on the process of how each thing should work with the others helps to focus on concepts rather than the implementation and actual workings of the code. There are also many types of diagrams, such as sequence diagrams that show what events take place over time, a use case diagram that shows what different levels of users are able to do, class diagrams that detail different objects’ construction, activity diagrams that can show workflow, and others. PlantUML is able to be used in many different ways for many different scenarios. There are sometimes problems that PlantUML cannot solve in the most elegant way, as the author describes, but there are alternatives and some problems that PlantUML was not designed to solve.

I think this blog was helpful to read through and see just how versatile PlantUML diagrams can be after learning about how to make them in class. Another benefit to diagrams that the blog didn’t go over, but we did in class was being able to find potential problems in the code before you even type anything which can save a lot of time. I think that using UML diagrams more often can help me with coding as having a diagram that gives me a top-down view would be helpful to look at instead of scrolling through a wall of text to find what I need to do next or how I can improve my code. I sometimes find that I can overcomplicate some sections of my code and having a written out simplified plan to look back at will help me code with more focus and also help with encapsulation which I don’t do as often as I should.

After reading this blog I will be more aware of what situations could be helped with a PlantUML diagram and make one to keep me focused on the structure and entire scope of the program. There are also ways to use diagrams in order to show processes that I haven’t used yet or have talked about in other classes which could be a good tool to use in the future to explain and show complex abstract processes.

PlantUML Diagrams – Matt Hayes

From the blog CS@Worcester – Computer Science Blog by dzona1 and used with permission of the author. All other rights reserved by the author.

Link to blog: https://developer.ibm.com/articles/an-introduction-to-uml/

To start off the new semester and new course, we’ve been learning, discussing, and practicing with UML diagrams, or Unified Modeling Language diagrams. These diagrams are great ways for software developers and companies to visualize the structure of programs, large or small. There are many different types of diagrams, and we’ve mainly covered Class Diagrams and Sequence diagrams. 

Although I am unsure about the popularity and usage of UML diagrams in professional environments, I believe they can be beneficial to the organization and cleanliness of a team’s code, for it is to be written after it has already been structured and designed. The article I chose today is one by Donald Bell on IBM, and it discusses a few types of UML diagrams with some background information on each.

Bell introduces a new topic to the audience as well as anyone should: with some background information. He states the creation of UML was to model computer applications and ensure that anyone who understands UML diagrams can efficiently, accurately, and productively contribute to the project. 

The first UML diagram covered is the Use-Case diagram. Such diagrams are utilized to help readers understand the interaction between the program and its users. There can be many Use-Case diagrams for one program, but they are more so used to highlight the essentials. Bell describes how to create this type of diagram so that it is easy to understand.

The second UML diagram covered is the Activity Diagram, which shows “the procedural flow of control between two or more class objects while processing an activity” (Bell). Bell believes the best-case scenario for this type of diagram is for more business-oriented visualizations, such as how a company wants to operate at a higher level. These types of diagrams are not as technical as other diagrams which makes it easier to understand for non-programmers (Bell).

The last UML diagram Bell covers is the Deployment Diagram, which shows the physical representation of a software system. This would mean user computers, databases, websites, etc.

I selected this article because it covers a few UML diagrams that we haven’t discussed in class, and it is important for software developers to have some UML proficiency.  This would be a beneficial skill to have at a new job, so you might understand the codebase faster. IBM is also a very credible company in the software industry which is why I chose an article from their website.

The content of the resource was presented in an understandable way for someone with a little bit of software knowledge. I enjoyed learning about the background of UML and its creation, along with the three types of UML diagrams that were listed and described. I hope to use such knowledge at a new job that may use UML diagrams so I could provide more productivity in a shorter time rather than taking too much time trying to understand the codebase.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Chapters 2-6 in the Apprenticeship Patterns textbooks goes over the specific different practices and patterns that software developers use in order to grow in their field.

Chapter 2 talks about the values of “emptying the cup” as an apprentice. Embrace the beginner’s mindset with The White Belt. Overcome roadblocks with Unleashed Enthusiasm. Acquire concrete skills in specific technologies to explore advanced patterns. Avoid complacency by systematically broadening your tech skills. Expose your ignorance to focus on learning needs. Confront and flex your knowledge muscles. Take audacious tasks to learn and grow. Retreat into competence when overwhelmed, then gather yourself to ascend further.

Chapter 3 explains how many people are walking the same path even when they seem to be on a different path. In other words, the experts that know more than you in the work field went through the same struggles (walked the same path) as you are to get to where they are now. It explains the story of Dave as he continues his journey in software development with a sense of assurance. However, his interactions with highly skilled hackers in online communities and face-to-face collaborations with high level developers humbled him and fueled his desire to learn. As he delved deeper into side projects and consuming learning material, Dave realized the vastness of knowledge available and the continuous learning process inherent in software development. While there is a considerable gap between his skills and those of seasoned developers, Dave found solace in the shared journey towards mastery that all developers embark on.

Chapter 4 introduces the concept of letting go of perceived competence and allow yourself to recognize that there is way more to learn and more to travel down the Long Road. The rapid learner faces the risk of becoming complacent in their success within their current environment which could stagnate their growth. It is crucial for such individuals to acknowledge the broader landscape of opportunities beyond their immediate sphere and to remain humble in the face of their accomplishments. The focus should not be on surpassing others but on personal growth and improvement, recognizing that the journey towards mastery is ongoing and that collaboration and mutual support are integral to this process.

Chapter 5 emphasizes the concept of learning and, especially for apprentices, how it is critical these patterns be applied early on in their journey. The essence of apprenticeship in software development revolves around perpetual learning and effective communication. Apprentices must constantly seek opportunities to replace ignorance with skill, not only acquiring concrete technical abilities but also in developing the ability to learn itself. These concrete learning activities such as “Expanding your bandwidth” and “Breakable Toys” pave the way for deeper self-discovery, leading to the importance of reflecting on work. sharing knowledge, creating feedback loops, and understanding personal weaknesses to transition successfully from apprentice to journeyman and eventually master craftsman.

Chapter 6 talks about the constant time and effort that should be put into studying to further develop your learning curriculum. In today’s age digital age, access to vast amounts of information is easy, thanks to the Internet and handheld devices. While blogs and online resources offer valuable content, the wisdom found in traditional books by experts like Jerry Weinberg and Kent Back is irreplaceable. Incorporating reading into an apprenticeship is crucial for success, allowing individuals to construct their own learning curriculum.

2. Emptying the Cup | Apprenticeship Patterns (oreilly.com)

3. Walking the Long Road | Apprenticeship Patterns (oreilly.com)

4. Accurate Self-Assessment | Apprenticeship Patterns (oreilly.com)

5. Perpetual Learning | Apprenticeship Patterns (oreilly.com)

6. Construct Your Curriculum | Apprenticeship Patterns (oreilly.com)

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

The first pattern from “Apprenticeship Patterns” by David H. Hoover and Adewale Oshineye that I would like to write about is “Practice, Practice, Practice”, from chapter 5 of the textbook. I’ve been learning how to code since shortly before I started my first semester at community college, in the fall after I graduated from high school. I’ve been able to complete the lessons that I’ve been assigned at school and through online resources, but even still today, whenever I’m working, I feel like I’m calling on every last bit of knowledge that I’ve got, and that once I’m on my own in the real world I’m going to end up drowning. This anxious feeling can get especially distracting when I imagine how much more progress and work there is to do in building myself into a competent software developer, let alone an exceptional one. Consequently, reading this textbook has been something of an exposure therapy exercise for me.

Developing some kind of practice regimen to reinforce my fundamental skills would go a long way toward constructing a sense of basic competence that I can eventually build on to enhance my skillset. Here I am about to graduate with a degree in computer science, and I honestly can’t say I know how to practice programming outside of school without starting a project and “just doing it”. This approach results in me feeling a lot of pressure to learn many new concepts and produce something useful before I get up from the chair again, and because my emotions quickly become too strong and distracting, I don’t end up doing either of those things. I need to develop a new way to practice my computer programming skills.

The phrasing of the problem presented in this pattern caught my attention because of how much I related to the sentiment: “It’s as if you’re always on stage.” I feel like every time I open my text editor to complete my daily tasks, or whenever I need to research a new subject, it’s the ultimate test of my ability and merit as a programmer. It’s going to be incredibly difficult to test my limits over the course of my career if my everyday experience feels so drastic. The solution offered through this pattern is the technique of practicing through “code katas”. The author explains that the term “kata” is borrowed from martial arts, and that it as a term which refers to a sequence of movements provided by a teacher to their students, performed without an opponent. The purpose of executing the kata is to reinforce the student’s fundamentals and build their physical control, fluidity, and power.

The benefits of applying the same practice of repeating fundamental movements to build overall competence towards the craft of software development are that it enables a practice environment without deadlines or expectations and that this method of practice allows learners to build their self-confidence without introducing the stress that comes with delivering complex software projects. About practicing with code katas, software developer Dave Thomas says “It has to be acceptable to relax, because if you aren’t relaxed you’re not going to learn from the practice.”

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