In addition to learning about design patterns that should be referenced when programming, I wanted to learn about bad software design, which led me to anti-patterns.

A wonderful source covering anti-patterns that I learned from can be found at: https://www.freecodecamp.org/news/antipatterns-to-avoid-in-code/.

Anti-patterns are bad software designs that show how not to solve problems in programming. The source covers 6 different anti-patterns: Spaghetti Code, Golden Hammer, Boat Anchor, Dead Code, Proliferation of Code, and the God Object.

Spaghetti Code is when there is barely any structure to the code. Files are thrown in random directories and it is difficult to follow the flow of the program. This would produce many issues when needing to modify the code, because the program can break and it would be difficult to tell what caused it. It would also be difficult to estimate what may break after you make a change.

Golden Hammer is when you repeatedly use an architectural approach in your code that does not exactly fit the program you are making. Despite the fact that it doesn’t exactly fit the program, it is still utilized because it gets the job done eventually. Problems arise from the fact that it does not fit the program, and can cause longer runtimes.

Boat Anchor is when programmers leave code in the codebase that has no purpose at the moment, and is kept incase it is needed in the future. This code acts as an anchor because it holds the program back– it increases build time, and can make code reading difficult when programmers have to discern between code used and the code saved for later.

Dead Code is when programmers cannot tell which parts of code are currently necessary for the program and which parts of code are no longer needed.

Proliferation of Code is when objects in your codebase only serve to create a more important object. This makes the code more difficult to follow.

God Objects are objects that have too many responsibilities. The code should be broken down more so that objects do not have to undergo functions that other, smaller bits of code can cover.

The Boat Anchor anti-pattern reminded me of YAGNI (“You aren’t gonna need it”). YAGNI is the principle that you should not add functionality to the program until it is actually needed. Adding the functionality in advance may end up messing with schedules and requirements may be changed in the future where that functionality is not even needed. The God Object anti-pattern reminded me of the single-responsibility principle (which the article briefly mentions). These anti-patterns will be very useful to apply to my code to prevent the program from being too complex and hard to follow.

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.

DESIGN PATTERNS.

Design patterns provide a comprehensive solution that can be reused for common problems that arise in software design. A design pattern isn’t a complete design that can be transformed directly into code.

Types of Design Patterns:

• Creational Design Patterns
  Creational Patterns deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. They reduce complexity and instability by creating objects in a controlled manner.

Types of CDP:

1. Abstract Factory

Creates families of related dependent objects.

• Builder

Constructs complex objects using step-by-step approach.

• Factory Method

 Creates an instance of several derived classes.

• Prototype,

 Creates a new object from an existing object.

• Singleton,

A class of which only a single instance can exist.

• Structural Design Pattern

These design patterns are concerned with arranging different classes and objects to create larger structures and provide new functionality. Structural class-creation patterns use inheritance to create interactions/interfaces.

Types of SDP:

1. Adapter

Allows for two incompatible classes to work together by wrapping an interface around one of the existing classes.

• Bridge

Separates the outline so that the two classes can differ on their own.

• Composite

Composite patternconsider a group of objects to be one.

• Decorator
  Allows for an object’s behavior to be extended dynamically at run time.
• Facade

Provides a simple interface to a more complex underlying object.

• Flyweight

Flyweight pattern takes the weight, or memory footprint, off of our objects by recycling them.

• Proxy

This pattern offers a proxy, or a substitute, to another complex object. Provides a space interface for the primary object to control access, reduce costs, or reduce complexity.

• Behavioral Design Patterns

Behavioral patterns are about identifying common patterns of communication between objects and identifying these patterns.

Types of BDP:

1. Chain of Responsibility.

Delegates commands to a chain of processing objects.

• Command.

Creates objects which encapsulate actions and parameters.

• Interpreter.

Implements a specific language.

• Iterator.

It accesses the elements of an object in sequence without revealing its basic representation.

• Mediator.

Allows for free integration between classes as it is the only class that has in-depth knowledge of their methods.

• Memento.

Provides the ability to restore an object to its previous state.

• Observer.

 Is a publish/subscription pattern that allows a number of observer objects to see an event.

• State.

Allows an object to change its behavior when its internal state changes.

• Strategy.

Allows one of a family of algorithms to be selected on-the-fly at run-time.

1. Template Method.

Defines the framework of the algorithm as an abstract class, allowing its sub-classes to deliver consistent behavior.

1. Visitor.

Separates an algorithm from an object structure by moving the hierarchy of methods to a single object.

