Good evening!
I had previously talked about a mysterious other dilemma that I did
not have the time to write about. This dilemma really goes into the
depts about design ques on frameworking.
The question:
How do you associate classes that make up a whole, but define
completely different functionality, and are all used in
conjunction with each other? How do you abstract this to the
best, and when is it considered too much abstraction?
That's a loaded question. Let's break this down some more and see if
we can develope an answer (as I don't have one yet).
Let's start with the smaller of the questions.
How do you abstract [classes] to the best?
This seems like an incredibily difficult question. How do you know
you've actually pulled out all the pieces and made them abstract?
How do you know it's not exceedingly abstract? How do you know it's
abstract enough for future implementations?
Okay, okay. This is super loaded. Lets go and assume you are creating
a framework to be prototyped for some basic functionality.
I'm going to back track. I'll provide an example; the one that
provoked this question to begin with.
Imagine, if you will, you are to implement a ratings/reviews API into
your website. You want to do a good job, right? You want it to be
extremely frameworked and use a standard API for your developers
that correlates to another API. Well, ratings/reviews has several
different partitions. You have search engine content, content loaded
from service server, and you also have a rating's star system that is
based on an XML file. These are all different parts of the services
API and are all called completely differenly. Not even using the same
methods (such as, one in Javascript, one uses XML, another uses static
files). Not to mention, each API contains several different rending
types. So, how do you split this out, but make it so that it can be
used later for other parts of the website that won't be using the same
configuration as another part of the website.
You'll end up having a lot of classes that don't really work together
but are together because they share the same parent. That's about
the only relationship. The problem with this is, if another part of
website needs to change the implementation, that means they have to
write three new classes that extend from the base classes. This seems
like God Awful horrible code. How do you overcome this hurdle and
allow the classes to be easily extended, changed, modified, and
accessible?
Yes, you can always just make each property have getter/setter. This
also seems like crappy code. Maybe not; but it seems unstandard and
unsafe.
Inevitably, my solution was to have a helper class that brought
everything together. The class allowed you to set properties on the
class by defining which rendering you'd be using and the properties
for it. Also, you are able to define the renderers options for the
type that it was rendering.
I found this to be the best in the situation.
Back to my original question. I have yet to really answer it; I know.
I think the method of abstraction is really all to the eye of the
beholder. Everyone thinks completely differently. Some will tell you
that you should only abstract as much as the business needs you to.
Others will tell you to make each and every property its own class.
Where's the fine line?
The line is probably at which point have you detoured and are no
longer talking about the functionality you were set out to introduce.
When you are going into things so off subject, so different
that you're just adding code to make it more accessibile. When you
reach this point, you need to take a step back and figure out what
you really do need. You should never be reinventing anything. Always
use what tools you have available.
The line is never fine, but horribly fuzzy. You should abstract out
to make things easier to expand on in the future. Abstract out to
seperate smaller functionalities. For example: