I learned about agile methodologies in one of my classes in Worcester State. At first I was confused and didn’t make sense to me but then after I read some more and started practicing with my classmates I saw the benefits of it. As Alistair Cockburn says: “Process and technology are a second-order effect on the outcome of a project. The first-order effect is the people.”

We cannot manage teams of programmers as if they were systems made up of components driven by a process. To use Alistair Cockburn’s phrase, people are not “plug-replaceable programming units.” If our projects are to succeed, we are going to have to build collaborative and self-organizing teams.

Those companies that encourage the formation of such teams will have a huge competitive advantage over those that hold the view that a software development organization is nothing more than a pile of twisty little people all alike. A gelled software team is the most powerful software development force there is.

Over the past 25 to 30 years agile innovation methods have greatly increased success rates in software development, improved quality and speed to market, and boosted the motivation and productivity of IT teams. From what I remember from my class is that we always played roles to feel that real work environment.

An agile software development process always starts by defining the users and documenting a vision statement on a scope of problems, opportunities, and values to be addressed. The product owner captures this vision and works with a multidisciplinary team (or teams) to deliver on this vision. Here are the roles in that process.

User

Agile processes always begin with the user or customer in mind. 

Product owner

The agile development process itself begins with someone who is required to be the voice of the customer, including any internal stakeholders. That person distills all the insights, ideas, and feedback to create a product vision.

Software development team

In agile, the development team and its members’ responsibilities differ from those in traditional software development.

There are different agile methodologies but I would say my favorite is scrum. It focuses on a delivery cadence called a sprint and meeting structures that include the following:

Planning — where sprint priorities are identified

Commitment — where the team reviews a list or backlog of user stories and decides how much work can be done in the sprint’s duration 

Daily standup meetings — so teams can communicate updates on their development status and strategies)

I learned a lot about methodologies online though a web that our professor enabled for us. Unfortunately I don’t remember the name but if you go online and search there are a lot of good websites who will give you a good explanation of how it works. One of webs that I like to read about it is the infowrold https://www.infoworld.com/article/3237508/what-is-agile-methodology-modern-software-development-explained.html?page=2 that gives you a good explanation on how these methodologies works.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

I decided that I wanted to talk a little more for the design patterns. This week I will present you another type. Decorator Design Pattern. Decorator design pattern is used to add additional features or behaviors to a particular instance of a class, while not modifying the other instances of same class.  It is a structural pattern, which provides a wrapper to the existing class. The reason why this pattern is in structural design patterns is because they show us how to glue different pieces of a system together in a flexible and extensible fashion. These patterns help us guarantee that when one of the parts changes, the entire application structure does not need to change.

What is the intent of this pattern? In software engineering, decorator design pattern is used to add additional features or behaviors to a particular instance of a class, while not modifying the other instances of same class. The intent of the this pattern is to provide a flexible alternative to sub-classing for extending functionality. This pattern is very important to understand because once you know the techniques of decorating, you’ll be able to give your (or someone else’s) objects new responsibilities without making any code changes to the underlying classes. You can attach new responsibility to an object dynamically. This is exactly the intended use of the decorator pattern. Per the Gang of Four – “Attach additional responsibilities to an object dynamically”.

When to use this pattern? Decorator Design Pattern has several requirement indicators to suggest that it is potential solution e.g.

1. We have an object that requires the extension.
2. Several objects that support the extension by “decoration”. Usually, those objects share a common interface, traits, or superclass, and sometimes, additional, intermediate super-classes .
3. The decorated object (class or prototype instantiation), and the decorator objects have one or several common features. In order to ensure that functionality, the decorated object & the decorators have a common interface, traits, or class inheritance.

What are the benefit and disadvantages?

·  Sometimes we want to add responsibilities to individual objects, not to an entire class. Decorators provide a flexible alternative to subclassing for extending functionality.

·  Avoids feature-laden classes high up in the hierarchy.

