Answered Aug 05, 2015 · 1 votes
Your question is indeed a bit vague, but it's kinda interesting in terms of "coding philosophy". I don't claim my answer to be the only way to do such things, especially without any specifics about your problem. It's just a set of guidelines I'd personally use and hopefully they will be helpful to you.
So, first of all, you have to really understand what's the problem you are trying to solve. I will not consider "I do it for educational purposes" as an option here. Try asking yourself questions like these:
Do you need to solve a singular problem?
A simplistic example: if your application needs to sort an array or, to be a bit closer to your field, calculate mean or deviation - all of those are singular problems. Your really shouldn't include a complete set of all known sorting algorightms in your application just to sort an array, same way you don't really need a deep statistical analysis system just to calculate a mean. I'd consider developing library specific to your problem.
What's wrong with current solution?
Such generic notions as frameworks are usually born when current solution is present, but there is a way to interact with it more efficiently. It's a really bad idea to hide bad code or design under the hood of some kind of abstraction. If current solution works well but its implementation seems to be a problem, I'd start with refactoring existing code, not rewriting it from scratch or hiding it.
Is it a recurring problem?
One of the most valueable features of generic pieces is reusability. It is always much harder to build something generic, yet useful. Harder means expensive, so you have to justify wasting time on building generic blocks. If you don't or can't use your expensive blocks in more that one place, you probably don't need them and better off developing concrete solution instead.
The reason I marked out these questions is that I often see code which its developer calls a framework and puts considerable amount of time and effort into it, but he ends up doing something that is not a framework and most importantly, it shouldn't be one in the first place.
So, we got to first part of your question:
Is there a reference to design and implement a framework? What are the characteristics of a framework? And what features should be?
It'd be appropriate here to give you a list of design guides and features that are exclusive to frameworks, but I don't think that it's a good idea. Here's why: there is no ISO or any other official or widely used standard for software frameworks development. And that's because framework does not solve particular problem, it provides means to do so - which is its most important feature.
A very common misconception about frameworks is that they must be absolutely transparent and should be able to bend to any need. Framework developers and users must understand that framework is hardwired to some point. And that's not because you can't do it otherwise. You can, it's called metaprogramming. The reason is that framework implies an invariable internal behaviour, which is usually called a "core of framework". It'd probably be useful for a client to have a way to extend this behaviour, but not modify it.
Point is, framework must dictate how client interacts with an environment. In a bit more strict terms, when client operates inside the framework, control flow is kind of reversed: framework evaluates client's code and makes appropriate calls, it is now framework who calls client, not the other way round, like it is with plain libraries. Ofcourse, there might be some exceptions, but I'm talking about general idea here.
What requisites must be covered?
As you probably figured already, there are no strict requisites. But there are few things that I'd like to suggest:
- Framework as a whole should represent a specific domain (field) fully, but it shouldn't go outside of it. It means, if your framework does financial analysis, it probably shouldn't do a weather forecast and be an alarm clock too
- Framework should have some kind of domain-specific language. And it doesn't really matter in which form. It can be just domain-specific objects that client operates, naming convention and proper level of indirection (abstraction) or you can go all the way and make a programming language with its own interpreter inside of it if you want. It's just the idea of client interacting with something closer to, for example, financial terms and operations, than some abstract handlers, pointers and functions
- It should be obvious, but it'd be careless not to mention it: always plan on expansion and scaling when dealing with generic matters. It shouldn't be too hard (I don't say easy) to implement and add something new as long as it doesn't contradict initially planned behaviour, but be careful and don't step into metaprogramming too deep doing that
And the last part of your question was:
Are the ORM associated with the Framework?
Well, yes and no. If your framework depends on data storage which is not specific for every instance, you should have some kind of abstraction for that. And ORM is probably the best way to go in this case, but there are few things I'd like to point out:
- There are other (probably not as flexible) ways to abstract data storage
- ORM implies that you are operating objects (OO-language, that is) which is not always true
- Problems of ORM technique itself is whole another topic, but I believe it is possible that those "hitches" might not be compatible with your framework in some way
Okay, that's it for your questions, but I'd like to add some tips if you ever decide to develop a proper framework:
- Do not forget that you develop means to solve, not a solution itself
- Do not try to "solve it all", meaning do not forget what problem you are solving. You can't solve it all, not in one solution anyway
- Do not concentrate on or get distracted by unnecessary features, especially early on
- Find an expert in a field which you plan to code for, he might have insight into what is needed and what is not
- I find it really convenient to adopt feature-driven development process for this kind of job, because framework implies tons of features which can make you scatter your effort which leads to a certain failure, if your approach is not solid. Especially if you plan on doing it alone, seeing iterative working results is kind of motivating
