Author Archives: xmurati

Code Smells

A smell of code has to do with being a superficial indicator which in most cases has corresponded to a much bigger and deeper problem in the system. This term was first coined by Kent Beck. This character became famous even after the appearance he had with Martin Fowler’s book. Code winds are very subjective winds and which differ only on the basis of language, developers but also methodology that have other factors.

What are the some frequently seen smells?

Bloaters: In its entirety this includes code, but also classes and methods. This smell has become great over time, making the accumulation of functionality but also the creep of features it has.

For example: it is about long methods, for classes of gods but also for long lists of parameters.

Dispensable: This smell refers to code that is otherwise known as dead code, which can not be called or executed. These are unnecessary blocks of code, as these codes do not offer benefits, but make it possible to increase technical debt.

Psrsh: It is a duplicate code, it deals with the refactoring of objects, as well as makes the generalization premature.

Connections: This smell means the moment when a code must be independent and end up bound together due to lack of access control, as well as excessive delegation.

Ex: We have code tracking, as well as the use of private and internal members.

*Developers in most cases are trained to see what are the logical errors that have been accidentally inserted into their code. Errors of this type will range from the most forgotten cases of different edges, which are not treated to the point where there are logical errors which make possible the crash that can have systems from most. Code winds are some signals that our code needs to be refactored in order to improve the alignment, support but also readability.

The presence of code scents is a very serious topic, despite the names being perhaps a bit ridiculous. Anyone who has little experience in software development is aware that code winds also have the property of seriously slowing down software release.

With the use of code wind detection tools, but also making it possible to submit codes in short as well as controlled refactoring sessions, we have the opportunity to go beyond the initial impact of code winds. In this way we have the right to discover the deepest problem that lies within the software. Code winds can in many cases be vital to make it possible to discover when to refactor and what refactoring techniques to use.

There is a part that is very essential in the way the software is developed as well as to find the flavors of the code. Another role is to dig into the root causes but also to fix them through what is called refactoring.

Most common codes are:

  • Bloaters
  • Object-Orientation Abusers

  • Change Preventers

  • Dispensables

  • Couplers

The ones that are found the most by details are :

Long method
Duplicate Code
Inheritance method
Data Clumps
Middle Man
Primitive types
Divergent Code
Shotgun Surgery
Feature EnvyPrimitive Obsession
Lazy Class
Type Embedded in Name
Uncommunicative Name
Dead Code

References:

https://levelup.gitconnected.com/10-programming-code-smells-that-affect-your-codebase-e66104e0341d

https://www.infoq.com/news/2016/09/refactoring-code-smells/

https://8thlight.com/blog/georgina-mcfadyen/2017/01/19/common-code-smells.html

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

Design Patterns

  • Creational
  • Structural
  • Behavioral

In what is called software engineering, a design model describes a solution that is determined by the problems found in the design of the software. It makes it possible to represent practices that are best and which evolve over a longer period of time through gaming but also testing that is done by software experienced developers.

1)Creational Design Patterns are patterns that explain how an object can be created. These models make it possible to reduce the complexity but also the instability that they have by making the creation of objects in a more controlled way.

In most cases, the new operator is often considered harmful as it distributes objects throughout the application. This can become even more challenging over time, in order to change the implementation, for the sole reason that the classes have a very close relationship with each other.

Creative design models address this issue here by making the client disconnect from the initialization process that is currently underway.

1. Singleton – Makes it possible to provide a single instance of an object that exists during an application.

2. Factory Method – It is possible to create different objects of different classes that are related, but without making specifications in the exact object that can be created.

3. Abstract Factory – Makes possible the creation of families that are dependent but also connected together.

4. Builder – Has the ability to build complex objects using one approach after another, or in other words step by step.

2) Structural design patterns– These are models that have to do with what is called the organization of objects and classes that are different, but also that change the formation of structures from the largest, but at the same time to make it possible to provide the functionality of ri.

Explain how the structural design model is used-

At the moment when we have two interfaces that have an incompatibility with each other but also that want to have a relationship between them by having adaptation with each other, it is also called as the adapter design model. This model, also known as the adapter model, converts an interface of a class to an interface or another class that the client expects. In other words, what is called adaptability somehow allows the classes to work together, which at another point due to incompatibility could not have happened otherwise.

3)Behavioral design patterns represent the responsibility but also the interaction of different objects.

