DEV Community: Katherine Mykhailyk

Exploring the Need for Creational (Factory) Design Patterns

Katherine Mykhailyk — Wed, 17 May 2023 20:54:11 +0000

I have a strong affinity for design patterns as they provide elegant solutions to common architectural design challenges.

The definitive resource for design patterns is the Gang of Four book, that builds their general classification around the conceptual motivations of the patterns taking into account the specific problems they tackle:

Behavioural patterns focus on managing variations in behaviour within a system. They provide solutions for scenarios where different objects or components need to exhibit different behaviours.

For example, suppose you have an application that involves different payment methods, each of which has its own specific behaviour, including authentication, transaction processing, and receipt generation. In this case, one of the behavioural patterns can be employed.

Structural patterns provide guidelines on how to construct larger structures by organising objects and classes in a manner that ensures flexibility and efficiency.

For example, you have a legacy system that uses a monolithic architecture, where different components are tightly coupled together. Now, you want to introduce a new feature without disrupting the existing system. In this case, you can apply the Adapter structural pattern, which allows you to adapt the new feature to the existing system without modifying its core components.

Creational (sometimes, I hear them referred to as Factory patterns or simply Factories) serve a key role in object creation, although their significance goes beyond that.

Factories are objects designed to produce other objects.

In OOP languages, when the code responsible for using objects is also burdened with their instantiation (which is frequently the case), complexity can arise. Such code becomes responsible for keeping track of multiple aspects, such as which objects to create, which construction parameters are necessary, how to utilise the object after construction, and sometimes even managing object pools. This lack of separation reduces cohesion, which is undesirable, and can lead developers to prematurely choose an instantiation scheme before fully understanding the objects that need to be instantiated.

Factory patterns address these issues by promoting object cohesion, decoupling, and testability. They contribute to maintaining a flexible design and facilitate problem decomposition into smaller, more manageable components.

When it comes to object creation and management, here is a good rule to follow: and object should either make and / or manage other objects or it should use other objects but it should never do the both.

This division of responsibilities simplifies the tasks for both groups. Moreover, by streamlining the creation and management of objects, it's possible to enhance their management without significantly increasing effort.

I would recommend following these steps:

Step 1 - Define the objects and their relations.

Step 2 - Implement factories for object instantiation and management: write factories that handle the creation of the appropriate objects based on specific situations, as well as managing existing objects if they are shared among different components.

As you can see, the code generated in Step 1 focuses solely on the behaviour and functionality of the objects without concerning itself with the instantiation details. Similarly, the code in Step 2 concentrates on the instantiation and management of objects, without being burdened by the complexities of their interactions.

Separating these concerns leads to increased cohesion in the code. If these aspects were not separated, you would end up with code that deals with both the functionality of the objects and the rules governing their creation and management in different circumstances. By isolating these concerns, each class can focus on either functionality or instantiation, resulting in more modular and cohesive code.

It's worth mentioning, that this approach provides us with enhanced encapsulation, a highly valued characteristic. It ensures complete separation between the implementing classes and the client code that utilises them. Consequently, I can introduce or remove implementations without requiring any modifications to the client code itself.

Moreover, this approach greatly facilitates the testing process. The behaviour of the client code remains consistent regardless of the specific set of implementations employed. It is sufficient to test each component individually, as the system will function in a consistent manner regardless of their combinations.

Other benefits include easier and more cost-effective maintenance in the future. They align with the open-closed principle, allowing for the addition of new code rather than modifying existing code when changes are necessary. This approach effectively reduces the overall maintenance costs.

Please consider this piece of code and think, what could be improved:

At first glance, the provided code appears fine, and I have encountered similar implementations in the past. However, there are a few key aspects that require attention:

