 |
|
| Computers Forum Index » Computer - Object » when to use component-based design vs. stayign with... |
|
Page 1 of 1 |
|
| Author |
Message |
| Ojas... |
 Posted: Sun May 31, 2009 11:38 pm |
|
|
|
Guest
|
First, I can understand component-based design when it is obvious that
components will likely be reused, or when we want to leverage existing
components.
Does anyone know of a good web page that nicely summarizes best
practices for when, and when not to, follow component design versus
traditional OOP? And are there different implementation levels that
one can follow when implementing a component?
Is there a web page anywhere that explains how to properly implement a
component? For example, should it thoroughly check all input
parameters, should it gracefully throw a published exception when
methods are called out of sequence, etc. To what extent should the
component be made idiot proof? I'm asking because this comes at a
cost in terms of development time, QA time, and processing overhead
(impacts performance).
Why:
I am working on a new product, and it is a product where nobody will
ever want to reuse any of our classes for other products.
In Visual Studio we've broken the product up into multiple projects
that use each other to simplify development on it given we have a half
dozen developers working on it.
This is a non-UI product, and it is highly specialized.
Assuming we do not need reuse of our large-grain components, for
example a component could be an adapter for reading and writing data
to a specific data source type (SQL Server), it seems like over-
engineering to have the main classes in these project files conform to
strict component contracts.
The public methods on our classes will never be used by anyone other
than the immediate small development team.
For example:
* do we need to have the component handle any invalid input values by
throwing an exception? For example, if someone passes a list, throw
an exception if any list element is null.
* do we need to have the component gracefully throw exceptions anytime
a dev makes an incorrect call sequence?
* should we add unit tests for every invalid and valid input parameter
combination we can think of? And of course add and test the software
to make all of these unit tests pass.
* etc. |
|
|
| Back to top |
|
|
|
| H. S. Lahman... |
| Posted: Tue Jun 02, 2009 11:51 pm |
|
|
|
Guest
|
Responding to shesh.rr...
Quote: * do we need to have the component gracefully throw exceptions anytime
a dev makes an incorrect call sequence?
I'm not sure what a 'dev' is here, but the basic rule is: raise an
exception when the software itself has gone unstable and use normal flow
of control for handling all other situations.
Would you not suggest using exception handling mechanism for error
handling then?
It depends on whether the error is unexpected or not. If at least
occasional occurrence is expected implicitly in the problem domain or
explicitly in the requirements, then one should not use the built-in
exception handling mechanisms. Things like user input errors, network
timeouts, unavailable resources, and whatnot are all expected errors in
some domains. So they need to be detected and processed within normal
application flow of control.
If the error is unexpected (i.e., the software is not working properly)
then the built-in exception handling facilities should be used because
they offer the best chance at recovery or a graceful exit. That's what
they are there for; they allow an immediate exit away from unstable code.
--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer
H. S. Lahman
H.lahman at (no spam) verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html |
|
|
| Back to top |
|
|
|
| Casey Hawthorne... |
| Posted: Fri Jun 05, 2009 9:36 pm |
|
|
|
Guest
|
Sorry, I've not followed the complete discussion.
I saw a presentation by Gregor Kiczales on Aspect-Oriented
programming.
-------------------------------------------
http://en.wikipedia.org/wiki/Aspect-oriented_programming
Aspect-oriented programming (AOP) is a programming paradigm that
increases modularity by allowing the separation of cross-cutting
concerns, forming a basis for aspect-oriented software development.
Cross-cutting concerns: Even though most classes in an OO model will
perform a single, specific function, they often share common,
secondary requirements with other classes. For example, we may want to
add logging to classes within the data-access layer and also to
classes in the UI layer whenever a thread enters or exits a method.
Even though the primary functionality of each class is very different,
the code needed to perform the secondary functionality is often
identical.
-------------------------------------------
AOP helps with logging and security which are archetypal cross-cutting
concerns.
AOP'ers are trying to find uses for AOP outside of these areas.
Kiczales argues that OOP suffers from a limitation called the tyranny
of the dominant decomposition.
So, I'd reccomend component based design if the tyranny of the
dominant decomposition is getting to be too challenging.
--
Regards,
Casey |
|
|
| Back to top |
|
|
|
| Lee Riemenschneider... |
| Posted: Sat Jun 13, 2009 9:04 pm |
|
|
|
Guest
|
On Fri, 5 Jun 2009 09:05:41 UTC, S Perryman <a at (no spam) a.net> wrote:
Quote: Matteo Bordin wrote:
Side question: in your posts you usually seem to imply fully
executable 4GL (in particular UML) have been quite common for years:
This "executable UML" is used as a slightly more abstract prog lang
(actually not really syntactically or semantically distinguishable from
some OOPLs) , that is then mostly "translated" into another prog lang to
produce an end system.
Not so much of a 4GL as a 3.xGL (where x is closer to 0 then it is to
0.999) . :-)
This is a big bucket of misinformation. Executable UML models are a
full abstraction level above 3GL code. The translation of an
Executable UML model isn't one to one with the target language.
Optimizations are done through the model compiler, not in the model.
An Executable UML model can be translated into code ranging from Java
to VHDL without a change to the model.
--
Lee W. Riemenschneider |
|
|
| Back to top |
|
|
|
| S Perryman... |
| Posted: Sun Jun 14, 2009 2:04 pm |
|
|
|
Guest
|
Lee Riemenschneider wrote:
Quote: On Fri, 5 Jun 2009 09:05:41 UTC, S Perryman <a at (no spam) a.net> wrote:
This "executable UML" is used as a slightly more abstract prog lang
(actually not really syntactically or semantically distinguishable from
some OOPLs) , that is then mostly "translated" into another prog lang to
produce an end system.
Not so much of a 4GL as a 3.xGL (where x is closer to 0 then it is to
0.999) . :-)
This is a big bucket of misinformation. Executable UML models are a
full abstraction level above 3GL code.
1. What is your definition of "3GL code" ??
2. Some UML *graphical* elements arguably are (sequence diagrams etc) .
The *"action languages"* are not.
And to prove this, provide an example of something 'written' in an
"action language" . Better still, provide a ref to the definition (in
BNF etc) of one such language (ie provide us with "big buckets" of
information) .
And also from 2, some graphical elements (class diagrams etc) are not
actually abstractions, merely pictorial representations of something that
could be defined as text.
And to repeat my statement :
<quote>
This "executable UML" is used as a slightly more abstract prog lang
(actually not really syntactically or semantically distinguishable from
some OOPLs) , that is then mostly "translated" into another prog lang to
produce an end system.
</quote>
Note the part "not really ..." .
Quote: The translation of an
Executable UML model isn't one to one with the target language.
Who said it was ??
Quote: Optimizations are done through the model compiler, not in the model.
An Executable UML model can be translated into code ranging from Java
to VHDL without a change to the model.
An Eiffel program can be translated into code ranging from C, to Java
bytecode, without a "change to the model" .
So your argument (whatever it is) appears to be a fallacy.
But anyway, enough of that.
You be getting on with giving us some "action language" examples or
language specifications to have a look at.
Regards,
Steven Perryman |
|
|
| Back to top |
|
|
|
| S Perryman... |
| Posted: Thu Jul 09, 2009 7:33 pm |
|
|
|
Guest
|
Lee Riemenschneider wrote:
Quote: Ignoring advice not to feed the troll. Sorry, but I want to see where
this is headed.
The premise is very simple :
With the definite exception of state transition diagrams, nothing exists in
your "executable UML" that cannot already be represented as is, or with
negligible effort, in a "3GL" .
Your claims of a "full level of abstraction above" are a fallacy.
1. Not really a surprise, as :
- the set that constitutes "3GL" is a very "broad
church" indeed (and some of its members raise the abstraction bar very
high)
- even the "5G" effort of the 1980s (I am assuming a certain lack of
ignorance on your part) did not even result in prog langs that were
semantically a "full level of abstraction" above the 3GLs (their power
resided elsewhere - again I am assuming a certain lack of ignorance on
your part as to what this is)
2. The premise is of course easily falsifiable.
If someone claims that micro-code is at the same level of abstraction as
assembler, one can ask to see the micro-code equivalent of the "add"
instruction etc.
If someone claims that assembler is at the same level of abstraction as
a typical prog lang, one can ask to see the assembler equivalent of a
procedure definition, an ADT spec etc.
I would expect a similar refutation for "executable UML" .
Fortunately, you don't have to spend forever on this.
You only have "domains" , "subsystems" , "events" , class relationships
to consider. Class definitions and your "action languages" are no
different to what 3GLs have been doing for over 40 years.
Quote: Interesting logic...
Logic is very interesting.
I can translate from Ada to VHDL without a "change to the model" .
And from ... to ... .
Again : so what ??
The act of translating from X to Y by definition never requires a
change to the "model" of X, only finding the equivalent means in Y to
represent something defined for X.
Regards,
Steven Perryman |
|
|
| Back to top |
|
|
|
| Lee Riemenschneider... |
| Posted: Tue Jul 21, 2009 2:23 am |
|
|
|
Guest
|
In article <h3us1v$ucq$1 at (no spam) aioe.org>, S Perryman <a at (no spam) a.net> wrote:
Quote: Lee Riemenschneider wrote:
In article <h352kj$8ho$1 at (no spam) aioe.org>, S Perryman <a at (no spam) a.net> wrote:
With the definite exception of state transition diagrams, nothing exists in
your "executable UML" that cannot already be represented as is, or with
negligible effort, in a "3GL" .
Your claims of a "full level of abstraction above" are a fallacy.
First you claim that the abstraction test fails, because the equivalent
can be done in a lower level language, ...
I claim no such thing.
Because *equivalence* != *abstraction*
I didn't say it did; you did. Re-read your original quoted text.
Quote: To express something such as a for loop, a function declaration etc in a
3GL requires far less content and detail than to provide the equivalent in
assembler.
That is because a 3GL is at a higher level of abstraction than assembler.
This is the nature of your "abstraction test" .
And your "executable UML" fails for the reasons already given.
A class diagram requires far less content and detail, than the equivalent
in C++, Java, etc., especially when it comes to relationships and the
constraints imposed by them. I find it hard to believe that anyone would
argue otherwise.
Quote: But unfortunately for you, C++ != "3GL" .
I've seen some programmers try to claim OO 3GLs are 3.5GL. I haven't really
seen a compelling argument to support even that minor step.
Quote: As you have already been told, some "3GL" raise the abstraction 'bar' very
high indeed.
And yet you have failed to support such a claim. Are they 9GLs, or does the
bar bump up against 4? e.g., 3.995GL This might be taking anarchy in the UK
a bit too far. |
|
|
| Back to top |
|
|
|
| John \"Z-Bo\" Zabroski... |
| Posted: Fri Jul 24, 2009 12:43 am |
|
|
|
Guest
|
On Jul 20, 10:23 pm, l... at (no spam) ubuntu1.frogooa (Lee Riemenschneider) wrote:
Quote: And yet you have failed to support such a claim. Are they 9GLs, or does the
bar bump up against 4? e.g., 3.995GL This might be taking anarchy in the UK
a bit too far.
I found this funny.
Stephen,
I think what the conversation needs is examples. You are being
critiqued on abstract stuff, when you would be better served to be
critiqued on concrete stuff. |
|
|
| Back to top |
|
|
|
|
|
All times are GMT
The time now is Sun Nov 29, 2009 8:42 pm
|
|