Skip to main content
added 11 characters in body
Source Link
João Farias
  • 11k
  • 2
  • 20
  • 40

Reflection API, has all utilities like ExcelReader Utility class, DB connector classes, Reporting utility, logging classes etc

For starters, based on what you described, this is not a framework. This is a library with multiple responsibilities.

The easiest way to know the difference is:

Your code calls libraries. Frameworks call your code.

As an exampleexamples of frameworks, you can take Ruby on Rails or Spring and analysisanalyse the lifetime of their objects.

For more details, you can check this article or deep dive in the C2 wiki.

the underlying framework which is quite complex for me

One thing that you can do is to break down this fat library into single responsibility libraries, then you can understand the components that serve to fulfill a single mission.

For each responsibility:

  • Create a new library;
  • Import this new library into the fat library;
  • Extract the components related to the responsibility into the new library, running the tests on both sides to check for regression;
  • In the end, refactor the tests on the fat library side so it won't depend directly on the new library.

Reflection API, has all utilities like ExcelReader Utility class, DB connector classes, Reporting utility, logging classes etc

For starters, based on what you described, this is not a framework. This is a library with multiple responsibilities.

The easiest way to know the difference is:

Your code calls libraries. Frameworks call your code.

As an example, you can take Ruby on Rails or Spring and analysis the lifetime of their objects.

For more details, you can check this article or deep dive in the C2 wiki.

the underlying framework which is quite complex for me

One thing that you can do is to break down this fat library into single responsibility libraries, then you can understand the components that serve to fulfill a single mission.

For each responsibility:

  • Create a new library;
  • Import this new library into the fat library;
  • Extract the components related to the responsibility into the new library, running the tests on both sides to check for regression;
  • In the end, refactor the tests on the fat library side so it won't depend directly on the new library.

Reflection API, has all utilities like ExcelReader Utility class, DB connector classes, Reporting utility, logging classes etc

For starters, based on what you described, this is not a framework. This is a library with multiple responsibilities.

The easiest way to know the difference is:

Your code calls libraries. Frameworks call your code.

As examples of frameworks, you can take Ruby on Rails or Spring and analyse the lifetime of their objects.

For more details, you can check this article or deep dive in the C2 wiki.

the underlying framework which is quite complex for me

One thing that you can do is to break down this fat library into single responsibility libraries, then you can understand the components that serve to fulfill a single mission.

For each responsibility:

  • Create a new library;
  • Import this new library into the fat library;
  • Extract the components related to the responsibility into the new library, running the tests on both sides to check for regression;
  • In the end, refactor the tests on the fat library side so it won't depend directly on the new library.
Source Link
João Farias
  • 11k
  • 2
  • 20
  • 40

Reflection API, has all utilities like ExcelReader Utility class, DB connector classes, Reporting utility, logging classes etc

For starters, based on what you described, this is not a framework. This is a library with multiple responsibilities.

The easiest way to know the difference is:

Your code calls libraries. Frameworks call your code.

As an example, you can take Ruby on Rails or Spring and analysis the lifetime of their objects.

For more details, you can check this article or deep dive in the C2 wiki.

the underlying framework which is quite complex for me

One thing that you can do is to break down this fat library into single responsibility libraries, then you can understand the components that serve to fulfill a single mission.

For each responsibility:

  • Create a new library;
  • Import this new library into the fat library;
  • Extract the components related to the responsibility into the new library, running the tests on both sides to check for regression;
  • In the end, refactor the tests on the fat library side so it won't depend directly on the new library.