November 2018 – A Fumbling in Progress

Refactoring – Other Design Principles – JobMan

Posted on November 22, 2018 by Robert Worrall

Encapsulate what changes

A factory pattern could be used to encapsulates job creation. The factory could be for each specific interface -e.g SpawnableJobs. The structure now takes the following form.

Don’t Repeat Yourself (DRY)

After applying the other principles – I cannot see any duplication of functionality at this time.

Don’t look for things. Ask for things. (Dependency Injection)

This is already achieved by the implantation of the factory method for creating Jobs. It is also done via injecting the numbering scheme at database creation.

Favor Composition over Inheritance

Composition has already been used for the implementation of SpawnableJob.

Program to the Interface not to the Implementation & Delegation Principles

This was covered when jobman was reviewed for Single Responsibility Prinicple and Interface Segregation Principle.

Conclusions

This was a useful exercise and will allow some of the work I did on JobMan to be reused in other projects. I will move the GUI code to a separate repository which will be placed on the Sourceforge page and the projects page of this website.

Refactoring – Dependency Inversion Principle (DIP) Applied To JobMan

Posted on November 19, 2018 by Robert Worrall

Already in the previous posts I have moved the Database to an interface where JobDatabase interacts with abstract base classes of Job and SpawnableJob. Meaning that neither Databases are dependent of details of implementions of Job and SpawnableJob and conversely they are not dependent the JobDatabase class as this is declared through interfaces. So the resulting structure is now:

I also renamed the currently implemented JobDatabase to JobDataBaseDB4OEmbedded.

Refactoring – Interface Segregation Principle (ISP) Applied To JobMan

Posted on November 16, 2018November 16, 2018 by Robert Worrall

This could be applied to the Database class. In particular the replication storage may not be required of later a multi user interface may be required instead of an embedded database. There is also a benefit to extracting the database out to an interface as it will allow other databases to be developed. e.g mysql.

Refactoring – Liskov Substitution Principle (LSP) Applied to JobMan

Posted on November 16, 2018November 16, 2018 by Robert Worrall

In the previous article I introduced 2 base classes Job and SpawnableJob. Their purpose was to forfill the closed open principle. However, as a side effect when all jobs are returned from the database spawnablejobs was also returned. This breaks the LSP as it is not intended that SpawnableJobs are substutable for Jobs and to do so would violate the single responsibility principle.

So to fix this. Spawnable will change so it has a filed of jobToBeReplicated which will hold an instance of Job and will no longer inherit from Job.

Refactoring – Open Closed Principle applied to JobMan

Posted on November 12, 2018 by Robert Worrall

The MainJob and Replicator classes could turned to Abstract or I could introduce new base classes. I had previously deleted the Job class but this needs reinstating with MainJob extending Job. Then there could also be a replication base class that then extends the Job class functionality and introduces the functionality associated with spawning a Job. The base class in this instance could be referred to as SpawnableJob. I have chosen to introduce base classes mainly because I prefer the names of the base classes.

In future Job Classes could have further functionality added e.g a job with attached documents.

This would require minimum amendments to the JobDatabase class.

The class diagram now looks like this:

Refactoring – Single Responsibility Principle (SRP) applied to JobMan

Posted on November 8, 2018 by Robert Worrall

The MainJob Class stores the data regarding a Job but also issues subjob numbers. Similarly the JobDatabase issues the MainJob Numbers. The Job numbers follow a particular scheme. So the scheme could be injected into the JobDatabase removing the responsibility from the MainJob class. This will also impact on JobComparator class which will also have to move to a dependency injection.

The trick will be ensuring the proper comparator with the numbering scheme, or at least instances where the comparitor uses the numbering scheme. The JobNumberingInterface could specify its own comparitor via injection with the method: public String getComparator().

Refactoring Old Code – Divide and Conquer

Posted on November 2, 2018November 2, 2018 by Robert Worrall

For refactoring the code in old project Jobman. I have finally finished my first phase of refactoring the. However instead of refactoring all of the code. I chose to concentrate on the relatively small section of the code base relating not GUI related. I have done this with the intention of putting all the GUI code into as seperate project – I.E Desktop JobManager. I then intend to create a restful project that then can be used via multiple platforms. For anyone who is interested I have created a Gitlab repository at:

https://gitlab.com/raw_org/jobman.git

Before I start creating other platform I need to finish refactoring the code. This is to ensure it is now following the SOLID and other Design Principles. As of today, this is how the JobManger minus the GUI elements currently looks like?

In the next post I will start with refatoring to SOLID principles.