Design Patterns

Designing SocialMediaLink in OOP

Posted on by admin

Beginning of Software Design

Requirement: Design an Actor class which has personal details and social media links.

A note on design:

The current design, with direct properties for each social media link and separate methods for updating/removing each, is more rigid and might lead to more boilerplate code as the number of social media platforms increases.

This design has some potential disadvantages:

  1. Rigidity:
    • If you wanted to add support for another social media platform, you'd have to modify the Actor class, adding a new property and accompanying methods to update and remove the link. This breaks the Open/Closed Principle (OCP) of SOLID, which states that a class should be open for extension but closed for modification.
  2. Duplication:
    • The IsValidLink method is invoked in every UpdateXXXLink method. If the validation logic changes, it will be correctly applied across all methods, but the repetitive structure is a red flag that there might be a more elegant design solution.
  3. No Single Responsibility:
    • The Actor class is currently handling both the data representation of an actor and the management and validation of links. This can be seen as a violation of the Single Responsibility Principle (SRP) of SOLID. Ideally, an Actor shouldn't have to be concerned with the intricacies of URL validation.
  4. Null State Ambiguity:
    • Using null to represent the absence of a link can lead to potential null reference exceptions if not handled properly elsewhere in the code. While setting the value to null does represent the absence of a value, it requires other parts of your application to consistently check for null before using a link.
  5. Lack of History/Tracking:
    • In the current design, there's no way to keep track of changes to an actor's social media links. If link history or auditing is a requirement (either now or in the future), this design would need to be significantly refactored.
  6. Potential for Incomplete Removals:
    • If a developer forgets to call the removal method, old data might remain in the system. In the design where links were contained in a list, you could have just cleared the list or removed specific items, ensuring all links of that type were removed.
  7. Scalability Concerns:
    • As new properties or methods are added, this class will grow, making it harder to maintain. A larger class tends to be more error-prone and harder to debug.

Recommendation:

A more flexible approach would involve encapsulating the behaviour and data of social media links into their own classes (as shown in the next designs). It allows for easier additions of new link types, centralized validation logic, and a clearer separation of concerns.

Continue reading →

Node.js nut-ioc usage

Posted on by admin

nut-ioc npm package is a simple, lightweight and fast IoC Container Framework.

nut-ioc injects dependencies run-time so that developers don't need to require modules.

Developers can implement in their codes following OOP basics, principles, patterns and concepts and probably more than that 🙂

  • Separation of Concern(SoC)
  • Single Responsibility Principle(SRP)
  • Open Closed Principle
  • Dipendency Inversion(Injection) Principle(DIP)
  • Chain of Responsibility Pattern
  • Aspect Oriented Programming

you can reach github repository.

https://github.com/nodejs-projects-kenanhancer/nut-ioc

Installing nut-ioc with npm

npm i nut-ioc

Demo GitHub Repository

You can find different usages of nut-ioc framework in separate brances.

https://github.com/nodejs-projects-kenanhancer/nut-ioc-basic-demo.git

Branch list
load-dependencies-with-dependencyPath
load-dependencies-with-dependencyPath-and_dynamically
load-dependencies-with-different-loaders
load-dependencies-with-interceptors
load-dependencies-with-new-loaders-and-filters
load-dependencies-with-programatic-notation
nut-swagger-usage
Continue reading →

Node.js nut-pipe usage

Posted on by admin

nut-pipe npm package is an implementation of Chain of Responsibility Pattern. We can encapsulate or wrap every aspect of code in separate module or class or function, etc. So that, separated aspect modules would implement Single Responsibility Principle(SRP) and Seperation of Concern Principle(SoC) properly.

🙂 so if you want to implement OOP basics and principles, then you can use nut.pipe npm package.

This design provides to developer clean business logic code. They don't need to think about Error, Exception, Log handling business logic. Before their business logic code is called, pipeline is called and it means first middleware is triggered then first middleware will trigger next one, but no middleware knows about next middleware. Middleware should know about its business logic then should call next one.

I know too much words but developers want to see code 🙂 same code will be developed in different ways.

Code example v1

I wrote a greeting service with sayHello() and sayGoodbye() functions. They include all business logic in their body. This is not good approach definitely. Code duplications are everywhere 🙂 For example, every functions have try/catch, console.log('ENTRY: …'), console.log('SUCCESS: …'), console.log('ERROR: …'), etc. Notice that getFullName doesn't contain these business logics. So, we can't know whether it is called or not. If developer like me 🙂 doesn't write these kind of aspects(logging and exception handling is kind of aspect) then we never understand that that method is called in run-time.

Continue reading →

Designing OOP Step by Step

Posted on by admin

I read Head First Design Patterns book shown as below. It is pretty good reference of Design Patterns. If you want to be familiar of Design Patterns, i recommend it definitely. This post contains some examples of this book but in a different presentation. When I want to remember fundamentals of Design Patterns, this post will remind me 🙂 I hope that you will benefit from this post.

I will create a class diagram and improve it step by step.

If you don't want to read all paragraphs, you just view class diagrams and code samples step by step. But, i heavily recommend to read and think of this post 🙂

Continue reading →

C# Asynchronous Programming Patterns

Posted on by admin

There are 3 Asynchronous Programming Patterns in C#.

1- Asynchronous Programming Model (APM)
2- Event-based Asynchronous Pattern (EAP)
3- Task-based Asynchronous Pattern (TAP)

 

1- Asynchronous Programming Model (APM)

Asynchronous Programming Model using Delegates

you can reach that article from Calling synchronous methods asynchronously

2- Event-based Asynchronous Pattern (EAP)

3- Task-based Asynchronous Pattern (TAP)

Chain of Responsibility Pattern and Aspect Oriented Programming with C#.NET

Posted on by admin

Each class contains only the business logic code, while the aspects will be responsible of intercepting the code in order to inject the cross-cutting concerns.

This is first version of example code.

This is second version. You can find MethodInfo and parameter values in the aspect classes.