As continuation of the post Design Patterns and Good Practice post I will review and amend the Whitestarmedialibrary using the SOLID design principles.
Single Responsibility Principle
As it has been described to me the Single Responsibility Principle (SRP) is:
There should not be more than one reason for a class/method to change, or a class should always handle single functionality.
Also responsibilities should not be mixed into one class. The benefit being there is less coupling and therefore it is easier to change parts of the system without breaking something. Now do I understand this? This may not be as silly a question as one might think. When I looked up SRP I found an article at https://www.toptal.com/software/single-responsibility-principle which discusses this directly from an MVC perspective. He argues the application logic is divorced from the controlling class. If I apply this to the WhitestarMediaLibrary the application structure could look like this:
This reduces the role of the WhitestarMediaLibrary to handing out various libraries and opening the initial database or databases. Do I want a situation where 2 or more libraries are interacting with the one database? Do I have a database for each media? Or do I restrict the library to manage one type of media at a time? This seems restrictive given someone may want to play music whilst they game or record TV whilst watching a film. I will delay this decision further down the line until I have applied the other SOLID principles.
However, I do need to move the database management to another class. This class shall be called WhitestarDBManager.
Open Closed Design Principle
Wikipedia states Open Closed Design Principle (OCDP) as “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification” My first thought was that because this library is an uncompleted project this principle would not apply to the Whitestarmedialibrary. Only then, when the project is compiled and used in another project, would this principle apply. However, if I declared WhitestarMedia as abstract it will allow for possible dependency inversion later and allow the possibility of new media types to be added later.
Liskov Substitution Principle(LSP) Principle
When looking for instances where I have overridden classes, I was unable to find anywhere I violated the super classes features. The only classes where I could do this were the WhitestarMedia class and its subclasses. However, the parent class in this instance was created to group common behaviour not as an interface for a subclass to implement.
Interface Segregation Principle
This has been stated in Jpassion course as:
“Clients should not be forced to implement interfaces they don’t us. Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one sub module.”
At present there are no formal interfaces used. This however may change when I come to implement playlists.
Dependency Inversion Principle
Wikipedia describes this as:
- High-level modules should not depend on low-level modules. Both should depend on abstractions.
- Abstractions should not depend on details. Details should depend on abstractions.
As suggested above (in the OCDP section), changing WhitestarMedia to abstract changes the dependency between a library and its media to the abstract WhiteStarMedia and a specific media implementation e.g WhiteStarMedia_Music. However, could this also be applied to libraries themselves? In the above SRP section I moved the functionality of the database and the media management to specific classes. A WhiteStarMediaLibrary Interface could be created so new libraries can be added later. If the interface defined a constructor that required the type of media managed, the main whitestarMediaLibraryClass would could keep the various libraries in a collection instead of specific local variables. It would also allow multiple libraries of the same type to be added e.g. a library for online music service and one for a local service e.g. mp3 collection. The resulting structure would look be:
This brings me back to another delayed decision, are databases to be single or multiple users? If I want a system where there can be multiple libraries managing media of the same type and some of these are streaming services such as Netflix or Spotify, then we would not be handing a database to them. A better option may be handing over a configuration file when initialising the library. This could be as simple as a properties file that is retrieved from local storage. The file could be created and configured by the type specific library itself. This is then handed back to the WhitestarMediaLibrary when a close method is invoked. The DBmanager can be moved to a utility library and then whether the library is shared or not is left to the implementation of the whitestarMediaLibraryInterface. The resulting structure is reduced to:
All of the classes are then placed into packages e.g. Utility or WhitestarMediaTypes