By generalizing these design models, the interaction that takes place through objects should be in such a way that they too can talk smoothly to each other.

Translated into simpler words, in order to avoid dependencies but also difficult coding, the application and the client at the same time should be connected as loosely as possible.

Behavioral design models have 12 types usable for this model:

1. Enterprise chain model

2.Command model

3.Performer model

4.Iterator Models

5.Broker model

6.The model of memories

7.Observer model

8.The state model

9.Strategy Model

10.Template model

11.Visitor model

12.Object Null

References:

https://www.gofpatterns.com/design-patterns/module2/three-types-design-patterns.php

https://howtodoinjava.com/design-patterns/creational/

https://howtodoinjava.com/design-patterns/structural/

https://www.ifourtechnolab.com/blog/a-complete-guide-on-behavioral-design-pattern-and-chain-of-responsibility-pattern-in-java

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

“Encapsulate what varies.”

“Find what changes and encapsulate it.”-  This is a different approach from the redesign approach. In simpler words, we are able to consider what we want to change without redesigning, rather than thinking about who might force a change in design.

This principle of encapsulating makes it possible for nothing to affect the rest of your code.

Encapsulation can be found everywhere!

When we turn the steering wheel and the car wheels rotate, we see that there is a variety of moving parts that work together to transform our action into the final effect that the car wheels have, but all these details are encapsulated by us. But this example can never be confused with abstraction. Because they are simply similar and can be true. Just like in the real world but also in the world of Software we have various examples of encapsulation but also of Abstraction that interact together. These are two concepts that are different but that are also related to each other, and that in most cases work together.

The moment we include anything that has the potential for change, we are dealing with time savings. In general, encapsulation has to do with objects which in a way make possible the merging of attributes but also of the methods they have, for the sole reason that they do not have an impact on other objects they have. But it works differently in cases when we are dealing with the design of a program which is mostly object-oriented. This is because the requirements that may most likely change in the future, need to be more concise for one reason only: that the change is likely to occur at the time it is requested. The volume of the code is changed by the summary which minimizes the volume of the code, and which may need to be changed in the future.

When we see that this principle is particularly relevant to the code which changes very often, we are dealing with the benefit of encapsulating the code, regardless of the frequency of the code change. Like what:

The code that is encapsulated has the possibility of reasoning to be separate from the code

  • To prevent conjugation summarized with the implementation of the code which is encapsulated, such as when summarizing when the interaction of a downstream system. At this point this replacement is even easier.
  • -Other developers can understand from the encapsulation constants, that they are sufficiently connected and have control security in case they have changed or even the way it has changed.

References:

https://genderi.org/encapsulate-what-varies.html

https://alexkondov.com/encapsulate-what-varies/

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

 GRASP

General Responsibility Assignment Software Patterns – is composed of various instructions which make the definition of classes but also of objects in the design that are oriented by different objects. GRASP has 9 different principles and models, each of which presents as a start the problems and solutions they have:

Information expert – What is the basic principle from which the responsibility for objects is determined?

                                    -We have to assign a class responsibility that has

                                     necessary information in order to fulfill it

In this example, the customer class carries references to all the messages that customers have. In this way, taking responsibility from the candidate to do the calculation of the total value of the various orders, comes gradually naturally. For this reason, this is one of the main principles, but also for the fact that if we do not have all the data we need, at that time we would not be able to meet the requirements and determine the responsibility.

Creator – Who creates object A?

                We need to define class B in order to create object A (or e

                in other words, B contains the data of A, records them, uses them closely, and with

                most importantly I have the initializing data that A) has.

This model tries to help in order to be able to decide which class should be responsible for creating a new example of a certain class. In principle, creating an object as a whole is one of the most important processes, and it is important to have a principle for deciding who should have the opportunity to create a possible class example.

Controller – Who is the first object to be used beyond the UI layer which receives and

                      coordinates the control that a system operation performs?

                    – The responsibility of an object which represents: “system” e

                     generally represents the “root object” as well as a usage scenario from

                     where the operation of the system is possible.

The high-level design of our system creates dependence on the implementation of this principle. However, we always have to define the object in order to process the business transactions that we have.

