Re: Encapsulation vs separation of concerns
From: frebe (fredrik_bertilsson_at_passagen.se)
Date: 12/31/04
- Next message: frebe: "Re: Encapsulation vs separation of concerns"
- Previous message: Steve Jorgensen: "Re: how many bugs do you find and correct during TDD?"
- In reply to: H. S. Lahman: "Re: Encapsulation vs separation of concerns"
- Next in thread: H. S. Lahman: "Re: Encapsulation vs separation of concerns"
- Reply: H. S. Lahman: "Re: Encapsulation vs separation of concerns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 30 Dec 2004 22:34:36 -0800
H. S. Lahman wrote:
> A::method1 does not have the responsibility for setting 'attr1'; that
> now belongs to A::method2.
But a call to A::method1 will cause the setting of 'attr1'. I would
aggree with you if all this was about asynchronous message handling.
But normal programming logic is synchronous. Mostly when you call a
method, you want a result. Let's hava java.util.ArrayList as an
example. The size() method needs to return a value. It can not send the
value as an message.
> Now to answer your specific question: it doesn't matter. The
> precondition for the execution of A::method2 is that B::method1 has
> completed its execution. So it doesn't matter who actually called
> B::method1.
But B::method1 needs to know where to send the message.
> If [C] needs to
> invoke B::method1, the A::method1 send a message to C rather than to
B.
But you need to change the implementation of B::method1. It can not do
both at the same time.
> > Can you rewrite, let's say java.text.NumberFormat in Java JDK
according
> > to your pattern? That might help me to understand your point.
>
> Alas, no, I don't do Java. In fact, as a translationist, I don't do
3GL
> code at all anymore. B-) [I doubt that I have written 10 KLOC of
3GL
> code since the mid-'80s, so barely even remember C++ syntax.]
So I have spent my time discussing programming with someone that don't
know programming? I assume that you actually work with building
software, what languages (4GL?) do you use?
> > I am still asking why a function is not self-contained. If we look
at
> > mathematics, isn't functions like sin, cos, etc self-contained.
They
> > are very easy to unit test.
>
> They are self-contained because they don't call other funtions at
all.
Wrong, one mathematical function can call another. For example, to
calculate sin or cos polynom caluculation can be used, to evaluate a
polynom you need for example the function for calculating power of.
> The problem lies in making functions that call other functions
> self-contained. That can't be done if the called function returns a
> value that the caller uses. As soon as that value is used, the
caller's
> implementation is no longer self-contained because it depends on what
> the called function does -- the called function is a literal
extension
> of the caller.
I cannot agree here. Computer science and programming is about making
blocks of functionallity that are reused on a higer level. Every
statement in a 3GL language is a function call. Assignment, simple
calculations (+,-,*,/), comparations, need blocks of logic (function)
on a lower level, to work.
> The OOA/D techniques that facilitate
> making self-contained methods for objects that collaborate with other
> objects are: <conceptual> separation of message and method; treating
> messages as announcements (I'm Done) rather than imperatives (Do
This);
> and using peer-to-peer collaboration. If one does the OOA/D
properly,
> then it won't matter that the OOPLs syntactically trash the
separation
> of message and method and make sending a message look like a
procedural
> imperative.
I realize that you think that every function/method call could be
treated like an asynchronous message. Asynchronous messaging is one
very useful technology, but is not the only solution. Of course you
need synchronous function/method calls too.
> The query is a paradigm for accessing static data storage (in
particular
> RDB static storage), not solving problems. As I indicated in the
> example I provided, Query may well be a class within the subsystem
the
> accesses persistence. But it is not a natural class for most problem
> spaces.
In many client applications, the user virtually builds a query by
choosing sort order, filters and filter values. The query concept
solves many problems for users. In, for example, an application for
accounting, the user really want to query the information in many
different ways.
And if queries are not built by the user, it is still a very natural
class in the business layer. When implementing the business logic, it
is not enough with a limited number of predefined methods for finding
objects. Otherwise you will have to be coding in both the business and
persistence (and probably also presentation) layer at the same time.
> My whole point in the
> persistence access context is that when the application needs to
solve
> some significant problem for the customer, the business abstractions
> will not map up 1:1.
Why not, please give an example? During all years I spent doing
software engineering, I see the same pattern everywhere. Lets say we
have a business object called Customer. Of course you would have a
table called customer, and most likely you would have a GUI form for
editing customer objects. This is a very natural pattern.
> Table, Tuple, etc. /are/ the implementation of the paradigm.
Maybe an implementation of the paradigm, but they can can be interfaces
in a programming language. I know that you can define anything as an
interface or implementation. For me, in a given context, an interface
and its implementation is two separate things, and because of this an
interface can never show anything of the implementation. But obviously
it is different for you.
> The caller must understand that implementation structure to
> properly make the call.
For a RDBMS, the schema definition is not an "implemantation
structure". It is the interface. How the schema is implemented is a
completly other story.
> In this example, if one decided to switch to an OODB or flat files,
one
> would have to completely redefine the interface and the callers'
If you want to change information model for your application, you have
to rewrite it. But if you switch from a RDB to a OODB or flat files,
you still use the same interface, SQL and JDBC/ODBC/ADO, and nothing
has to be changed in your application.
> One would even have to
> modify the callers if the RDB schema changed!
Wanting to change the schema without changing you application is the
same thing as wanting to change your object model but not change the
rest of your application. Give me two examples of a schema change you
want to do, that would not affect the rest of your application.
> As I indicated previously, the problem solution doesn't care if the
data
> is persisted in an RDB, an OODB, flat files, or clay tablets. Those
> mechanisms and paradigms should be completely transparent to the
> business solution logic.
Having business logic transparent to your information model will only
be able to use features that exists in all types. Because the
relational model are much more powerful than the record model in flat
files, you have to implement a lot of logic in your business layer
(like queries, transactions, locking, etc) that already exists in RDB.
But you cann't use it because your application have to work with flat
files too. It is the same problem in Java JDK. Because java is platform
independent, it can't let the programmer use all features in the
operative systems (environment variables, file security, etc), because
these features does not exists (or works complety different) on every
platform. Some times this kind of abstractation is worth the cost (most
operative systems are very similar) but regarding databases (they are
too different) it is not worth it.
> >>>I agree with you here that that you need a generic library with
classes
> >>>like Table/Tuple/Field etc. And like you say, this kind of library
can
> >>>be used by any application. Which one do you use?
> >>
> >>The thing that wants to be reusable is the subsystem, not the
classes
> >>that implement it.
> >
> > I don't follow you here. I thought a subsystem is a collection of
> > classes.
>
> It is a collection of classes. But the subsystem as a whole should
be
> reusable. One should not have to construct the subsystem from
library
> classes for every application.
I thought we was talking about two levels in the persistence layer.
First we have a generic standard product on top of JDBC/ODBC/ADO that
have classes like Table/Tuple/Field. On top of this product we have the
application specific persitence layer, which maps the business objects
to the database objects. Or?
> >>One typically builds a persistence access subsystem
> >>once and reuses the entire thing across applications. Then one
just
> >>provides a configuration file and glue code for the interface in
the
> >>application.
> >
> > Here you are talkning about some sort of standard product/library,
> > right? Which one are you using?
>
> Alas, the industry isn't there yet for general programming.
Have a look at http://butler.sourceforge.net. It has everything you are
talking about. Look at the classes in the butler.sql packages. They fit
very well inside your persistence layer.
Fredrik Bertilsson
- Next message: frebe: "Re: Encapsulation vs separation of concerns"
- Previous message: Steve Jorgensen: "Re: how many bugs do you find and correct during TDD?"
- In reply to: H. S. Lahman: "Re: Encapsulation vs separation of concerns"
- Next in thread: H. S. Lahman: "Re: Encapsulation vs separation of concerns"
- Reply: H. S. Lahman: "Re: Encapsulation vs separation of concerns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
