Page 1 of 1

Abstraction or Dependancies

Posted: Tue Sep 26, 2006 11:10 pm
by alex.barylski
In building a framework, I frequently encounter such questions...and I am forced to ask my self, what would others think? How do others feel?

Obviously, I will use my own framework regardless, but if I want others to potentially use it, I need to answer tricky subjective questions...

So I've decided to run a poll:

If given the ultimatum, which would you choose?

Remeber I said ultimatum, there is no maybe or other option...

I'll explain my situation better if you absolutely must know because you think there is a metter way to design, in which case I'm all ears, but first I need your vote. :)

Posted: Wed Sep 27, 2006 2:08 am
by Weirdan
In my book abstraction is not opposite to dependencies in any way. Unless you give these words some different meaning than I do, I don't see how this even a choice.

Posted: Wed Sep 27, 2006 2:44 pm
by alex.barylski
Weirdan wrote:In my book abstraction is not opposite to dependencies in any way. Unless you give these words some different meaning than I do, I don't see how this even a choice.
I knew I should have given an example, but was afraid that would skew results as someone might try and tell me something along the lines as: "Your design is wrong" when I assure you it isn't...if anything it's the concept or idea, but thats debateable.

I am debating adding a File/String class to my framework similar to MFC. By adding these classes and requiring framework developers to use them internally (instead of PHP API) to use them you add another abstraction to the library. However in doing so, when someone only wants to use, say the template engine, but the template engine niternally uses the CString class, you've just created a dependancy on the String class having to exist.

PITA in somecase personally, but I do like the idea of abstraction, so I just might go with that idea...

Hence the poll for abstraction over dependancies... :wink:

Posted: Wed Sep 27, 2006 5:36 pm
by Christopher
Hockey wrote:I am debating adding a File/String class to my framework similar to MFC. By adding these classes and requiring framework developers to use them internally (instead of PHP API) to use them you add another abstraction to the library. However in doing so, when someone only wants to use, say the template engine, but the template engine niternally uses the CString class, you've just created a dependancy on the String class having to exist.
But if you have a string class then you have abstraction and the class has dependencies on the library, if you don't create a string class then you have the dependencies on the library directly. For every abstraction class you add, you also add a new dependency. So it is Abstraction and Additional Dependency vs No Abstraction and Less Dependency.

Posted: Wed Sep 27, 2006 5:40 pm
by Chris Corbyn
Abstraction is always a good thing. The more abstraction you have in an application, the more layers and hence, the less likely you are to do any major restructuring in the long term.

Abstraction can be done very badly however. It's one of the most vital things to get right since if issues arise with your abstraction layer you may just finish up creating even more work for yourself, with the adverse effect.

By the way; can I just say that MFC just makes me think of Manchester City Football Club... so stop talking about it; you're confusing me :P :)

Posted: Wed Sep 27, 2006 5:53 pm
by AKA Panama Jack
My philosophy is the KISS principle. Keep It Simple Stupid.

Unfortunately that doesn't seem to happen often when it comes to web site creation. One area that is a little out of hand is the use of abstraction layers for just about everything. Honestly, it adds too much overhead to add a layer for everything. Sure there are times when using an abstraction layer is very useful as with databases and templates. Sadly some people go "ape doo-doo" when abstraction layers. At times it's almost as bad as making everything an object on a site. It's just adding more processing overhead.

Posted: Wed Sep 27, 2006 6:04 pm
by alex.barylski
d11wtq wrote:Abstraction is always a good thing. The more abstraction you have in an application, the more layers and hence, the less likely you are to do any major restructuring in the long term.

Abstraction can be done very badly however. It's one of the most vital things to get right since if issues arise with your abstraction layer you may just finish up creating even more work for yourself, with the adverse effect.

By the way; can I just say that MFC just makes me think of Manchester City Football Club... so stop talking about it; you're confusing me :P :)
:lol:

My dad says the same thing...but with him it's the Manitoba Farming Community :P

Posted: Wed Sep 27, 2006 6:14 pm
by alex.barylski
AKA Panama Jack wrote:My philosophy is the KISS principle. Keep It Simple Stupid.

Unfortunately that doesn't seem to happen often when it comes to web site creation. One area that is a little out of hand is the use of abstraction layers for just about everything. Honestly, it adds too much overhead to add a layer for everything. Sure there are times when using an abstraction layer is very useful as with databases and templates. Sadly some people go "ape doo-doo" when abstraction layers. At times it's almost as bad as making everything an object on a site. It's just adding more processing overhead.
I agree, however I do have other reasons to add a File abstraction outside of just adding the layer...

The API is then consistent and if I were to port my framework over to PERL, ASP or even C the porting of application code is also minimized.

Plus like d11, I do like the idea of abstraction, it does make sense. However I am in the same mindset when people use classes for everything, although I am slowly convincing myself that using classes as a quasi-namespace in PHP is acceptable practice. :P

But again, like my arguments on template engines, I also am an adovcate for optimization when possible and wrapping a string class just might be overkill...I dunno yet as there are certainly advantages of doing so, especially when porting a framework to another language. Plus the KISS principle applies. PHP's default string handling functions are complex and verbose, like the array functions. Newbies would have an easier time adjusting to a fixed framework API wrapper for a string or array, allowing them to start simple and build on that knowledge.

For instance, consider the array_* not only are they anaologous to a vector, but also a hash/associative and at the same time, they emulate a stack with push_* or pop_* functions...thats all that sprint to mind. But thats alot of function to remember when all you mostly do is add/remove...overly complex...which is good because advanced programmers like flexibility, but bad for newbies.

Admittedly MFC helper classses such as CArray and CFile do little more than add extra error checking, etc, they also encapsulate the concept of a file pointer, etc...working with an object is prefered to working with the raw API IMHO. It makes you think more OOP, which, even for advanced developers is a good thing, as we all know OOP lends itself to problem solving better than procedural.

Cheers :)