REFERENCE

1. https://www.geeksforgeeks.org/design-patterns-set-1-introduction/
2. https://sourcemaking.com/design_patterns

From the blog CS@Worcester – THE SOLID by isaacstephencs and used with permission of the author. All other rights reserved by the author.

What is YAGNI?

YAGNI – You aren’t gonna need it is an Extreme Programming (XP) key practice that’s states: “Always implement things when you actually need them, never when you just foresee that you need them.”As it stated then programmer should not add functionality until it is proven to be absolutely necessary

YAGNI Principle always recommends programmers to build the easiest solution to today’s problems. Even if you are sure you will need the feature, moreover, do not run it now. Mostly, it’ll alter in either:

1. You won’t need it after all, or
2. What you really need is different from what you originally thought.

Why YAGNI Principle is mostly relevant in Software Development Lifecycle than others?

In Software Development when software developers start implementing features they always go into practices known as FEATURE CREEP. Software developers always try to add or improve features regardless of whether they are not requested by users. For example, developers may try to add authentication to the form without first completing CRUD in the database.

Alternatively, following YAGNI in the configuration life cycle enables developers to implement features that will only be relevant for the first duplicate or demo and other future features that will work as a new version or update of software developed as recommended by users.

YAGNI Principle is safe, if …

The YAGNI principle, alone, may not be secure. Software developers can set up an early algorithm on the system and then copy-paste it all over, so when it goes wrong they spend a lot of effort fixing it. With this process in coding, YAGNI is very dangerous and may not be the best idea.

But when the developers set the quality of the design, the quality of the code, and the quality of the test, YAGNI is completely safe, as every future risk is excluded by simple design rules, and it will be easy to find and fix if it goes wrong.

Benefits of YAGNI:

• With a simple answer you can say the biggest benefit of the YAGNI Principle is to avoid unnecessary development.

Main reasons to practice YAGNI

1. It saves time as you avoid writing code that may not make sense later.

2. Your current code is better because you avoid guessing which can be bad

For two main reasons for practice, they ensure:

• That deadlines are available quickly,

• Customer satisfaction due to visible and frequent changes according to their needs or details,

• The best quality of code ordered by the fact that developers focus on small tasks (those that are currently very important),

• The code can be extended more and more (allows for updated versions),

• Reduced number of adjustments required,

• That the error is easy to fix.

REFERENCE: – 

https://deviq.com/principles/yagni

From the blog CS@Worcester – THE SOLID by isaacstephencs and used with permission of the author. All other rights reserved by the author.

            Although I dedicated my previous post to introducing REST and RESTful API writing, I feel that it is important to briefly return to talking more about Docker, given how much I have come to using Docker containers for a significant part of my studies recently. In this blog, I have talked about containerization as a concept overall and not exclusive to Docker, as well as some of the things that can be done when using Docker. Namely, I discussed data management through use of volumes and mounts and container networking through port mapping. Such  features can be rather straightforward and easy to use individually and with enough practice during application development, however as development becomes more complex and demanding, having to repeatedly run commands to enable further functionality can be rather cumbersome for individual developers and overwhelming for the entire development team overall. This is not exclusive to Docker; certain utilities or commands used in development that are used especially frequently may overcomplicate the development process. Thus, often, a certain degree of automation or simplification is needed.

In my experience, I have used scriptwriting in order to speed up parts of my development process. In Docker, where it is possible to have to manage multi-container applications at once, having to manually define ports and volumes for each service individually can be extremely inconvenient for complex application development. Therefore, docker-compose YAML files  are often utilized to manage multiple services, volumes, and networks at once and in a more organized manner. Though a docker-compose file is not exactly a script file when it comes to defining container services, they can still help condense the entire process to create a service into one file. Moreover, to utilize a Docker container for application development, a docker-compose YAML file is not enough, as a Dockerfile is also needed in order to build the container’s image. However, for simplicity, I will only focus on the compose file.

Like I mentioned, a compose file is not necessarily a script file, not at least from my experience of writing script files. Despite this, there is a certain structure that needs to be followed when writing docker-compose files in order to ensure the proper functionality of the application. One resource that I found in my research regarding writing docker-compose files is an article named Introduction to Docker Compose posted on Baeldung.Com by Andrea Ligios. In this article, Ligios begins by briefly introducing the theory YAML configuration files and why using such a configuration file is preferable for development. Moreover, they proceed to illustrate the basic structure of a docker-compose file by highlighting the services, volumes, and networks to be used for the multi-container application, before they go into further detail on how to set up each of the previously mentioned sections and provide examples.

