Category Archives: CS@Worcester Blog

Digg Deeper Learning Pattern

This pattern is a great idea for a beginner such as me. It offers a way to complement the lack of knowledge that comes with the lack of experience. It should be used carefully because of the ease of wanting to just reinforce the skills you are already good at. Knowing a little on a lot of subjects will not help getting things done and knowing a lot in just one subject will get you just as far. The secret as I see it is to have a good toolbox and know how to at least hold each tool. As you need to pick up each of these tools you learn about them more in depth but not too much to hinder your progress. As you shuffle through this toolbox picking up things you need and not obsessing on one tool you build a hierarchy of depth in the knowledge of things you need most. We will handle the same tool more than once and every time we do, we should dig just a little more.

The author presents a more all in version of the dig deeper which I think is the philosophical normalized world idea. It would be nice if we had the luxury of tunnel vision and look for the PhD dissertation of the original design algorithm for every tool we use, but it is also the easiest way to fall into a deadlock. I find that in school it is very hard to get in depth knowledge on every subject as much as I want. Time and time again I see myself compromising and kicking the can down the road, because I do want in-depth knowledge in some subjects, but there are time sensitive co-responsibilities that need immediate attention. Although, as I said earlier, some of these tools that I want to understand better come up again and again over the semesters and I do indeed gain a little more ground on understanding them.

I believe the author is right when he says that we need to learn to dive into ever lower levels of understanding.  By lower I mean from specific to general and by specific, I mean not only the surface high level function you need. The author does throw a little caution which I also mentioned earlier. The risk of becoming what some call a one trick pony.  The balance is really hard to define, and it is very personal. I don’t have my own balance definition yet, but I hope that with time this too will come.

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

The White Belt

As I started looking into the list of patterns, “The White Belt” hit the nail on my head as the problem illustrated in this pattern looks like what I’m currently facing, or have been facing against for a while I would say. I think the first time I found myself in a “wrong place” with programming was in a Hackathon back in spring 2021.

The situation was my teammates were all having Java background so we decided to create an Android Application using Android Studio so everyone can write code in Java. However, things began to feel strange as we started, Java here is not what we were familiar with actually, the coding concept is different as we have to understand what we need and find out the right documentation according to the problem, something that we were not supposed to do initially, but it’s impossible to change the project now as it might collapse team spirit. Therefore, I had to wear the “black belt” and learned the hard way to figure out how to implement features in a short period of time. The repository that we were working on that time if you want to check: OPCredit

This project damaged my thinking more than it improved my knowledge as I feared that my personal development has stalled because I can’t write Java while Java is my first programming language. According to the solution and action indicated in the book, I ameliorated the situation by learning basic JavaScript, I was impressed by how less complex the code is compared to Java while doing the same thing. Then, as I proceed to learn its frameworks, and from ES5 to ES6, in my view, this is one perfect instance where you shouldn’t suppose to already know what will be implemented, but to be neonate and accept the concept.

By the time this post is online, I was learning CI/CD and Docker, something that is not related to my first language as I will have to understand what is happening in the Command Line Interface to give the container the correct solution. This time, I will wear “The White Belt” even more carefully to not only learn what I have to learn but also to practice how to use this belt for future progression.

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

White Belt Pattern

For my first Apprenticeship pattern, I chose to write about “The White Belt”. In this pattern, you’ve created a good understanding of the first language you’ve learned, and others have recognized and have often called you for help when they have problems. Even though this is great, you feel that you’re have a little difficulty trying to learn new materials and find that things are slowing down and you’re not learning as quick as before and fear you have hit a peak of your personal development.

When I first read about this pattern, I did in fact felt like I hit a plateau in obtaining new skills and in self learning. I could relate to the description of the white belt very much. I really loved how they quoted Yoda from Star Wars with “You must unlearn what you have learned”, regarding approaching new situations. Another quote that I liked while reading about this pattern is “In order to climb, you must leave the sure footing, letting go of what you already do well and possibly slipping downward into a ravine. If you never let go of what you already do well, you may continue to make steady progress, but you’ll never get off the plateau” by Jerry Weinberg. Both quotes are quite similar and suggest that in order to learn and make a steady progress, you must leave your comfort zone and tackle the problem with a different method. This helped me come to the realization that I’m constantly trying to incorporate another programming language that I was comfortable with the new language I’m trying to learn. Which results in me having a hard time learning new things for both languages. After I took a step back to analyze what was going on, I went back and tackle each language in a separate way. I then was able to learn and get past the plateau I was on.

There isn’t anything I would disagree with what was said for this pattern. Everything that was said was great and would really help others who have also hit a plateau. The story of Dave was a quick and simple way of relating the quotes I said earlier and applying them. Overall reading about this pattern has helped me come to the realization that there are some problems that should be handled differently, for instance when learning a new problem or a technique of how to do something.

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

Reaction to Apprenticeship Patterns

My initial reaction after reading Apprenticeship Patterns by David H. Hoover and Adewale Oshineye, was very eye opening for me. It made me rethink about my future and goals and what I want to be able to achieve. The story of Dave which displayed his experience was very helpful. Apprenticeship Pattern is a book I would definitely recommend to people who are getting into software development. It’s a book that gets your mind ready to go on a journey from an apprenticeship to journeyman status. While reading the introductions from Chapter 2 thru 6, it really inspired and motivated me to do my own learning other than what I am currently doing in my university. I would agree with the reading however, I do believe some people may disagree depending on their mindset and goals. In the book it takes about how some people become the “better than average developer”. This isn’t what I want to achieve, instead I would like to someday develop an application that is useful or that can help communities and to be able to do that, I need a mindset of a master. A master is a step above a journey man who completed their apprenticeship. The mindset of a master is to constantly get better at their craft and they’re always learning new things.  The chapter that I believe that is most relevant to me right now would be in chapter three. In the intro of chapter three, we follow Dave who decides to branch out and connect with other developers through a website. After this he met a few hackers that inspired him because were experts in their craft but were still learning new things at a fast rate. This made him realized he just barely scratched the surface of being a great software developer. After a few interactions and observations, he captured the learning process and threw himself into anything he can get his hands on. This last part is what I can really relate to right now. I am trying to learn as much as I can before the end of my semester and to work on a few projects that will help be harness my skills together.

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

Apprenticeship Patterns Relfection

The author aligns software development with a craft rather than strictly a science. A craft is an art or skill where tools, methods, and knowledge are required to be an expert. He gives various examples that show how craftsmanship is needed to create well-designed software, and I agree with this point of view. I believe software development should be approached as more of a craft, especially when it comes to how programming is learned through apprenticeship.

Rather than traditional school-based education, programmers would learn from experienced people. Not from books and assignments where one’s ability is determined from the accumulation of grades.

There should not be the target for an education system that creates a class of ‘programmers’ who know general knowledge about computer science and the basics of programming, but an environment that helps each student master their software development craft. We shouldn’t focus only on code but should focus on improving how we approach programming.

An area where I see this approach put to practice is in coding boot camps. These are usually fast-paced programming courses that last less than one year. The classes are taught by individuals who have deep knowledge of the field and years of experience as professional programmers. Instructors have worked in corporations directly with the tools and technologies they teach their students. It is also an environment where learning programming is more hands-on. Creating projects is the center point of a coding bootcamp. The curriculum is much more comprehensive on practical knowledge than what is taught in the traditional college environment; relating to what students will be working on in a future job. I find less use in the existing 4-year college degree model of education. I am not the only one, as the rates of college enrollment are dropping year after year. Ultimately, a college degree acts as a form of accreditation, but the value of a degree is losing value with time.

To me, the most relevant chapter was 4, “Accurate Self-Assessment.” It is common to learn just enough to accomplish what is needed to be done and not extend your knowledge any further. Learning something new takes effort, and it is much easier to remain complacent with the technologies we already understand. The author also suggests comparing yourself to whom you were yesterday and avoiding comparisons to someone else. The benefit of this methodology is you identify your growth over time. And once you realize the distance between who you were yesterday and who you are today, changes can be made to reach levels of improvement of where you want to be.

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

