Design Patterns, and other such oddities

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” from A List Apart ,which is a
blog that specializes in having many writers from the Computer Science
industry comment on various issues and topics. I figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

 

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Design Patterns, and other such oddities

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” from A List Apart ,which is a
blog that specializes in having many writers from the Computer Science
industry comment on various issues and topics. I figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

 

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Design Patterns, and other such oddities

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” from A List Apart ,which is a
blog that specializes in having many writers from the Computer Science
industry comment on various issues and topics. I figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

 

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

The World of Software Licenses

 This week in class, we discussed what goes into licensing a piece of software, along with copyright law. If I am being perfectly honest, this wasn’t what I was expecting to study in this class, though it makes sense, in a way. Licensing, as I have learned, is a very important part of software development, and knowing who owns what, and defining who can do what with your code ties in pretty well to the other topics we’ve been discussing in class. As such, I’ve taken a look at an article from A List Apart, which is a blog that specializes in having many writers from the Computer Science industry comment on various issues and topics. I’ve chosen the article: “Considering Open Source Licenses”, which talks about one of the things most interesting (and confusing) to me in terms of licensing, Open Source Licenses.

One would think that making software open source would be as simple as declaring it as such. However, in the real world, it’s a little more complicated than that. What you really need to do is to attach a license to your software that describes what can be done with it, and there are several different licenses you can choose from, all with different requirements and specifications. Most of the licenses discussed in the article are, what else, open source licenses. All of them do functionally the same thing, allow people to use your software and edit it as they see fit. However, they all have slightly different specs that are important to keep in mind. The MIT license for instance, only requires you to keep the original license in tact, and attach a copyright notice to your project if it uses code that has the MIT license attached to it. GPL, on the other hand, requires you to document modifications made to the software, whether that be through traditional documentation or how-tos on how to use the software. The article also discussed in brief, some of the problems that occur if you were to violate a license, which isn’t something that was discussed in class, and was something I found interesting.

The article makes it very clear that nothing covered is concrete legal advice, and of course, I am no lawyer either. That being said, licensing isn’t nearly as difficult as I once thought, I was under the impression it was similar  to filing a patent, or some other legal document. I am happy to be wrong, in this case, and for any software I develop in the future, I will be sure to put some more though into licensing in the future!



(Side note: It has occurred to me that I am absolutely TERRIBLE at spelling the word license. I’ve spelled it so many different ways in the writing of this post it is almost comical. I also appreciate the fact that copyleft is a genuine term, since I was only familiar with copyright)


ARTICLE LINK: https://alistapart.com/article/considering-open-source-licenses/



From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

The World of Software Licenses

 This week in class, we discussed what goes into licensing a piece of software, along with copyright law. If I am being perfectly honest, this wasn’t what I was expecting to study in this class, though it makes sense, in a way. Licensing, as I have learned, is a very important part of software development, and knowing who owns what, and defining who can do what with your code ties in pretty well to the other topics we’ve been discussing in class. As such, I’ve taken a look at an article from A List Apart, which is a blog that specializes in having many writers from the Computer Science industry comment on various issues and topics. I’ve chosen the article: “Considering Open Source Licenses”, which talks about one of the things most interesting (and confusing) to me in terms of licensing, Open Source Licenses.

One would think that making software open source would be as simple as declaring it as such. However, in the real world, it’s a little more complicated than that. What you really need to do is to attach a license to your software that describes what can be done with it, and there are several different licenses you can choose from, all with different requirements and specifications. Most of the licenses discussed in the article are, what else, open source licenses. All of them do functionally the same thing, allow people to use your software and edit it as they see fit. However, they all have slightly different specs that are important to keep in mind. The MIT license for instance, only requires you to keep the original license in tact, and attach a copyright notice to your project if it uses code that has the MIT license attached to it. GPL, on the other hand, requires you to document modifications made to the software, whether that be through traditional documentation or how-tos on how to use the software. The article also discussed in brief, some of the problems that occur if you were to violate a license, which isn’t something that was discussed in class, and was something I found interesting.

The article makes it very clear that nothing covered is concrete legal advice, and of course, I am no lawyer either. That being said, licensing isn’t nearly as difficult as I once thought, I was under the impression it was similar  to filing a patent, or some other legal document. I am happy to be wrong, in this case, and for any software I develop in the future, I will be sure to put some more though into licensing in the future!



(Side note: It has occurred to me that I am absolutely TERRIBLE at spelling the word license. I’ve spelled it so many different ways in the writing of this post it is almost comical. I also appreciate the fact that copyleft is a genuine term, since I was only familiar with copyright)