Low Merger – How do we enable the impact of change? How to make it possible to

                             do we support low dependency but also increased reuse?

                          -To determine the responsibility that belongs to us so that the union (Which in this case is

                            Unnecessary, to remain the same Low.

The relation is basically about the mass, how one element relates to another. In this way, the higher the union is, the greater the dependence that one element has on another.

High cohesion – The way we keep objects focused, manageable,

                                 understandable, but also as a side role to support the low link?

                                -We have to assign a certain responsibility, for the sole reason that cohesion

                                 to remain high again.

The definition of cohesion is that it has the role of a measure of how tightly all the responsibilities that the element has can be related. In general, classes that have low cohesion, have within the data that are unrelated, or that have unrelated behaviors.

Indirect – The place from where responsibility should be assigned to avoid merging in order

                   direct between two or even more things.

                 – A responsibility must be assigned to an object that is intermediate, from where

                  mediation of services or other components is done, for the sole reason that they

                  not have a direct connection.

At this moment, the position of the mediator model enters the game. Another role that Indirection has is that it supports low fusion, but at the same time reduces all readability and reasoning to be used for the whole system as a whole.

Polymorphism – How are alternatives that are based on their type treated?

                         -At the moment when the alternatives or even the behaviors which are

                          interrelated    change

                       based on the type of class, determine the responsibility we should have for

                       behavior towards the species from where the behavior also changes, using in this way

                       also polymorphic operations.

Polymorphism is a term that indicates the basic design principle that is object-oriented. This principle has very strong links with what is otherwise called the Strategy Model.

Clean fabrication – Which object should have more responsibility, when we need it to violate the

                                  High   Cohesion but also the Low League. But in addition to these, the solutions

                                  which are offered by other principles and which are not considered appropriate?

                                -We need to define a group that is responsible for a certain class

                                  artificial or even a suitable class that can not do the representation of

                                  a concept that has the domain of the problem.

In some cases, it is very difficult to understand the moment where we have to place the responsibility. This is the main reason why there is a Domain Service concept in Domain-driven Design. The logic behind these services is not directly related to the entities that are separate.

Protected variations – How to design subsystems, objects, and systems in

                                              these elements, not to be influenced by other elements?

                                             -How to identify points that have variations or

                                              even the instability that is predicted, must

                                              define the responsibility we need to create an interface that is with

                                              stable.

This principle is the most important and is indirectly related to the other principles that GRASP has. But we must always be ready for the demands that are constantly changing, as programmers that we are.

Refereces:

https://titanwolf.org/Network/Articles/Article?AID=c96c4845-28c5-46c8-ae48-

https://yamm.finance/wiki/GRASP_(Object_Oriented_Design).html

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

          YAGNI

YAGNI has two different meanings: You Ain’t Gonna Need It or in other words, You Aren’t Gonna Need It. YAGNI has appeared differently as the main principle that has been used in the extreme program. This principle stated in a different interpretation is:

“Always implement things when you really need them, never when you just anticipate that you might need them.”

The reasons why this principle exists are various. As a start, it makes it possible to maximize the amount of unnecessary work that remains unfinished. This is a very good way to improve the productivity of the developer, but also the simplicity of the product. One thing to keep in mind, these features are very expensive, both for development and maintenance. It is also important for users, so that they have the opportunity to learn, but also to navigate around. But those features seemingly are not necessary, in fact, they are a very large source of waste.

 Yagni Advantages

Here are some reasons why YAGNI should be used:

-Save time in the same amount of money (saving time and money is equal), and this is the main factor but also the most important

-gives you the opportunity to use a much easier code, good but most importantly “thoughtless”

-makes available the deadlines

-ensures that the client is happy with the very frequent but also obvious changes that are in line with the specifications

-code has better quality, notice this from the fact that many developers focus on just one even smaller task they may be doing (tasks which are more important at the moment)

last but not least, that code has the property to be more extensible.

Yagni design principle

We will not need this program much. Extreme Programming (XP) says that a programmer should not add the functionality he has until it is considered necessary. So YAGNI translates differently – You will not need it. Extreme software is generally used in the Agile software development process. According to this principle, we should not add any functionality until the moment when it is deemed necessary, in other words, to write the code which we need in the current situation.

YAGNI in Agile/XP

Many people may remember that this principle is called “stupid” and that the requirements it has should be prepared even better. But those people who work in the slightly more advanced methodology or, as they say, “agile” should take into account the possible changes that the client’s requirements may have. For this reason, the subsequent tasks in most cases depend on the results of the current status of this project, but that over time this result may change.

If at the same time we develop many features that “maybe needed” as a start, we lose not only the time but also the effort that has been needed to complete it. There are also cases when we waste the time we spend refactoring or fixing them as these interventions may be redundant.

In general, developers should never rely on different assumptions because they are likely to prove that they are not worthy and capable of the effort and time a programmer needs.

Refereces:

https://www.plutora.com/blog/you-aint-gonna-need-it-yagni

https://jasonmccreary.me/articles/practicing-yagni/

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

DRY (Drying principle)

Do not repeat yourself

This term was coined in 1999 by Dave Thomas and Andy Hunt in the book they created The Programmatic Programmer. The definition they made was like “Every piece of knowledge or logic must have a single, clear representation within a system.” DRY in the use of software engineering, is the principle that has to do with reducing duplication in code, having as main source or “fragment” – that has reusable code in the moments when we need it.

If we are writing a module or even a code, we need to keep in mind the design principles of today and use them wisely. We have to make them our habit, so that we do not have to remember them every time. This will save development time, but also make our software software strong, and in this way we will have it even easier to maintain and expand this software.

DRY Violations- “We enjoy pressing” (or in other words, “Losing everyone ‘s time.”). This phrase means that we can write the same code or logic over and over again.

How to get dry- Less code is good: This saves effort and time for it, it is much easier to maintain, but above all, it reduces the chances of any defect.

Kiss: Keep It Simple, Stupid-KISS Principle is an indicator that shows you how to keep the code clear and simple, to make it as easy to understand as possible. However in general programming languages should be as understandable as possible by humans, because computers the only way they can understand is only with 0 and 1. Therefore we must keep the coding as simple as possible but also direct. We should keep our methods no matter how small, but these methods should not always contain more than 40-50 lines.

KISS Violations – It is very likely that we have all experienced a situation where we need to work on a project and have found a code written incorrectly. This makes us wonder why we wrote these unnecessary lines.

How to reach KISS- To avoid violations of the KISS principle, we should try to write a code as simple as possible and transform it into our code.

The benefit of KISS- If we have some functionalities written by a developer if it is written in irregular code, and at the same time we want another developer to make the modification in the same code, then first they have to understand the code.

If we have not yet discovered a productivity system, most of these may sound familiar.  The only difference here is that we have a process approach with a laser focus that is in unnecessary duplication.

Some of the tasks that rarely come up are:

-Increase tasks that are similar but unplanned, such as handling a customer complaint.

-Let’s not forget the annual tasks (or even the monthly ones, in cases when they are followed for a single week): such as billing, inspections, audits, greater maintenance.

– Ask others about their routine tasks. This helps us to fill the gaps.

References

https://henriquesd.medium.com/dry-kiss-yagni-principles-1ce09d9c601f

https://ardalis.com/don%E2%80%99t-repeat-yourself/

https://blog.softhints.com/programming-principles-and-best-practices-dry-kiss/#kisskeepitshortandsimple

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

SOLID

Solid principles are divided into five different parts of programming and a design that addresses objects. Robert Cecil Martin or also known as “Uncle Bob”, was the one who introduced this type of anchoring or principle also called SOLID. This is one of the principles, where each letter represents a method which is represented by three letters, and which basically has a principle. When we work with software, which has a poorly managed management mode, we are dealing with a code that can become rigid, a fragile mode, and this makes this software difficult to use. When the code is rigid we are dealing with a code that is difficult to modify, it is difficult to change the way it currently works, or even more difficult to add any other features.

·  Single Responsibility Principle (SRP)

·  Open-Closed Principle (OCP)

·  Liskov Substitution Principle (LSP)

·  Interface Segregation Principle (ISP)

·  Dependency Inversion Principle (DIP)

Single Responsibility Prinnciple

The Principle of Sole Responsibility (SRP) at its core for a class not to change, there should be no more than one reason. And this results in every different class having to work with one method. However, each member in the class is related has a direct connection to what is called the primary function of the class. Unlike the example where a class has multiple responsibilities within it, in this method the possibility that it needs to be changed increases even more. And from all of this, we have an increased risk of presenting flaws whenever a class starts to modify. But by focusing only on one responsibility, this risk is even more limited.

Open-Closed Principle (OCP)

The Open / Closed Principle (OCP) means that classes for extension should generally be open, but for modification they should be closed. “Open for extension” aims to open the creation of our classrooms in order to add new functionality, while new requirements are generated. “Closed for modification” means not modifying a class after we have developed it, as it should never be modified, except to correct defects. These two parts of the principle seem to be contradictory to each other. However, if we structure our classes and their dependencies well, we can add functionality without having to reduce the existing source code.

Liskov Substitution Principle (LSP)

The Liskov Substitution Principle (LSP) can be formed in a variety of ways. LSP is applicable to inheritance hierarchies. He emphasizes that we need to create as many of our classes as possible, so that client dependencies are replaced with subclasses without the client being aware of this change. For this reason, all subclasses are based on functioning in the same way as the basic classes they have. Subclasses do not have to apply only the methods and properties that the class bases have so that they are the true type of behavior. But they must also be consistent with her behavior. And this requires compliance with some basic rules.

Interface Segregation Principle (ISP)

There are some classes that have public interfaces and that are not cohesive. The principle of interface sharing (ISP) explains that clients are not tasked with dependent on interfaces that are not usable by them.

– The first rule is the existence of contradictions between the parameters of the methods that the base class has and that of the compliance in the subclasses.

– The other rule is for preconditions and unconditional. The other LSP considers invariant.

-The other rule is to limit history.

– The last rule of LSP states that a subclass should not throw exceptions that are not thrown from the other base class.

Dependency Inversion Principle (DIP)

(DIP) indicates that high-level modules should not be dependent on low-level modules. Both should be dependent on abstraction. These abstractions should not depend on the details, but these should depend on the abstractions. The idea is that high and low-level modules have, categorizes classes hierarchically. High-level classes or modules are those that deal with much larger groups of their functionality.

References

https://www.jrebel.com/blog/solid-principles-in-java

https://www.geeksforgeeks.org/solid-principle-in-programming-understand-with-real-life-examples/

https://www.educative.io/edpresso/what-are-the-solid-principles-in-java

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

Design Principles

The four fundamental ideas of Object-Oriented Programming are Encapsulation, Abstraction, Inheritance, and Polymorphism. OOP allows programmers to approach software development as if they were dealing with real-world objects. People in real life have the skills and expertise to do a variety of tasks. Objects in OOP feature fields for storing knowledge, state, and data, as well as the ability to perform a variety of operations. The basic terms we need to know before getting more into OOP are Object, Class, Method, and Instance.

Object – A class’s instance

Class – A model that describes an object’s functionality

Method – Changing the state of a class applies to all other instances of the class

Instance – Is similar to an object. The blueprint used to build the product is an instance of the class.

Let’s move on to the four fundamental ideas of Object-Oriented Programming:

Encapsulation

When objects are encapsulated inside a class, they each have a private state. Other objects can’t directly access this state, but they can only use a list of public functions to get at it. These functions allow the object to control its own state and no other class has access to it unless access is granted. As a developer, you must use the given ways to communicate with the object. The state of a class invoked by a method created a bond between the private state and public methods.

Abstraction

Abstraction is a continuation of encapsulation. To show just relevant information to an object, data is selected from a large pool. Abstraction is the technique used to get, remove, or select user data from a bigger pool. In the case of abstraction, you can use the same info gathered for a different app to power other programs with little or no coding changes.

Inheritance

Inheritance is the process through which one object gains access to all of the properties of another without actually changing anything about the original. For instance, a child gets personality qualities from both of their parents. Reusability is a significant benefit of inheritance. The existing class’s fields and methods can be reused. Inheritance might be single, multiple, multilevel, hierarchical and hybrid, in Java.

Polymorphism

Polymorphism makes it possible to utilize a class in the same way as its parent, which eliminates the possibility of confusion. As a result, each child sub-class retains its own functions and methods. Each of the child sub-classes should have unique variations.

In a conclusion, Object-Oriented Programming refers to programming languages that use objects. The goal is to implement real-world concepts, keep data and the functions that operate on it separate such that no other part of the code may access it, except for that function.

References:

https://info.keylimeinteractive.com/the-four-pillars-of-object-oriented-programming

https://www.geeksforgeeks.org/understanding-encapsulation-inheritance-polymorphism-abstraction-in-oops/

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

Introductory Blog CS-343

Hello everybody!

My name is Xhuljana Murati. I study Computer Science in Worcester State University.  CS-343 is one of the classes that I am registered for this semester. This blog post is an introduction to this class. CS-343 will be another challenge to accomplish and the blog that I just created would be a good opportunity to share my knowledge professionally. I hope you will enjoy my blog posts weekly!

Thank you for reading!

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.