While it is important to understand how each part of a docker-compose configuration works individually, when it comes to larger-scale development and deployment, simplifying the process through use of docker-compose files can be extremely helpful.

Direct link to the resource referenced in the post: https://www.baeldung.com/ops/docker-compose

Recommended materials/resources reviewed related to :
1) https://www.tutorialspoint.com/docker/docker_compose.htm
2) https://docs.docker.com/compose/
3) https://dockerlabs.collabnix.com/beginners/difference-compose-dockerfile.html
4) https://phoenixnap.com/kb/docker-compose
5) https://runnable.com/docker/docker-compose-networking

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

This week will be continued talk on APIs and specifically I wanted to learn more about the structure of our API’s including on the differences between frontend and backend and any extra information on API’s that can be included. I have chosen a website that goes over what exactly these are and gives a good amount of information that could be useful later down in our careers.

In summary, frontend and backend are two very popular terms in web development. The term frontend is usually used for the part of the website that the user directly interacts with like the GUI’s. This is also called the “client side” of the application and use languages that should sound familiar to you such as HTML, CSS, and JavaScript with JavaScript being the most popular language of them all. This is because of several advantages such as flexibility, speed, and extended functionality although it does have some disadvantages in areas such as with debugging. Now if the frontend is what the user interacts with, the the backend should be everything that is kept out of sight from the user such as work with the databases, the scripting, and the API itself while making sure it can connect to the frontend. The languages used include python, PHP, and java all being widely used. The work on the frontend and backend has also become quite specialized over the years in which it is usual for one person to either work with just the frontend or just the backend and people who work on both are called full stack developers.

This resource has given me insight on the work we are doing with the API’s and with the work we are doing on the backend. The work that we are doing with the databases and the API’s is an entirely different area from the frontend that we haven’t even touched yet. The areas that have to be learned are numerous that require different sets of skills and talents to work in. It makes me wonder on whether we will get to work with the frontend in this class or in a future class. The I should prepare myself a bit more if one would want to become a full stack web developer seeing the needed skills in both ends. Although I haven’t done much work on any frontend material so I would have to wait to see on what the experience is like when working on the frontend on deciding if I should focus on one or another in the future.

Source:https://www.interviewbit.com/blog/difference-between-frontend-and-backend/

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

Resource Link: https://www.digitalocean.com/community/conceptual_articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design#single-responsibility-principle

For this blog post, I wanted to delve into what the SOLID principles are and how they apply to object oriented programming. SOLID is an acronym for the 5 object oriented design principles. They are the single-responsibility principle, the open-closed principle, the Liskov substitution principle, the interface segregation principle, and the dependency inversion principle. The reason these principles are important, and why they’re important to use is that they help to maintain good coding practices and help to avoid code smells. This is essential in large projects, as code smells and bad design could increase development time, make refactoring harder, and make development harder for teams if other team members couldn’t understand the code.

The first principle of SOLID is the Single-Responsibility Principle. It states that a class should have only one reason to change, and that it should have only one job. This means that a class should only have code related to its function, and not extraneous code that should be elsewhere that’s unrelated to the class’s intended purpose. This helps to keep classes simple and easy to understand. If a class contained logic unrelated to its purpose, then it would make the intended purpose of the class confusing.

The second principle of SOLID is the Open-Closed Principle. It states that a class should be open for extension but closed for modification. This means that a class should be designed in such a way that if a modification to that class is needed, it can instead be extended by a different class, and then that class could be modified while maintain the functionality of the original class. The also helps the make each class have its own specific purpose. If instead of creating a new class, a single class was modified every time a modification was needed, then the class would get messy very fast, making it hard to read and hard to understand its functionality.

Next, the Liskov Substitution principle states that every subclass that extends another class should be substitutable for the parent class. This means that for example, if there was a shape class, and then a square class extended the shape class, then the square class should be able to be used in place of the shape class.

Then, the Interface Segregation Principle states that classes shouldn’t be forced to use an interface which has functionality that it has no use for. This means that if an interface has some functionality that doesn’t apply to everything, then a class shouldn’t use that interface if it won’t be using that functionality. Instead, interfaces should be very broad, making them applicable for many different purposes.

Finally, the Dependency Inversion Principle states that functionality should depend upon abstractions, not concrete methods. This means that if you have a class that must perform some functionality, and it shouldn’t depend on an exact implementation, then the class must be design in such a way that it applies to all implementations, based off abstractions.

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