ARTICLE LINK: https://alistapart.com/article/considering-open-source-licenses/



From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

The World of Software Licenses

 This week in class, we discussed what goes into licensing a piece of software, along with copyright law. If I am being perfectly honest, this wasn’t what I was expecting to study in this class, though it makes sense, in a way. Licensing, as I have learned, is a very important part of software development, and knowing who owns what, and defining who can do what with your code ties in pretty well to the other topics we’ve been discussing in class. As such, I’ve taken a look at an article from A List Apart, which is a blog that specializes in having many writers from the Computer Science industry comment on various issues and topics. I’ve chosen the article: “Considering Open Source Licenses”, which talks about one of the things most interesting (and confusing) to me in terms of licensing, Open Source Licenses.

One would think that making software open source would be as simple as declaring it as such. However, in the real world, it’s a little more complicated than that. What you really need to do is to attach a license to your software that describes what can be done with it, and there are several different licenses you can choose from, all with different requirements and specifications. Most of the licenses discussed in the article are, what else, open source licenses. All of them do functionally the same thing, allow people to use your software and edit it as they see fit. However, they all have slightly different specs that are important to keep in mind. The MIT license for instance, only requires you to keep the original license in tact, and attach a copyright notice to your project if it uses code that has the MIT license attached to it. GPL, on the other hand, requires you to document modifications made to the software, whether that be through traditional documentation or how-tos on how to use the software. The article also discussed in brief, some of the problems that occur if you were to violate a license, which isn’t something that was discussed in class, and was something I found interesting.

The article makes it very clear that nothing covered is concrete legal advice, and of course, I am no lawyer either. That being said, licensing isn’t nearly as difficult as I once thought, I was under the impression it was similar  to filing a patent, or some other legal document. I am happy to be wrong, in this case, and for any software I develop in the future, I will be sure to put some more though into licensing in the future!



(Side note: It has occurred to me that I am absolutely TERRIBLE at spelling the word license. I’ve spelled it so many different ways in the writing of this post it is almost comical. I also appreciate the fact that copyleft is a genuine term, since I was only familiar with copyright)


ARTICLE LINK: https://alistapart.com/article/considering-open-source-licenses/



From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

On the subject of using Simple Factories…

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.

On the subject of Licensing your Code…

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.

Diagrams and Code

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.

Understanding Design Smells and Technical Debt: A Beginner’s Guide

In the world of computer science, especially for those new to programming, concepts like design smells and technical debt can seem daunting. However, grasping these ideas is crucial for building sustainable software. Design smells are indicators of potential problems in your code, such as overly complex structures or poor naming conventions. Technical debt, on the other hand, refers to the compromises made during the development process that can lead to greater issues down the line, akin to borrowing money that needs to be paid back later.

I recently came across the article “Understanding Technical Debt” by Tom Smith on Medium. This piece breaks down these concepts in an approachable manner, making them easier to understand for beginners. Smith discusses common design smells, such as “Long Method” and “Feature Envy,” and explains how they can accumulate into technical debt if ignored.

I chose this article because I believe it provides a solid foundation for understanding these concepts without overwhelming beginners with jargon. As I embark on my journey in computer science, I find it essential to learn about the long-term implications of my coding decisions. Smith’s article highlights the importance of recognizing design smells early on, which resonated with me as I often focus on getting things done rather than considering the quality of my code.

What I learned from the article is that design smells serve as early warning signs. For example, if a method is too long or complex, it may indicate that it’s doing too much and should be broken down into smaller, more manageable pieces. This insight has made me reflect on my past coding experiences, particularly a group project where we rushed to implement features without thoroughly reviewing our code. The result was a project that became difficult to manage and understand. I realized that by overlooking design smells, we inadvertently added technical debt to our project.

Moving forward, I plan to apply this knowledge in my coding practice by adopting a more mindful approach. I want to prioritize code quality and regularly check for design smells as part of my workflow. Implementing practices like peer code reviews and refactoring sessions will help ensure that my code remains clean and maintainable. I believe this proactive approach will not only enhance my skills but also contribute to a more positive team environment where everyone is encouraged to uphold coding standards.

In conclusion, understanding design smells and technical debt is vital for anyone starting in computer science. By paying attention to these indicators, we can write better, more maintainable code. I highly recommend reading Tom Smith’s article for a beginner-friendly introduction to these essential concepts.

Resource:
* Fowler, M. (n.d.). Technical Debt and Design Smells: A Practical Guide. Retrieved from Martin Fowler’s website.

* Smith, T. (n.d.). Understanding Technical Debt. Medium. Retrieved from Medium.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.