Hello Archer,
I was thinking about the design of a plantform-like stuff that
allow people inherit from my work and implement their own functions
without source.
Cool. Lots of folks have implemented frameworks. There are quite a few
strategies for doing this.
I think plug-in tech can't satisfy it well. Because user only
need realize one function for it, not a large quantity.
Not sure what you mean by "plug-in tech" that is not useful. If you are
referring to Reflection, then your framework will normally not need
Reflection in order to do its work... (with some important exceptions --
that's a seperate discussion).
Normally, you would design your framework to use Design Patterns that allow
the users to insert algorithms or structures using interfaces that you
provide.
At first, I think of a class like A, it is implement by default. B,
inherit from A, is user customrized class which override some
functions.
That would be unusual in a Framework. Much more common would be that you
would create an Interface I that Class A derives from. You'd also provide
Collaborator Z. This class can use any object derived from Interface I,
including Class A. Your user would derive a class from Interface I and pass
it to Collaborator Z, who can use it exactly the same way as it would use
Class A.
A good example of this, that most folks are familiar with, is the stream
object. There are many types of streams, but they all derive from the
Stream interface. This allows you to create a stream reader, if you'd like,
that will use any of the stream objects. It also allows you to create your
own unique stream object that any of the other stream readers can use.
In this way, user can archieve the object, but it need user to read
my source. That is a long term and a boring time. How to design this?
I agree with you completely. Users should definitely not read your code, or
even have access to it. Fortunately, there is no need for them to.
In order to build a framework, you need to learn a few things:
1) Design Patterns in general... start by picking up "Design Patterns
Explained" by Shalloway and Trott. This is an essential first step. Do not
skip this step.
2) In the GoF list, focus on the Strategy, Chain of Responsibility,
Decorator, Factory, Abstract Factory, Singleton, and Bridge patterns. If
you master this set of seven patterns, you will have the tools you need to
build most framework classes. There are a few more that are often used, but
this is a powerful set.
3) Read about Inversion of Control
http://www.martinfowler.com/articles/injection.html
I hope this helps,
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