·  A decorator and its component aren’t identical.

·  Lots of little objects.

There are a lot of examples and reading that you can do for this design. I would suggest you https://howtodoinjava.com/design-patterns/structural/decorator-design-pattern/ . This is a very good website where it gives details what the Decorator Pattern is and it gives you an example to understand it better. Also https://dzone.com/articles/decorator-design-pattern-in-java . What I like about this website is that it has all the important part in points. Touch only the important part without going to much in details for a beginner.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Last week I gave you a small introduction in design pattern and explained their benefits in codes. Today I want to talk about one of this design patterns. The Factory Pattern. The reason why I choose this pattern is because I had to use it in one of my projects in java. The Simple Factory is not actually a Design Pattern; it is more of a programming idiom. But it is commonly used, so we will give it a Headfirst Pattern Honorable Mention. Just because Simple Factory is not a REAL pattern does not mean we should not check out how it is put together.

So, what is a simple factory pattern? The Factory Method Pattern defines an interface for creating an object but let us subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. As with every factory, the Factory Method Pattern gives us a way to encapsulate the instantiations of concrete types. As in the official definition, you will often hear developers say that the Factory Method lets subclasses decide which class to instantiate. They say “decide” not because the pattern allows subclasses themselves to decide at runtime, but because the creator class is written without knowledge of the actual products that will be created, which is decided purely by the choice of the subclass that is used.

When to use the Factory Design Pattern in Java?

Static Factory methods are common in frameworks where library code needs to create objects of types which may be sub classed by applications using the framework.        

Some or all concrete products can be created in multiple ways, or we want to leave open the option that in the future there may be new ways to create the concrete product.

Factory method is used when Products do not need to know how they are created.

We can use factory pattern where we have to create an object of any one of sub-classes depending on the data provided

There are a lot of examples about the Factory Design online. A lot of website gives a good explanation. I decided to choose the Headfirst Design Patterns by Elisabeth Robson; Kathy Sierra; Bert Bates; Eric Freeman. The chapter four shows talk about this pattern and shows a very good explanation and an example also. Another website that it helped me to understand it better was javarevisited. Again, it explains it with details and examples how it works.

https://javarevisited.blogspot.com/2011/12/factory-design-pattern-java-example.html#:~:text=Factory%20design%20pattern%20is%20used,just%20change%20in%20one%20class.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

This week I would like to talk about the design patterns. I would like to give a little intro to design pattern. As you have probably experienced by now, writing correct computer programs can sometimes be quite a challenge. Design patterns are not language specific either. Good design patterns are implementable in most programming languages, depending on the capabilities of the language of course. They also speed up the development process by providing tested and proven development paradigms.

Effective software design requires considering issues that may not become visible until later in the implementation process. Reusing design patterns helps to prevent subtle issues that can cause major problems later. It also improves code readability for programmers and architects familiar with the patterns. In addition, patterns allow developers to communicate using well-known, well understood names for software interactions.

Correctly using a design pattern is very important. Implement it in the wrong way and it can create more problems than it solves.

In my CS-343 class we worked a little with design patterns and how they work. It is uncommon to introduce design patterns and not explain who the Gang of Four are. The Gang of Four are the authors of the book, “Design Patterns: Elements of Reusable Object-Oriented Software”: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. The Gang of four design patterns are divided into 3 fundamental groups:

Creational Patterns provide ways to instantiate single objects or groups of related objects.

Structural Patterns provide a manner to define relationships between classes or objects.

Behavioral Patterns define manners of communication between classes and objects.

My favorite book about design principles is “Head First Design Patterns” by Kathy Sierra; Elisabeth Robson; Bert Bates; Eric Freeman. It is one the best for the introduction to this topic. I suggest the first chapter which gives you an understanding of the design patterns. In this chapter, you will learn why (and how) you can exploit the wisdom and lessons learned by other developers who have been down the same design problem road and survived the trip. Before we are done, we will look at the use and benefits of design patterns, look at some key OO design principles, and walk through an example of how one pattern works. The best way to use patterns is to load your brain with them and then recognize places in your designs and existing applications where you can apply them. Instead of code reuse, with patterns you get experience reuse.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

In the second week of my blog I will continue to talk about the Design Principles. These are the first steps that each of us learn when we are introduced with the world of programming. The first week I talked about the importance of OOC and how to get out of a bad OOC case. Today I want to talk about SOLID. Computer science and their acronyms, never ending.

What does Solid stands for? Probably you all know but I will explain it anyway. S.O.L.I.D is an acronym that represents five principles of object-oriented programming and code design theorized by Robert C. Martin also known as Uncle Bob. 

[S]ingle Responsibility Principle
[O]pen/Closed Principle
[L]iskov Substitution Principle
[I]nterface Segregation Principle
[D]ependency Inversion Principle

The goal of the principles is to make it easier to develop, maintain, and scale. They also make it easy to recognize and avoid code smells as well as improving the refactorability of your code.

The reason why I choose this topic is that I like everything that makes my life easier. And these principles have helped me a lot in my programming experience. I used to do a lot of repetition in my code, so these principles helped me understand how to code better. Remember “Do not repeat yourself”.  SOLID it makes your software easier to implement and prevents unexpected side-effects of future changes.

I researched and read a lot about Solid principles, to understand the concept and how to apply it. There are tons of examples, books, websites that are nice, help you with anything that is unclear. Stackify and Medium are two of my favorites in this topic. They show the importance of SOLID and apply it in code examples. Stackify it is more detailed, shows what a future developer should keep in mind, tips and tricks that you might you use it.

Simply learning and knowing these principles will not in itself make a person a better programmer. To truly be able to understand them you must apply them. If you cannot do that in the code base you have now, then work through practice problems applying them there. As you use them you will see why they are important and where they may not be the best choice. This is something that comes with time because it takes many experiences to get a full picture or how they can be applied. Whether you are just starting your career and learning the best ways to write code or have been at it for decades there is much to learn from just applying simple principles to the way you code.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

I would like to start my blog with a concept that is known for all computer scientists around the world. OOP or the long-term Object-Oriented Programming.  The OOP has been around since 1980, but unlike trendy fashions and video game characters, this programming model is still going strong after these many years.

When I was first introduced to OOP, I felt like I was never going to learn it. But like wise people say, practice makes you perfect. Most of the courses in colleges requires a good understanding of the OOP. In the CS-343 course we have to perform object-­oriented design and programming with a high level of proficiency so OOP will be a key in our projects that we are going to develop. You cannot develop software for mobile unless you understand the object-oriented approach. The same goes for serious web development, given the popularity of OOP languages like Python, PHP and Ruby.

You have decided to learn object-oriented programming, but you don’t know where to start. Object-oriented programming has so many concepts and features. The whole thing can feel overwhelming at times. It is easy to make mistakes when you construct a program using OOP. So, what to do When everything goes to hell? Duplicate and rethink.

Abstractions are tricky. When used properly, they can help you maintain your code over time. However, a wrong abstraction can add a lot of unnecessary complexity to the project and trap you in an even worse maintenance hell.

So how to avoid the wrong abstraction? How to recognize when an existing abstraction isn’t right for us anymore? And what can we do about it at this point?

When I made that mistake and I was looking for any information how to fix it, I found a good blog that gives you good directions on what to do next. Object Oriented programming requires thinking about the structure of the program and planning at the beginning of coding. Looking at how to break up the requirements into simple, reusable classes that can be used to blueprint instances of objects. Overall, implementing OOP allows for better data structures and reusability, saving time in the long run.

I have attached the link for you to read and have a better understanding. It is easy to get lost in coding, but the important part is that you still can get out of it. I hope this blog helps a little with your programming problems and make your life easier.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.