The problem I have with good object-oriented design is that it doesn’t seem to be what I thought it used to be. Design patterns help, but I think a balance between abstraction and practicality has to be maintained. Another problem is when to refactor an object into two or more objects or when you create an interface or start with an interface. Hard questions that sometimes you know beforehand and others you find after you already written a few hundred or thousand lines of code.
The problem with too many classes is that while it is abstract enough, the scope becomes too large to comprehend fully. Keeping with the minimal amount of lines per method in a class seems logical for unit testing purposes and maintainability, but there have been a few times when I’ve taken this too far. Sometimes, one large class for the implementation is all that is needed and yet will be small enough to not extend beyond the scope of the problem.
Likewise, too few classes, when more classes should be used appears to be a problem as well. From a few libraries I’ve used, I’ve wished that I could quickly replace the functionality without extending the entire object. There is a trade off, You’re Not Going To Need It seems to have hindered me for quite a few years, while I was figuring out how to create an DB abstraction of DB abstracted libraries. The answer is that it isn’t needed nor would it ever be used. To have created it would to have spent the majority of my time on code abstraction that no one would have cared about or used, because it would be too convoluted and worthless.
So how much abstraction is needed to allow those who wish to replace functionality easily and yet not create a convoluted mess that no one will use? The answer is becoming more and more clear. The reason, I can only guess is that I’m now asking better questions. The questions I was asking before weren’t relevant to the actual problem I should have been solving.
Anyone who says object-oriented programming is easy, either doesn’t understand it or understands it so well and for so long that they’ve forgotten how complicated the solutions can be to put together. Anyone who says that object-oriented programming to follow and adhere to the strict OOP guidelines probably hasn’t done any real work or doesn’t mind the torture. Don’t get me wrong, I can handle a bit of torture myself and a little bit here and there isn’t all that bad.
It does prove whoever said that the first implementation should be thrown away (not exactly, but you end up doing so anyway or wishing you did). With object-oriented development, there have been many times I’ve went back to previous code and thought that I went about it the wrong way or that there was a better way.
I’m going to be rediscovering these problems and their solutions. What I would have done two or four years ago, might not be that far off from how I would do it now, but I believe my mind is more open to violating the strict adherence to “proper” object-oriented design. It isn’t that I knew what it was, but what I thought it was.
I’m discovering there is a difference between what object-oriented programming solves and what I was using it before to solve. The problem is one of ease-of-use and yet over complicating the design is something that often stems from bad object-oriented libraries and implementations. I experience problems when there is too much abstraction and I’m discovering that too much serves to over-complicate something that could otherwise not be, because the condition for the abstraction is never going to be met.
I used to think, naively, that if I make something abstract enough, then everyone will use it, because they can use their libraries with it and combine both libraries extremely easy, they’ll just have to write the bridge and then include the library. However, with further experience with libraries, and from discovering how developers use libraries and how I move from library to library and evaluate them. Developers don’t use piecemeal, or tend towards not using piecemeal. If a library offers everything including the kitchen sink, then the developer has to weigh whether any part is worthy of being used and if any part fails to meet their criteria, then the entire library is out.
This might not be completely true with component libraries, and could depend on other solutions. To clarify, lets say that there is a library that uses a HTML purifier that isn’t any good. Instead of using a better library that does a better job to replace that part, most likely what will happen is another library without that part or at least one with a better implementation will be used. I think the reason is more to do with modifications, it is easier to go with a library that doesn’t require modification to get what you want than refactoring the current third-party library to use what you want.
This is dependent on how much of the library is independent on the other parts. With some libraries, the pieces are so dependent on each other that in order to use another library for the HTML sanitization, the entire library might have to be replaced. This is a simple example, but I find it with MVC with the views using a template engine and you can’t remove it easily. I also see it with front controller implementations that only support mod_rewrite URLs.
My solution is to create my own. I’m going to write my own MVC library and see how well or poor it is. The problem, I suppose, is that no one realizes how bad their library sucks. That is until someone comes along and tells them. Most won’t. The way I figure it out, is seeing how annoyed I get with doing repetitive tasks or going through steps that seem redundant (why can’t the library take care of it?).
The contradiction for me is that good object-oriented design seems to tend more towards abstraction, but it is counter-intuitive in that it makes the object-oriented design more complicated and thus less likely to be used. It is just that finding a middle ground for which to have a well abstracted object-oriented library that is simple to use is difficult.
Possibly Related Posts:
- Easier APIs for WordPress
- Libraries Should Use Liberal Licenses
- Why Writing Documentation Wasn’t a Waste of Time
- WTF Are People Still Writing PHP Template Engines
- Ripping CodeIgniter a New One, Part 2
Tags: PHP Info