DEV Community

The S of SOLID in my view.

Witerlland Silva on February 07, 2024

Hi, This is my first article on this site. This is my first article at all. So, in this series of articles, I want to review SOLID with Typescript....
Read full post
Collapse
 
efpage profile image
Eckehard •

You did not mention derived classes, but the SPR is a strong argument to use them. Assume you have a range of objects or functions all doing similar things. If you write all members of the group separately, you probably need to implement the same code multiple times. If you call a subfunction, it might be hard to meet the different requirements.

If you put the code in an abstract base class, all members of the group will inherit the code but may apply modifications where necessary. Then you will only have one class that is responsible for the behavior of the whole group.

Collapse
 
dscheglov profile image
Dmytro Shchehlov • • Edited

@efpage you see, derived classes is not about SRP.

The inheritance is one of the ways to follow OCP (Open/Close Principle) and DIP (Dependency Inversion Principle). And more than -- it is not a best way to respect these principles.

Inheritance is a mechanism of sub-typing, limitted by LSP (Liskov Substitution Principle) that makes SRP not relevant to inheritance: Derived Class MUST DO the same stuff as a Base Class, but in differnet way, preserving safity of substitution.

Collapse
 
witerlland profile image
Witerlland Silva •

Oh, it's an excellent idea. This text is just my initial annotations, And I never thought so many people would reach me lol. Maybe I can write some text another time, going deeper into the topic.

Collapse
 
efpage profile image
Eckehard • • Edited

The topic is much bigger than it seems.

Many systems like the Windows GDI or the android API are build using excessive inheritance. Such systems can contain hundreds of classes, and management would be nearly impossible without a clear structure. Methods introduced are always introduced as early as possible to assure, they are only implemented once.

Here is an image of the android view hierarchy.

Collapse
 
dscheglov profile image
Dmytro Shchehlov •

@witerlland actually inheritance is not too much good idea to understand or present SRP.
See my comment: dev.to/dscheglov/comment/2cob9

This text is just my initial annotations, And I never thought so many people would reach me lol

Look, all developers are reflecting SOLID. To write such texts is your way. And it is a really good approach to do that.

Just try to understand comments and discuss it if there is something unclear.

Collapse
 
dscheglov profile image
Dmytro Shchehlov • • Edited

@witerlland SRP (Single Responsibility Principle) is a rather controversial story )

It seems your example is not too much suitable )

On the start you have code that emits a single report that contains three sub-reports, it is not exactly you have after the refactoring: just three reports

I can guess you mean something like that:

class ReportService {
  constructor(apiBaseUrl: string) { /* -- snip -- */ }
  getSalesReport(): Promise<SalesReport> { /* -- snip -- */ }
  getSellersReport(): Promise<SellersReport> { /* -- snip -- */ }
  getBillingReport(): Promise<BillingReport> { /* -- snip -- */ }

  private sendApiRequest(endpointPath: string): Promise<unknown> { /* -- snip -- */ }
}
Enter fullscreen mode Exit fullscreen mode

If so, we cannot decide to split or not to split just considering the naming, and guessing that "Actors" are different. But yes, in some cases we have to split this class, in some other cases -- we can keep it as a single one.

So, both works. To make final decision we need to deep dive to the problem details.
However, in general, programs live longer then organization charts ;)

Regarding the SRP.

One of the most important criteria for SRP is "Concern Separation": The class that builds a report should not warry about how to send data.

The method sendApiRequest must be extracted to the separate class ApiClient,
and correspondent instance must be injected into the ReportService class or classes:

interface IReportService<Report, Params = {}> {
  getReport(params: Params): Promise<Report>;
}

interface IApiClient {
  sendApiRequest(pathname: string): Promise<unknown>
}

type SalesReport = {
  kind: 'Sales';
  // -- snip --
};

class SalesReportService implements IReportService<SalesReport> {
  constructor(
    private readonly apiClient: IApiClient,
  ) {}

  async getReport() {
    const data = await this.apiClient.sendApiRequest("/sales");
    return data as SalesReport;
  }
}

// -- snip --
Enter fullscreen mode Exit fullscreen mode

See more detailed example on TS Playground

One small suggestion: if you want to follow SOLID -- think in interfaces, not in classes

Collapse
 
witerlland profile image
Witerlland Silva •

Oh, it's an excellent idea. And a better way to explain the concept. Thanks for correcting me and giving me examples of it, because it's just an initial annotation and I want to go deeper into the theme.