The truth is, I don’t like the direction that BackPress is going. I think it suffers or is going to suffer from the Blob anti-pattern that a lot of object-oriented WordPress plugins follow. Whether that will ultimately be the case, it is sort of already seen with the Taxonomy BackPress implementation.
The point is, I want to set an example of how it should be done, if the person writing the example had about 10 more years writing objects and coding using object-oriented patterns. I’m just winging it people! I’ll fail, it is a given. I do wish to prove what a rough of what it should look like. That said, the developers behind BackPress and bbPress are far more experienced than I am. It is a wonder however why the objects aren’t better designed. Take the Roles and Capabilities class API, it is well done. The purpose of the objects are well defined and abstracted.
I think the point is of differing opinions and practices of what objects should encompass. I believe that objects should serve a single purpose and everything outside of its scope should be in its own class. You can take this too far and create too many objects which while they are well abstracted would probably better serve as functions.
That can be another problem. On one hand, if you create a God object, then all the user has to do is use that one object, but it also can’t be used for anything else. It can only be used for its one purpose and you can’t easily take out the installer portions and use them for other projects. On the other hand, if you create too many objects, you have an unwarranted complexity and without documentation, no one knows how to combine the classes to create a concrete application.
I tend to implement on the latter than the former, whether for better or worse. I’m not yet into UML, so my coding tends to involve a lot of refactoring. Therefore, I’m going to try to release version 1.0 as quickly as possible, that way the API is locked and only bug fixes will be applied. In that way, I can see what problems arose with the design of the classes and understand where I went wrong for the version 2.0 refactor release. When I release version 2.0, I’m not going to worry about backwards compatibility, so that I can get rid of the problem areas that do quite suck.
The principles of the development of CorePress is as follows:
- Test-Driven Development.
The API is not going to be released (as final), unless every component has at least 90% code coverage. In this way, many of the known use cases will be covered and edge cases and unknown use cases can easily be covered on top of the current code coverage. It should provide a great deal of additional stability and that is important for a library that no one is going to use except me.
Also, test-driven development techniques will be used to help design the library to be as easy as possible. I think it is better to find problems with the design before most of the class code is written.
- Documentation and Developer Manual.
Documentation is important for a library, because if the developer doesn’t know how to use your library, then they most likely won’t bother to use it. All of the code is going to have inline documentation describing the purpose. There will also be a Developer Manual with sections for each of the components, detailing the use cases and examples of how to use the components. I think with both of the two documentation, the API and manual will go a long way to help those that choose to use the library, when it is ready to be used.
- Licensing
Well, part of the problem is that either WordPress does the job too well for me to rewrite it or I’m not skilled enough to write it well enough anyway. Therefore, I am going to be using parts of the WordPress library that will be clearly documented as such and licensed under the GPL. This won’t stop most of the library from being New-BSD licensed. The important API parts will be New-BSD and hopefully, I can write the security layers to protect the API from hackers without digging my paws into the WordPress code. If I need to, those sections will be independent from the CorePress library.
I plan on releasing 0.1 version at the end of February, so whatever components are complete at that point will be released, with the exception that the DB, Plugin, and HTTP components must be completed. If those components aren’t complete at that time, then I’ll have to push the date back. I believe that I’ll have those three components done before the end of this month, so I’m not so much worried about it, but completed also includes documentation and I haven’t started the developers manual yet.
Oh yeah, I’m going to base the Developers Manual off of the docblocks in the code, so I’ll just improve on the current inline documentation and add examples and better explanations in some cases.
Possibly Related Posts:
- Calibre Improvements
- DragonU Bug Tracker Dev – Milestone 1
- Dragon MVC
- Why I Contributed to WordPress
- DragonU DB Component
Comments are closed.