Breakable Toy Pattern

The breakable toy pattern is something I practice often without realizing it was considered a pattern for good learning practice. I must say at times I find it to be a double edge sword. Sometimes I look for things beyond my abilities and end up stuck, depressed, and put it in the back burner, but I end up unpacking them later [because I’m stubborn] sometimes over multiple iterations and when I finally get them working the achievement felt is increased in the same order. I think this pattern probably pairs well with other patterns such as confront your own ignorance maybe I’ll write about this one next. Anyway, I want to talk about how he describes the pattern in his own way.

The author makes a good point in the first few paragraphs that the point of a breakable toy was to be able to work on things you don’t usually work on. This description enforces that this pattern helps you learn without side effects on the systems you work on that are not toys. I believe that he makes this distinction to allow for a daring approach, one that would allow you to try something just to see what happens. This allows for a much deeper understanding of any problem. It is like testing to find boundaries, critical systems may not allow such playful adventures but even these critical systems had to be prototyped at some point and someone stress tested the system so you could have a safe playpen.

I know stress testing is an idea that could be consider a little alien to the breakable toy pattern, but I believe it is part of it. When building these breakable toys, we use tools and frame works that we sometimes stress to the end of their abilities. Then we find better tools and frameworks or learn to better use and manage the ones we have.

To conclude the breakable toy pattern allows for growth not only skill-wise but also mentally when we exercise self-control. It allows us to practice focus and confront anxiety. To build the skill set of building skill sets.       

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

Design patterns

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn’t a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. 

The main goal of using design patterns is to make the code easy to maintain, hence reducing the maintainability costs. Design patterns are split into several groups: creational patterns, structural patterns, and behavioral patterns.

Creational Patterns:

Creational patterns are used to create objects for a suitable class that serves as a solution for a problem. Generally when instances of several different classes are available. They are particularly useful when you are taking advantage of polymorphism and need to choose between different classes at runtime rather than compile time. Creational patterns support the creation of objects in a system. Creational patterns allow objects to be created in a system without having to identify a specific class type in the code, so you do not have to write large, complex code to instantiate an object. It does this by having the subclass of the class create the objects. However, this can limit the type or number of objects that can be created within a system.

There are 6 types of creational design patterns.

  1. Factory Method Pattern
  2. Abstract Factory Pattern
  3. Singleton Pattern
  4. Prototype Pattern
  5. Builder Pattern
  6. Object Pool Pattern

Structural Patterns: 

Structure diagrams depict the static structure of the elements in your system. i.e., how one object relates to another. It shows the things in the system – classes, objects, packages or modules, physical nodes, components, and interfaces. Since structure diagrams represent the structure, they are used extensively in documenting the software architecture of software systems. Structural patterns form larger structures from individual parts, generally of different classes. Structural patterns vary a great deal depending on what sort of structure is being created for what purpose.

There are 7 types of structural design patterns.

  1. Adapter Pattern
  2. Bridge Pattern
  3. Composite Pattern
  4. Decorator Pattern
  5. Facade Pattern
  6. Flyweight Pattern
  7. proxy Pattern

Behavioral Patterns:

Behavioral design patterns are concerned with the interaction and responsibility of objects. In these design patterns, the interaction between the objects should be in such a way that they can easily talk to each other and still should be loosely coupled. That means the implementation and the client should be loosely coupled in order to avoid hard coding and dependencies.

There are 12 types of behavioral design patterns.

  1. Chain of Responsibility Pattern
  2. Command Pattern
  3. Interpreter Pattern
  4. Iterator Pattern
  5. Mediator Pattern
  6. Memento Pattern
  7. Observer Pattern
  8. State Pattern
  9. Strategy Pattern
  10. Template Pattern
  11. Visitor Pattern
  12. Null Object

