| View previous topic :: View next topic |
| Author |
Message |
Victor Porton
Guest
|
 Posted: Fri Oct 10, 2008 5:20 pm Post subject: Which place in hirearchy |
 |
|
I generate static HTML pages (articles, product pages, etc.) from a
DB.
Should article generation be in Article object (or maybe its derived
ArticleGenerator object) or in special GenerateHTML (or maybe its
derived GenerateHTMLArticle) object?
Currently Article object is used for editing the DB table with
articles. |
|
| |
|
 Back to top |
Victor Porton
Guest
|
| Posted: Sat Oct 11, 2008 4:39 pm Post subject: Re: Which place in hirearchy |
|
|
On Oct 10, 7:20 pm, Victor Porton <por...@narod.ru> wrote:
| Quote: | I generate static HTML pages (articles, product pages, etc.) from a
DB.
Should article generation be in Article object (or maybe its derived
ArticleGenerator object) or in special GenerateHTML (or maybe its
derived GenerateHTMLArticle) object?
Currently Article object is used for editing the DB table with
articles.
|
I decided to use multiple inheritance:
StaticArticle <- Article, StaticSiteObject
Article <- SiteObject
StaticSiteObject <- SiteObject
StaticArticle generates static (HTML) pages with articles.
StaticSiteObject is commons for generating HTML pages.
Article is about ID of an article in DB.
SiteObject is commons for articles, products, etc. in DB |
|
| |
|
| Back to top |
H. S. Lahman
Guest
|
| Posted: Sat Oct 11, 2008 7:49 pm Post subject: Re: Which place in hirearchy |
|
|
Responding to Porton...
| Quote: | I generate static HTML pages (articles, product pages, etc.) from a
DB.
Should article generation be in Article object (or maybe its derived
ArticleGenerator object) or in special GenerateHTML (or maybe its
derived GenerateHTMLArticle) object?
|
It all depends on what problem the application is solving. At one
extreme, if all the application is doing is reformatting DB tables into
HTML and pushing them off to a browser, then you probably should be
using a RAD IDE designed for that sort of thing rather than an OO
approach. OTOH,...
| Quote: |
Currently Article object is used for editing the DB table with
articles.
|
This hints that the application has already been designed around some
problem where a notion of Article is a correct abstraction of the
problem space. (That's good because one should always solve the customer
problem before worrying about how to get data to/from the DB once one is
outside CRUD/USER processing.)
If that's the case then there are really three distinct steps. First,
you get data from the DB to populate and initialize the object
abstractions needed to solve the customer problem. Second, you solve the
customer problem using those object abstractions. Third, you provide
information to the user that needs to be encoded in HTML from the
objects abstractions for browser display.
Typically the first step will be a job for factory objects that create
the problem objects (e.g., the various GoF construction patterns). Those
factory objects understand and encapsulate things like DB queries and
parsing datasets. If one thinks of the HTML as a distinct suite of
object abstractions (example citation below), then one can repeat the
factory approach by providing factory objects that understand how to
construct those HTML objects from the problem solving abstractions.
Just to complicate things a bit more, decoding RDB tables and encoding
HTML is always done exactly the same way and the paradigms for RDBs and
browser display are very narrowly defined. That allows one to extract
the invariants of the processing and encapsulate them in subsystems that
are reusable across applications. The initialization of those subsystem
for a specific context (e.g., RDB schema) can be handled parametrically
through configuration data that is defined specifically for the application.
As an example of this you might check out the model in Figure 17.2 of
"Executable UML" by Mellor and Balcer. That model of a web browser
display semantic could be reused for any application. All one would have
to provide is object initialization data (configuration data tailored to
the specific problem) and a Facade-like interface that converted the
specific application's data into subsystem requests that mapped to
specific objects based on message identity. For example, a
displayArticle (<attribute data>) interface method that would
re-dispatch to the appropriate factory object that knew how to configure
the HTML for an article entity.
--
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH |
|
| |
|
| Back to top |
Phlip
Guest
|
| Posted: Sat Oct 11, 2008 8:20 pm Post subject: Re: Which place in hirearchy |
|
|
Victor Porton wrote:
| Quote: | I generate static HTML pages (articles, product pages, etc.) from a
DB.
Should article generation be in Article object (or maybe its derived
ArticleGenerator object) or in special GenerateHTML (or maybe its
derived GenerateHTMLArticle) object?
Currently Article object is used for editing the DB table with
articles.
|
Which is simplest?
Which is easiest to test?
--
Phlip
http://broadcast.oreilly.com/2008/10/testing-rails-partials.html |
|
| |
|
| Back to top |
Victor Porton
Guest
|
| Posted: Sun Oct 12, 2008 5:10 pm Post subject: Re: Which place in hirearchy |
|
|
On Oct 12, 6:14 pm, "H. S. Lahman" <h...@pathfindermda.com> wrote:
| Quote: | Responding to Porton...
I generate static HTML pages (articles, product pages, etc.) from a
DB.
Should article generation be in Article object (or maybe its derived
ArticleGenerator object) or in special GenerateHTML (or maybe its
derived GenerateHTMLArticle) object?
Currently Article object is used for editing the DB table with
articles.
I decided to use multiple inheritance:
StaticArticle <- Article, StaticSiteObject
Article <- SiteObject
StaticSiteObject <- SiteObject
If I understand this notation correctly you are doing:
[SiteObject]
A
|
+---------+---------+
| |
[StasticSiteObject] [Article]
A A
| |
+---------+---------+
|
[StaticArticle]
There are a couple of technical problems with that from an OOA/D
perspective. Since OO class models are essentially Venn Diagrams of set
and subset membership, this model says that the set of members of
[SiteObject] is an identity set to the members of [StaticArticle]. It
also says that all members of [StaticSiteObject] are members of
[StaticArticle] and all [Article] members are [StaticArticle] members. I
suspect is not what you want.
|
I want the reverse: Article and StasticSiteObject inherits from
SiteObject, StaticArticle inherits from StasticSiteObject and Article, |
|
| |
|
| Back to top |
H. S. Lahman
Guest
|
| Posted: Sun Oct 12, 2008 9:14 pm Post subject: Re: Which place in hirearchy |
|
|
Responding to Porton...
If you are doing a CRUD/USER pipeline application between RDB and
browser, you can ignore the rest of this message. N-)
| Quote: | I generate static HTML pages (articles, product pages, etc.) from a
DB.
Should article generation be in Article object (or maybe its derived
ArticleGenerator object) or in special GenerateHTML (or maybe its
derived GenerateHTMLArticle) object?
Currently Article object is used for editing the DB table with
articles.
I decided to use multiple inheritance:
StaticArticle <- Article, StaticSiteObject
Article <- SiteObject
StaticSiteObject <- SiteObject
|
If I understand this notation correctly you are doing:
[SiteObject]
A
|
+---------+---------+
| |
[StasticSiteObject] [Article]
A A
| |
+---------+---------+
|
[StaticArticle]
There are a couple of technical problems with that from an OOA/D
perspective. Since OO class models are essentially Venn Diagrams of set
and subset membership, this model says that the set of members of
[SiteObject] is an identity set to the members of [StaticArticle]. It
also says that all members of [StaticSiteObject] are members of
[StaticArticle] and all [Article] members are [StaticArticle] members. I
suspect is not what you want.
That's because of two OOA/D rules to ensure unambiguous specification of
generalization:
(1) The union of members of all sibling subsets must be a complete set
of the immediate parent superset.
(2) Sibling subsets are disjoint subsets (i.e., an object can't be a
member of two such subsets at once).
<aside>
Poorly formed OOPLs break these rules regularly by allowing one to
instantiate a superclass without specifying a leaf subclass. But that
leads to nasty problems because of the inherent ambiguity of certain
superclass members being defined negatively (i.e., NOT a member of
existing subclasses) when the tree is reorganized during maintenance.
A similar problem arises when the OOPL allows a superclass to have only
one subclass. That is ambiguous because the other members of the
superclass NOT in the defined subclass are not rigorously defined. [If
the members of [StaticArcticle] are the only members of [Article], those
are identity sets and there is no need for subclassing. So there *must*
be other members of [Article] that have not been not defined.)
</aside>
I am also not keen on a multiple inheritance solution because it is
something one wishes to avoid whenever possible. That's because it tends
to produce subclass objects that are not cohesive and are not easily
mappable to problem space entities (e.g., try going into your local auto
dealer and asking to see a Displayable Dodge Caravan). Multiple
inheritance is sometimes useful but it needs to be applied with
discipline (e.g., only in contexts where there is already common
semantics). In this case HTML rendering and RDB schemas are semantically
quite independent.
Bottom line: I would look for a different solution.
--
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH |
|
| |
|
| Back to top |
H. S. Lahman
Guest
|
| Posted: Mon Oct 13, 2008 7:35 pm Post subject: Re: Which place in hirearchy |
|
|
Responding to Porton...
| Quote: | I decided to use multiple inheritance:
StaticArticle <- Article, StaticSiteObject
Article <- SiteObject
StaticSiteObject <- SiteObject
If I understand this notation correctly you are doing:
[SiteObject]
A
|
+---------+---------+
| |
[StasticSiteObject] [Article]
A A
| |
+---------+---------+
|
[StaticArticle]
There are a couple of technical problems with that from an OOA/D
perspective. Since OO class models are essentially Venn Diagrams of set
and subset membership, this model says that the set of members of
[SiteObject] is an identity set to the members of [StaticArticle]. It
also says that all members of [StaticSiteObject] are members of
[StaticArticle] and all [Article] members are [StaticArticle] members. I
suspect is not what you want.
I want the reverse: Article and StasticSiteObject inherits from
SiteObject, StaticArticle inherits from StasticSiteObject and Article,
|
That's exactly what I showed. In UML the diamond (conventionally an 'A'
in a text diagram) on a generalization relation is on the end that is
the superclass (i.e., from which the subclasses inherit).
--
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH |
|
| |
|
| Back to top |
|