1) OrderManager class creates instance of Order object (line #14) directly by itself. It would be okay, if only you won't need to do all other stuff:

Generating the OrderId (line #15) and handling the associated logic internally (line #25)
Setting the CustomerName (line #16)
Setting the TotalAmount (line #17)

2) The OrderManager class also performs order management operations:

Saving the order to the database (line #20) and keeping the logic within itself (line #31)
Sending a confirmation email (line #21) and managing the process internally (line #36)

As you can observe, this class is responsible for multiple tasks, and it would greatly benefit from being divided into smaller, more understandable components. Since we are discussing creational design patterns, we can utilise one of them to eliminate lines #15-#17 and #25-#29. This modification would align the class more closely with the Single Responsibility Principle. I plan to cover this subject in our future articles.

One more thing, that you need to know is that there is a range of creational patterns exist:

Factory Method
Abstract Factory
Singleton
Prototype
Builder

I will begin with the Factory Method, which is remarkably straightforward to comprehend and implement.

In conclusion, the use of creational patterns, provides significant benefits in software development. By separating the object creation process from object usage, factories enable more flexible, modular, and maintainable code. They promote encapsulation, allowing for easy addition or removal of implementations without impacting the client code. Additionally, creational patterns adhere to the open-closed principle, reducing maintenance costs by enabling the addition of new code rather than modifying existing code. Overall, incorporating factories and creational patterns in design and development leads to improved code organisation, testability, and future scalability.

Other examples of this patterns: DbProviderFactory Class

JavaScript Metaprogramming: Part 1 - Unleashing the Potential of the Reflect API

Katherine Mykhailyk — Tue, 16 May 2023 05:53:25 +0000

Metaprogramming is a programming technique (or approach) which involves treating programs as data, enabling them to be read, generated, analysed, transformed, and even modified dynamically. It empowers developers to interact with and manipulate other programs programmatically.

Essentially, this concept conveys that metaprogramming enables us to create sophisticated programs with the ability to generate new programs or comprehend their own structure. However, what does this actually mean in practice?

To begin, it is essential to grasp that metaprogramming encompasses both language capabilities and approaches to writing logic in a metaprogramming style.

I would like to start my explanation with the aspect that emphasises metaprogramming as the program's self-awareness and the ability to manipulate itself at runtime.

Reflection stands out as a significant tool in this context. It's the concept within metaprogramming, which draws parallels to seeing our own reflection in a mirror. In a similar manner, reflection allows us to gain insights into aspects of a program that would otherwise remain hidden. It provides the capability to introspect and access different elements of a program, such as properties, methods, and structure. This ability to observe and modify a program's internal workings facilitates advanced program analysis and dynamic adaptations.

At its core, reflection allows an object to introspect its own properties and methods, enabling self-examination and potential modification. In the case of JavaScript, this capability empowers objects to dynamically explore their own structure, accessing and manipulating properties and methods as required.

In JavaScript, the Reflect API serves as the implementation of Reflection. It is introduced as a set of static methods provided by the global Reflect object, which consists of a collection of related functions rather than properties. It provides static methods that allow for the invocation of interceptable internal methods of JavaScript objects. These functions, introduced in ES6, establish an API for introspecting and manipulating objects and their properties.

The Reflect object serves as a convenient namespace that encapsulates a set of functions replicating the behaviour of core language syntax and duplicating the functionality of existing Object functions. While the Reflect functions themselves do not introduce new features, they consolidate these features into a unified and convenient API.

Example 1 - Accessing properties:

// Example object
const myObject = {
  name: 'John',
  age: 25
};

// Using Reflect to get a property value
const name = Reflect.get(myObject, 'name');

// Without using Reflect to get a property value
const name = myObject['name']; // or myObject.name 

console.log(name); // Output: "John"

Example 2 - Set properties:

const myObject = {
  name: 'John',
  age: 25
};

// Using Reflect.set() to update a property value
Reflect.set(myObject, 'age', 30);

// Without using Reflect to set a property value
myObject['age'] = 30; // or myObject.age = 30

// Result
console.log(myObject.age); // Output: 30

Example 3 - Invoke a target function with a specified this value and a set of arguments:

const obj = {
  name: 'John',
  greet() {
    console.log(`Hello, ${this.name}!`);
  }
};

const greetFunc = obj.greet;
const args = [];

// Using Reflect.apply() to invoke the greet method on the obj object
Reflect.apply(greetFunc, obj, args);

// Without using Reflect
greetFunc.apply(obj, args); 

// Output: "Hello, John!"

By the way, it's worth noting that mentioning Reflect.apply() during interviews when discussing binding context can be quite impressive. It showcases a deeper understanding of JavaScript's function invocation mechanisms, going beyond just mentioning call, apply, and bind.

Example 4 - Retrieve an array of all property keys, including both enumerable and non-enumerable:

const obj = {
  name: 'John',
  age: 25
}

Object.defineProperty(obj, 'address', {
  value: '123 Main St',
  enumerable: false
});

const symbolKey = Symbol('id');
Object.defineProperty(obj, symbolKey, {
  value: 123,
  enumerable: false
});

// Using Reflect.ownKeys()
const keys = Reflect.ownKeys(obj);

// Without Reflect
const keys = Object.getOwnPropertyNames(obj).concat(Object.getOwnPropertySymbols(obj));

// Result
console.log(keys); // Output: ['name', 'age', 'address', Symbol(id)]

It's important to note that Reflect is not intended to be used as a constructor. It cannot be invoked with the new operator or treated as a regular function. All properties and methods of the Reflect object are static, mirroring the behaviour of the Math object.

Example 5 - Let's also create our own implementation of the Reflect object to gain a better understanding of its functionality:

class Reflect {

  static get(target, propertyKey, receiver) {
    if (typeof target !== 'object' || target === null) {
      throw new TypeError('Reflect.get called on non-object');
    }
    return target[propertyKey];
  }

  static set(target, propertyKey, value, receiver) {
    if (typeof target !== 'object' || target === null) {
      throw new TypeError('Reflect.set called on non-object');
    }
    target[propertyKey] = value;
    return true;
  }

  static apply(target, thisArg, args) {
    if (typeof target !== 'function') {
      throw new TypeError('Reflect.apply called on non-function');
    }
    return target.apply(thisArg, args);
  }

  static ownKeys(target) {
    if (typeof target !== 'object' || target === null) {
      throw new TypeError('Reflect.ownKeys called on non-object');
    }
    return Object.getOwnPropertyNames(target).concat(Object.getOwnPropertySymbols(target));
  }

  // Additional Reflect methods can be implemented here
}

// Example usage:
const myObject = {
  name: "John",
  age: 25
};

console.log(Reflect.get(myObject, "name")); // Output: "John"
console.log(Reflect.set(myObject, "age", 30)); // Output: 30

So, Reflect API in JavaScript provides a powerful set of methods that enable metaprogramming capabilities. By leveraging reflection, developers can gain insight into program structures, dynamically modify behaviour, and achieve advanced program analysis. The Reflect API offers a convenient and unified approach to interact with objects, mimicking core language syntax and providing an efficient way to access and manipulate properties, invoke functions, and work with object metadata. By harnessing the capabilities of the Reflect API, developers can take their programming to the next level, empowering them to build more flexible, dynamic, and intelligent applications.

You can find the comprehensive list of available methods of the Reflect object here.

Understanding SQL Joins: A Beginner's Guide

Katherine Mykhailyk — Sun, 30 Apr 2023 23:42:32 +0000

There are three main types of joins in SQL: INNER, OUTER, and CROSS joins. Each join involves two tables, referred to as the LEFT and RIGHT tables, respectively.

By combining these concepts, you can create different types of joins such as inner, left outer, right outer, and full outer joins.

It's crucial to keep in mind that when you use the JOIN keyword without specifying the type of join, it will be treated as an INNER JOIN by default. To perform an outer join, you need to specify whether it's a RIGHT, LEFT, or FULL join. Moreover, it's worth noting that the INNER and OUTER keywords are optional with INNER being the default.

For presentational purposes I created two DB tables (I use SQL Server and Azure Data Studio visual tool):

PaymentSystems Table:

Customers Table:

Let's examine how the various types of joins can impact the outcome of a query using the example of these two tables.

Inner type of joins

1. INNER JOIN (or simply JOIN)

The diagram for INNER JOIN, depicts the overlapping area between two circles, which represents the rows in each table that have a common value. When this type of join is used, only the rows that have matching values in both tables will be selected and returned. In other words, INNER JOIN returns only the data that is common to both tables.

Let’s assume the following code:

SELECT * FROM dbo.PaymentSystems S
INNER JOIN dbo.Customers C
ON S.Id = C.PaymentSystemId

Running the above code will produce the following result:

As shown in the result, the INNER JOIN did not include certain rows from the Customers table in the final output, as those rows did not have an Id that matched the condition specified in the ON clause: S.Id = C.PaymentSystemId.

Outer type of joins

2. LEFT OUTER JOIN (or simply LEFT JOIN)

It retrieves all the rows from the left table and any matching rows from the right table. If there are no matching rows in the right table, NULL values are used instead.

Let's execute this query and observe the result:

SELECT * FROM dbo.Customers C
LEFT JOIN dbo.PaymentSystems S
ON C.PaymentSystemId = S.Id

As shown in the result, the LEFT OUTER JOIN retrieved all the rows from the Customers table, but only those rows from the PaymentSystems table that matched the condition specified in the ON clause: C.PaymentSystemId = S.Id. In cases where there was no match found, the missing values were replaced with NULL.

3. RIGHT OUTER JOIN (or simply RIGHT JOIN)

It returns all the rows from the right table and matching rows from the left table. If there are no matches in the left table, NULL values are returned. It's similar to LEFT OUTER JOIN, but the tables are reversed, with the right table being the primary table.

SELECT * FROM dbo.PaymentSystems S
RIGHT JOIN dbo.Customers C
ON S.Id = C.PaymentSystemId

The outcome of the query will be as follows:

The Customers table has been included completely, but PaymentSystems table is only included where it met the condition S.Id = C.PaymentSystemId.

4. FULL OUTER JOIN (or simply FULL JOIN)

It retrieves all rows from both tables, and if there are any unmatched rows, it fills in the columns with NULL values.

SELECT * FROM dbo.PaymentSystems S
FULL OUTER JOIN dbo.Customers C
ON S.Id = C.PaymentSystemId

As you can see, this code returns a result set that includes all the rows from both the PaymentSystems and Customers tables, regardless of whether there is a matching row in the other table. The result set will have NULL values in any columns where there is no match between the two tables.

Cartesian type of joins

5. CROSS JOIN

A CROSS JOIN produces a result set that combines each row from the first table with each row from the second table, resulting in a Cartesian product of the two tables. It should be used with caution as it can generate a large number of rows and cause performance issues. Cross joins are appropriate when no other join can be used, and when the WHERE clause can limit the result set to a manageable size. Although a cross join doesn't make sense for my particular tables, we can still use it to illustrate how it works:

SELECT TOP 14 * FROM  dbo.Customers C
CROSS JOIN dbo.PaymentSystems S

The resulting output displays all the possible combinations of rows from the Customers and PaymentSystems tables, as generated by the cross join operation. As you can see, I have limited the output by using the TOP 14 clause in order to restrict the number of rows returned by the query.

No obvious category

6. SELF JOIN

There is no specific keyword in SQL for a self join. Self join doesn't belong to any of the traditional join categories such as inner, outer, left, right, or full outer join. It's a type of a instruction where a table is joined with itself. In other words, a self join is a regular join, but the table is used as both the left and right table in the join. This can be useful when you have a table that contains a hierarchy or a relationship between rows, and you need to join rows within the same table based on that hierarchy or relationship.

A self join is utilised when a table needs to reference data within itself, for example: employees, multi-level marketing, machine parts, comment tree where each comment references the next one, and so on.

The following example demonstrates a simple implementation of a self join with the help of LEFT JOIN:

SELECT *
FROM dbo.Employees E
LEFT JOIN dbo.Employees MA
ON MA.EmployeeId = E.ManagerId

Alternatively, you can also use the following query with a WHERE clause:

Select * FROM dbo.Employees E, dbo.Employees MA
WHERE MA.EmployeeId = E.ManagerId

Another way to obtain the same result is by using an INNER JOIN :

SELECT * FROM dbo.Employees E
INNER JOIN dbo.Employees MA
ON MA.EmployeeId = E.ManagerId

The three queries shown above are examples of self-joins where the Employees table is joined with itself.

In conclusion, SQL joins provide a powerful way to combine data from multiple tables. Understanding the differences between joins is essential for building complex queries and retrieving the data you need. By mastering SQL joins, you can unlock the full potential of your database and gain deeper insights into your data.

C# Extension Methods: the basics you need to know

Katherine Mykhailyk — Wed, 26 Apr 2023 03:04:28 +0000

Extension methods are a powerful feature (introduced in C# 3.0) in object-oriented programming languages that allow a method to be added to an object, including a class or a type, after it has been compiled.

When creating extension methods, you would typically use static methods within static classes and the “this” modifier. Although extension methods are static, they can be invoked as if they were instance methods. However, extension methods cannot be defined for static classes, and they cannot override methods of a class or interface. If an extension method has the same name and signature as a class or interface method, it will not be called. Additionally, at compile time, instance methods defined in the type itself will always have a higher priority than extension methods.

Extension methods are actually widely used in C# development and is often leveraged indirectly through popular libraries like LINQ, which uses extension methods to add query functionality to existing types such as System.Collections.IEnumerable and System.Collections.Generic.IEnumerable. This allows developers to query collections with great ease and flexibility. For example:



List<int> numbers = new List<int> { 1, 2, 3, 4, 5 };
var result = numbers.Where(n => n % 2 == 0).Select(n => n * n);

The following logic is performed behind the scenes (simplified code of Where and Select LINQ methods):



public static class MyLinqExtensions
{
    public static IEnumerable<T> Where<T>(this IEnumerable<T> source, Func<T, bool> predicate)
    {
        foreach (T item in source)
        {
            if (predicate(item))
            {
                yield return item;
            }
        }
    }

    public static IEnumerable<TResult> Select<TSource, TResult>(this IEnumerable<TSource> source, Func<TSource, TResult> selector)
    {
        foreach (TSource item in source)
        {
            yield return selector(item);
        }
    }
}

Extension methods provide a more convenient way of writing code, leading to improved readability and discoverability. For example, consider the following two code snippets:



// Case 1: We don't have extension methods and need to use static methods

var total = Enumerable.Aggregate(
                Enumerable.Distinct(
                    Enumerable.Select(
                        Enumerable.Where(myList, x => x.price > 5)
                       , x.price)
                    )
               , (total, next) => total + next);

// Case 2: We have extension methods

var total = myList.Where(x => x.price > 5)
                  .Select(x => x.price)
                  .Distinct()
                  .Aggregate((total, next) => total + next);

The following extension methods use cases are among the most popular:

1) The most significant benefit of using extension methods is that they provide a convenient means of adding extra features to the .Net Framework or third-party classes that cannot be modified or don’t have access to the source code. For example:



// The UserManager class that is part of the 
// Microsoft.AspNetCore.Identity library has been extended
// by adding a new method called FindByPhoneNumberAsync

public static class UserManagerExtension
{
    public static async Task<AppUser?> FindByPhoneNumberAsync(this UserManager<AppUser> userManager, string? phoneNumber)
    {
        return await userManager.Users.FirstOrDefaultAsync(u => u.PhoneNumber == phoneNumber);
    }
}

// Example of use

var user = await _userManager.FindByPhoneNumberAsync(phoneNumber);

2) Extending the functionalities on a DTO. For example:



// Our DTO

public class TransferDTO
{
  public int Id {get;set;}
  public string Name {get;set;}
}

// Extension method

public static class TransferDTOExtension 
{
    public static int GetName(this TransferDTO transfer) 
    {
        return transfer.Name;
    }
}

// Example of use

var transfer = new TransferDTO();
Console.WriteLine(transfer.GetName()); // Extra functionality!

3) Collection Functionality. This is basically what we have seen higher. They allow the functionality to be called from any collection such as an System.Array or System.Collections.Generic.List that implements System.Collections.Generic.IEnumerable on that type.

In conclusion, extension methods in C# provide a powerful and flexible way to extend existing types without modifying their source code. They enable developers to add new functionality to types, including third-party types or types that are part of the .NET framework. Extension methods also make code more readable by allowing developers to write fluent and concise code. However, it is important to use extension methods judiciously and avoid creating ambiguous or confusing code. When used appropriately, extension methods can be a valuable tool for improving code quality and maintainability in C#.