Design Patterns – Wikipedia

Behavioral Design Patterns – Javatpoint

From the blog CS@Worcester blog – Syed Raza by syedraza089 and used with permission of the author. All other rights reserved by the author.

GRASP (General Responsibility Assignment Software Patterns)

GRASP (General Responsibility Assignment Software Patterns) is a design pattern in object-oriented software development used to assign responsibilities for different modules of code. GRASP is a set of “nine fundamental principles in object design and responsibility assignment”, first published by Craig Larman in 1997 in a book “Applying UML and Patterns”.

GRASP is occasionally coupled with other design patterns such as SOLID. Design patterns such as these help keep code simpler, more organized, more comprehensible, analyzable and reusable.

Patterns:

In object-oriented design, a pattern is a named description of a problem and solution that can be applied in new contexts; ideally, a pattern advises us on how to apply its solution in varying circumstances and considers the forces and trade-offs. Many patterns, given a specific category of problem, guide the assignment of responsibilities to objects.

This is the list of 9 GRASP patterns.

  1. Creator
  2. Information Expert
  3. Low Coupling
  4. Controller
  5. High Cohesion
  6. Indirection
  7. Polymorphism
  8. Protected Variations
  9. Pure Fabrication

Creator: 

Takes responsibility for creating certain other objects. It has information on how to create objects. It can be used to enforce the logical design of a system.

Information Expert:

The information expert pattern states that we need to assign responsibilities to the right expert.

Low coupling: 

One of the major GRASP principles is Low Coupling. Coupling is a measure of how strongly one object is connected to, has knowledge of, or depends upon other objects. 

Controller:

Controller is responsible for handling the actions of user-interfaces. The controller is the first object to receive a command from the UI.

High cohesion: 

High cohesion is an evaluative pattern that attempts to keep objects appropriately focused, manageable and understandable. High cohesion is generally used in support of low coupling.

Indirection: 

The indirection pattern supports low coupling and reuses potential between two elements by assigning the responsibility of mediation between them to an intermediate object.

Polymorphism:

According to the polymorphism principle, responsibility for defining the variation of behaviors based on type is assigned to the type for which this variation happens. This is achieved using polymorphic operations. The user of the type should use polymorphic operations instead of explicit branching based on type.

Protected variations:

A pattern that protects elements from the variations on other elements by wrapping the focus with an interface and using polymorphism to create various implementations.

Pure Fabrication: 

A class that does not represent a concept in the problem domain. This kind of class is called a “service” in domain-driven design.

GRASP (object-oriented design) – CodeDocs

GRASP (object-oriented design) – Wikipedia

GRASP Patterns – Beyond Velocity

From the blog CS@Worcester blog – Syed Raza by syedraza089 and used with permission of the author. All other rights reserved by the author.

Object-oriented programming

Object-oriented programming (OOP) is a programming paradigm based on the concept of “objects”, which can contain data and code. It is used by nearly every developer at some point in their career. OOP is the most popular programming paradigm in the field of computer science. It relies on the concept of classes and objects. It is used to structure a software program into simple, reusable pieces of code blueprints. There are many object-oriented programming languages including JavaScript, C++, Java, and Python. 

Objects:

This is the basic unit of object-oriented programming. Object can be a combination of variables, functions, and data structures, in particular in class-based variations of the paradigm it refers to a particular instance of a class. Objects can be declared several times depending on the requirements.

Classes: 

Classes are a blueprint or a set of instructions to build a specific type of object. It is also a basic concept of Object-Oriented Programming which revolves around real-life entities. Class in Java determines how an object will behave and what the object will contain. A class is used to bind data as well as methods together in a single unit.

Principles of OOP:

There are four principles of object oriented programming(OOP).

  1. Inheritance
  2. Encapsulation
  3. Abstraction
  4. Polymorphism

Inheritance:

Inheritance is a mechanism of acquiring the features and behaviors of a class by another class. Using inheritance, we can create a derived class from a base class such that it inherits the properties and methods of the parent class(base class) and can have its own additional properties and methods. The derived class is also known as the child class.

