From: Robert Martin on
On 2007-01-23 15:28:32 -0600, "topmind" <topmind(a)technologist.com> said:

> OO does the reverse. Wether one approach is inharently better or not, I
> cannot say with certainty.

That is the most mature statement I've seen you make.

In many ways OO is the reverse of procedural programming.

In procedural code dependencies flow in the direction of control.
In OO code dependencies flow against the direction of control.

In procedural code functions can be added to existing data structures
without changing the data structures.

In OO code data structures can be added to existing functions without
changing the functions.

People who are used to working with tables and data often build DSLs
out of the data and write programs using those higher level data
concepts.

People who are used to OO often write DSLs out of objects and write
programs using those higher level object concepts.

One way is not better than the other; but BOTH ways are better than just one.
--
Robert C. Martin (Uncle Bob)��| email: unclebob(a)objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



From: Robert Martin on
On 2007-01-22 09:45:54 -0600, "Daniel Parker" <danielaparker(a)gmail.com> said:

>
> lilburne wrote:
>> Robert Martin wrote:
>>
>> Hasn't Payroll been solved?
>
> I think so. I think you buy them these days. I don't know of any
> companies that would write their own payroll system anymore.

Remarkably, a lot do. Ironically, COTS software is sometimes more
painful to adapt to your needs than writing the whole applciation from
scratch.


--
Robert C. Martin (Uncle Bob)��| email: unclebob(a)objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



From: topmind on
On Jan 23, 5:34 pm, Robert Martin <uncle...(a)objectmentor.com> wrote:
> On 2007-01-23 15:28:32 -0600, "topmind" <topm...(a)technologist.com> said:
>
> > OO does the reverse. Wether one approach is inharently better or not, I
> > cannot say with certainty.
>
>That is the most mature statement I've seen you make.
>
> In many ways OO is the reverse of procedural programming.
>
> In procedural code dependencies flow in the direction of control.
> In OO code dependencies flow against the direction of control.
>
> In procedural code functions can be added to existing data structures
> without changing the data structures.
>
> In OO code data structures can be added to existing functions without
> changing the functions.
>
> People who are used to working with tables and data often build DSLs
> out of the data and write programs using those higher level data
> concepts.

I assume that DSL stands for "domain-specific language". Note that one
can also write DSL with functions also. Thus, one is not limited to
just DSL's using tables.

>
> People who are used to OO often write DSLs out of objects and write
> programs using those higher level object concepts.
>
> One way is not better than the other; but BOTH ways are better than just one.

But there are no clear, consensus criteria for when to use one over the
other. People's selection seems to be a personal preference. I am
afraid that the rules of thumb you suggest cannot be considered in
isolation such that one is weighing many factors, and I tend to
disagree with the weights you assign to some factors.

> --
> Robert C. Martin (Uncle Bob) | email: uncle...(a)objectmentor.com

-T-

From: frebe73 on
> > How many getEmployeeBySomeCriteria methods do you think you will end up
> > with in a normal payroll application?
>
>I imagine it will be quite a few,

Only a few ways of fetching employees? By name, by employment no, by
SSN, by department, by city.... But I guess that you will do it the OO
way, fetching all employees and select the instances you really want,
by traversing them and call a matcher/filter function. Performance is a
secondary issue.

> though fewer than the number of
> embedded SQL statements that would exist if I did not put them behind
> an interface.

What is the purpose with putting a statement like "select salary from
employee where SSN=?" behind an interface? You are substituting one
one-liner with another one-liner that needs an additional
implementation.

> > Why do you want to hide predicate
> > logic and set operations behind a procedural interface?
>
> I don't. I want to give the operations meaningful names. For example:
>
> findEmployeesEligibleForRetirement

This is neither predicate logic nor a set operation. You have given an
example of a function, which indeed is very useful (also together with
predicates).

> is more evocative than a long SQL statement that doesn't mention
> retirement at all. Think of the functions as compilable comments that
> describe what the SQL beneath them is intended to do.

A much better idea would be to create a view
EmployeesEligibleForRetirement. Views are much more flexible than
functions, because they can be combined together in other set
operations and logic statements. You might for example join this view
with the SalarayPayment relation. If you embedd the statement inside a
function, you don't have that kind of flexibility.

> This has the additional benefit that when the eligibility rules change,
> the callers of findEmployeeEligibleForRetirement() will be unaffected.

The same benefit exists if you create a view.

> >> In any application, OO or not, this translation must take place.
>
> > Absolutely not.
>
> The data is on the disk.

This is a common statement from people that lacks education about
modern databases. They think that the SQL statement
"select mycol from mytable", will cause the database to read something
from disk. In a well-tuned database, the data will most likely already
be in RAM.

> It must be translated into some kind of
> TableRow structure or similar. Then it must be unpacked from that
> structure into something convenient for the application to use.
>
> Now it is entirely possible that the application will simply index into
> the TableRow structure every time it wants to access the data; but even
> that is an *implicit* translation into a more convenient form.

You don't need a TableRow instance, just use select/fetch into. And if
you still prefer a result set, this class is generic. You don't have to
write it yourself.

> > If you have a table employee and a class employee, you obviously have
> > duplication.
>You have the same "duplication" if you have a table "employee", and a
> set of convenient variables used to hold parts of one of the rows from
> time to time. You even have it if you have a TableRow structure that
> holds the employee row.

TableRow is a generic class, employee is not.

> > If you have five variants of getEmployeeBySomeCriteria,
> > you obviously have duplication.
>I don't see that at all. The five functions may simply call a more
> general function passing in specific parameters.

Why do you want the five functions in the first place? If you have
general function, why not use that one from the beginning?

Fredrik Bertilsson
http://mybase.sf.net

From: frebe73 on
> > On a very hight abstractation level we can describe the requirements of
> > the system by defining the data model for the input data and the output
> > data, and data derivation rules. If we choose to use computer software
> > to implement it, is an implementation issue.
>
> That particular implementation issue contains an entire engineering
> discipline and science.

One could also say that more than 90% of the employees in the world are
still getting paid by the manual system you described above. I am not
saying that behavior is not needed, I am only opposing your statement
that "we are being paid to create payroll behaviors". We are getting
paid to produce payroll data (paychecks). The customer doesn't care so
much about how (behavior) it is done.

The most stupid thing about OO is data hiding. Why should we hide the
stuff that are most important of all?

Fredrik Bertilsson
http://mybase.sf.net