There are 6 different types of inheritance in OOP.

  1. Single inheritance
  2. Multi-level inheritance
  3. Multiple inheritance
  4. Multipath inheritance
  5. Hierarchical Inheritance
  6. Hybrid Inheritance

Encapsulation: 

Encapsulation means carrying all the important information inside an object. encapsulation is also often used to hide the internal state of an object from the outside. This process is called information hiding. The general idea of this mechanism is that If you have an attribute that is not visible from the outside of an object, and bundle it with methods that provide read or write access to it, then you can hide specific information and control access to the internal state of the object. 

In Encapsulation, Only public methods and attributes are accessible from the outside. Code is hidden in a class, only public methods are accessible by the outside developers.

Abstraction:

In Object Oriented Programming, abstraction means implementation is hidden from the user and only required functionality will be accessible or available to the user. Abstraction uses simplified high level tools to access a complex object. Abstraction is an extension of encapsulation.

Abstraction also plays an important security role by only displaying specific or selected data to users.  

Polymorphism:

The word polymorphism means having many forms. Using inheritance, objects can override shared parent behaviors, with specific child behaviors. Polymorphism allows the same method to execute different behaviors in two ways: method overriding and method overloading.

What is Object Oriented Programming? OOP Explained in Depth (educative.io)

What is object-oriented programming (OOP)? (tutorialspoint.com)

Object-oriented programming – Wikipedia

From the blog CS@Worcester blog – Syed Raza by syedraza089 and used with permission of the author. All other rights reserved by the author.

Unified Modeling Language (UML)

The Unified Modeling Language (UML) is a general-purpose, developmental, modeling language in the field of software engineering that is intended to provide a standard way to visualize the design of a system. The creation of UML was originally motivated by the desire to standardize the disparate notational systems and approaches to software design. It was developed at Rational Software in 1994–1995, with further development led by them through 1996.

UML offers a way to visualize a system’s architectural blueprints in a diagram. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems. The UML is a very important part of developing object oriented software and the software development process.

UML has many types of diagrams, which are divided into two categories. Some types represent structural information, and the rest represent general types of behavior, including a few that represent different aspects of interactions.

Class Diagram

A Class Diagram in Software engineering is a static structure that gives an overview of a software system by displaying classes, attributes, operations, and their relationships between each other. This Diagram includes the class name, attributes, and operation in separate designated compartments.

 

Structure diagrams

Structure diagrams show the static structure of the system and its parts on different abstraction and implementation levels and how they are related to each other. Since structure diagrams represent the structure, they are used extensively in documenting the software architecture of software systems. Structural Diagrams include: Component Diagrams, Object Diagrams, Class Diagrams and Deployment Diagrams.

Behavior diagrams

Behavior diagrams show the dynamic behavior of the objects in a system, which can be described as a series of changes to the system over time; They are used extensively to describe the functionality of software systems. Behavior diagrams include: Use Case Diagrams, State Diagrams, Activity Diagrams and Interaction Diagrams.

Interaction overview diagrams

The Interaction Overview Diagram focuses on the overview of the flow of control of the interactions.The Interaction Overview Diagram describes the interactions where messages and lifelines are hidden. You can link up the “real” diagrams and achieve a high degree of navigability between diagrams inside the Interaction Overview Diagram.

UML 2.0

UML 2.0 has been an industry standard focusing on model-driven application integration. UML 2.0 is capable of providing better semantics or definitions. It has also worked to improve the internal structuring. UML 2.0 adds the definition of formal and completely defined semantics. This new possibility can be utilized for the development of models and the corresponding systems can be generated from these models.

Unified Modeling Language – Wikipedia

What is Unified Modeling Language (UML)? (visual-paradigm.com)

What is UML | Unified Modeling Language

From the blog CS@Worcester blog – Syed Raza by syedraza089 and used with permission of the author. All other rights reserved by the author.