I think the key ultimately resides in what the patterns community calls a
pattern: a Solution to a Problem within a given Context that yields certain
Consequences.
For example, one of the key problems in enterprise systems has been how to
represent domain entites. We latched on to the OO model because it helps
represent domain entities in a natural and compelling way--each object has
complete knowledge of itself (and only itself), thereby allowing us to
partition the system into manageable "chunks". But reality and practicality
have to intrude--if we want a system with lots of objects interacting with
one another, we have to pay careful attention to *how* those interactions
are taking place, particularly with an eye to trips across the network.
Where I see your statement "I guess it's just a design call as to what falls
into the category of "Functionality which should be on another class but
isn't", as you say." I hear something a bit different: "When designing
systems that need to cross process and machine boundaries, you need to be
aware of the network boundaries and design accordingly". In short, network
boundaries become a new force in the Context of the Problem, and thus may
force us to derive a new Solution to the Problem.
Ted Neward
{.NET || Java} Course Author & Instructor, DevelopMentor
(http://www.develop.com)
http://www.javageeks.com/tneward
http://www.clrgeeks.com/tneward
----- Original Message -----
From: "Mike Dunbar" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 15, 2002 9:57 AM
Subject: Re: [EJB-INT] Off Topic: Architecture, Service-Based vs Classic OO
[was Re: date service]
> So, I guess it's just a design call as to what falls into the category
> of "Functionality which should be on another class but isn't", as you
> say. Believe me, I have also seen utility classes with static methods
> that made we just wanna scream. In the example DateService utility
> class given, however, that didn't come to my mind. I'm not sure if it
> is because this is after I had been exposed to the ideas of
> Service-Based (or Oriented) Architecture. Maybe someone could give some
> criteria for pointing out "bad procedural-style grouping of
> functionality apart from data" vs "good OO workflow/manager
> (stateless-session) style class".
>
> Thanks,
> Mike
>
>
> --- "Richard S.Martin" <[EMAIL PROTECTED]> wrote:
> > I don't think the approach of putting the getCustomersInRegion method
> > in a
> > CustomerService class is at odds with "classic-oo"; it is simply that
> > the
> > object being modelled by this class does not represent the Customer
> > itself,
> > but the workflows in which the Customer partakes. Such objects are
> > just as
> > valid for OO modelling as concrete things like Customers.
> >
> > Bringing us back onto this mailinglist's topic, this is, of course,
> > exactly
> > what we are doing when we use an entity bean to represent a customer
> > and
> > model the customers' workflows with stateless session beans.
> >
> > Fundamentally, we are still modelling a thing which can be given a
> > meaningful
> > name. This is, I think, very different from what I described
> > initially where
> > the "utility" class simply models "Functionality which should be on
> > another
> > class but isn't"
> >
> > Rich
> >
> >
> > On Wednesday 15 May 2002 14:57 pm, Mike Dunbar wrote:
> > > To me, this is brings up an interesting topic and I would love to
> > hear
> > > what others think about it. It reminds me of what someone recently
> > > presented to me as the "classic OO" approach versus a
> > "service-based"
> > > approach.
> > >
> > > They characterized the classic OO approach as putting each business
> > > logic method in the most fitting domain entity class (a domain
> > entity
> > > class being a data-encapsulating class, like Customer). They
> > > characterized the service-based approach as moving all business
> > logic
> > > methods into seperate service classes, and restricting the domain
> > > entity classes to get/set methods for the encapsulated data -like a
> > > JavaBean.
> > >
> > > I'll give a simplified example that will hopefully convey the
> > > difference. Assume a Customer class, containing name, address, etc.
> > > data for a customer. Also assume a getCustomersInRegion(Region r)
> > > method, returning all customers for a given region.
> > >
> > > Classic OO Approach:
> > > Place the get/set methods for name, address, etc. AND the
> > > getCustomersInRegion method in the Customer class.
> > >
> > > Service-Based Approach:
> > > ONLY place the get/set methods for name, address, etc. in a
> > > CustomerBean class, and place the getCustomersInRegion method - and
> > all
> > > other non get/set data methods - in a seperate CustomerService
> > class.
> > >
> > > Now, I consider myself an ardent lover of OO, my education
> > initially
> > > being Bertrand Meyer's OOSC2
> > > (http://www.eiffel.com/doc/oosc/page.html). So, I initially wanted
> > to
> > > stick with alloting business logic methods to appropriate data
> > bearing
> > > classes. Isn't that what OO's about after all - marrying data and
> > > functionality? However, we have tried to more or less adopt this
> > > approach on my current project, and I kind of like it. You still
> > get
> > > benefits like information hiding, polymorphism, etc. The person who
> > > advocated it claims that it facilitates greater reuse, but I have
> > yet
> > > to pin them down for an explanation. Frankly, I don't see it
> > myself.
> > >
> > > So, I beg for some other opinions on this!
> > >
> > > TIA,
> > > Mike
> > >
> > > --- "Richard S.Martin" <[EMAIL PROTECTED]> wrote:
> > > > First, thanks for sharing this. I'm sure many people will find
> > > > methods of
> > > > your class useful.
> > > >
> > > > Second, from a design point of view I have a personal hatred of
> > > > "utility"
> > > > classes like this which simple serve as a collection of public
> > static
> > > > methods. There are very few occasions where this is appropriate,
> > but
> > > > mostly
> > > > it is an excuse to lapse into old procedural-style coding habits.
> > > >
> > > > One tends to end up with a class which doesn't "belong" very well
> > > > anywhere
> > > > and provides functionality which should really be on the class it
> > is
> > > > intended
> > > > to supplement.
> > > >
> > > > It is usually much better to use a Wrapper around the class whose
> > > > functionality you want to extend, which simply passes through
> > > > existing
> > > > methods and handles the extended functionality.
> > > >
> > > > Rich
> > > >
> > > > On Wednesday 15 May 2002 11:08 am, you wrote:
> > > > > Hi guys,
> > > > > Hope this helps to solve many problems using dates. Expect
> > your
> > > >
> > > > esteemed
> > > >
> > > > > suggestions and comments for my improvement.
> > > > > i could not send more than 100 lines. so i am sending the file
> > as
> > > >
> > > > 2 parts.
> > > >
> > > > > import java.util.Date;
> > > > > import java.util.Calendar;
> > > > > import java.text.SimpleDateFormat;
> > > > > public class DateService {
> > > > > public final static SimpleDateFormat dateFormatter = new
> > > > > SimpleDateFormat("yyyy-M-d");
> > > > > public final static SimpleDateFormat timeFormatter = new
> > > > > SimpleDateFormat("HH:mm");
> > > > > public final static SimpleDateFormat dateTimeFormatter = new
> > > > > SimpleDateFormat("yyyy-M-d HH:mm");
> > > > > public static Date addDays(Date date, int days){
> > > > > Calendar cal =
> > > >
> > > > Calendar.getInstance();cal.setTime(date);cal.add(cal.DATE,
> > > >
> > > > > days);return cal.getTime();
> > > > > }
> > > > > public static Date addMonths(Date date, int months){
> > > > > Calendar cal = Calendar.getInstance();cal.setTime(date);
> > > > > cal.add(cal.MONTH, months);
> > > > > return cal.getTime();
> > > > > }
> > > > > public static Date addYears(Date date, int years){
> > > > > Calendar cal =
> > > >
> > > > Calendar.getInstance();cal.setTime(date);cal.add(cal.YEAR,
> > > >
> > > > > years);
> > > > > return cal.getTime();
> > > > > }
> > > > > public static Date convertFromSqlDate(java.sql.Date date){
> > > > > return new Date(date.getTime());
> > > > > }
> > > > > public static java.sql.Date convertToSqlDate(Date date){
> > > > > if (date == null) return null;
> > > > > return new java.sql.Date(date.getTime());
> > > > > }
> > > > > public static String format(Date date, String simpleFormat)
> > throws
> > > > > InvalidDateException{
> > > > > try{
> > > > > return new
> > > >
> > > > SimpleDateFormat(simpleFormat).format(date);
> > > >
> > > > > } catch (Exception e){ }
> > > > > }
> > > > > public final static Date getCurrentTime() {
> > > > > return Calendar.getInstance().getTime();
> > > > > }
> > > > > public static Date getDate(int yy, int mm, int dd) throws
> > > > > InvalidDateException{
> > > > > if (yy < 100)
> > > > > yy += 1900;
> > > > > try {
> > > > > Calendar cal =
> > > > > Calendar.getInstance();cal.clear();cal.set(Calendar.DATE, dd);
> > > > > cal.set(Calendar.MONTH, mm -
> > > >
> > > > 1);cal.set(Calendar.YEAR, yy);
> > > >
> > > > > return cal.getTime();
> > > > > }catch (Exception e){
> > > > > StringBuffer msg = new StringBuffer(10);
> > >
> > >
> >
>
msg.append(yy);msg.append('/');msg.append(mm);msg.append('/');msg.append(dd
> > >
> > > > >) ;
> > > > > }
> > > > > }
> > > > > public static Date getDate(String date) throws
> > InvalidDateException
> > > >
> > > > {
> > > >
> > > > > try {
> > > > > return dateFormatter.parse(date);
> > > > > } catch (java.text.ParseException pe) {
> > > > > throw new InvalidDateException(pe.getMessage(),pe);
> > > > > }
> > > > > }
> > > > > public static Date getDate(String yy, String mm, String dd)
> > throws
> > > > > InvalidDateException{
> > > > > try {
> > > > > int y = Integer.parseInt(yy); int m =
> > > > > Integer.parseInt(mm);
> > > > > int d = Integer.parseInt(dd); return
> > > >
> > > > getDate(y,m,d);
> > > >
> > > > > }
> > > > > catch (NumberFormatException e) {
> > > > > StringBuffer msg = new StringBuffer(10);
> > >
> > >
> >
>
msg.append(yy);msg.append('/');msg.append(mm);msg.append('/');msg.append(dd
> > >
> > > > >) ;
> > > > > }
> > > > > }
> > > > > public static int getDay(Date date) throws
> > InvalidDateException{
> > > > > try {
> > > > > Calendar cal =
> > Calendar.getInstance();cal.clear();
> > > > > cal.setTime(date);return
> > cal.get(Calendar.DATE);
> > > > > } catch (Exception e) {}
> > > > > }
> > > > > public static int getHour(Date date) throws
> > InvalidDateException{
> > > > > try {
> > > > > Calendar cal = Calendar.getInstance();
> > > >
> > > > cal.clear();
> > > >
> > > > > cal.setTime(date);return
> > > >
> > > > cal.get(Calendar.HOUR_OF_DAY);
> > > >
> > > > > } catch (Exception e) { }
> > > > > }
> > > > > public static int getMinutes(Date date) throws
> > > >
> > > > InvalidDateException{
> > > >
> > > > > try {
> > > > > Calendar cal =
> > Calendar.getInstance();cal.clear();
> > > > > cal.setTime(date);return
> > cal.get(Calendar.MINUTE);
> > > > > } catch (Exception e) { }
> > > > > }
> > > > > public static int getMonth(Date date) throws
> > InvalidDateException {
> > > > > try {
> > > > > Calendar cal =
> > Calendar.getInstance();cal.clear();
> > > > > cal.setTime(date);return
> > cal.get(Calendar.MONTH) +
> > > >
> > > > 1;
> > > >
> > > > > } catch (Exception e){}
> > > > > }
> > > > >
> > > > > Regards
> > > > >
> > > > > Ramesh Kesavanarayanan
> > > > > [EMAIL PROTECTED]
> > >
> > >
> >
>
===========================================================================
> > >
> > > > > To unsubscribe, send email to [EMAIL PROTECTED] and include
> > in
> > > >
> > > > the body
> > > >
> > > > > of the message "signoff EJB-INTEREST". For general help, send
> > > >
> > > > email to
> > > >
> > > > > [EMAIL PROTECTED] and include in the body of the message
> > > >
> > > > "help".
> > >
> > >
> >
>
===========================================================================
> > >===
> > >
> > > > This email and any files transmitted with it are confidential and
> > > > intended solely for the use of the individual or entity to whom
> > they
> > > > are addressed. All information is the view of the individual and
> > not
> > > > necessarily the company. If you are not the intended recipient
> > you
> > > > are hereby notified that any dissemination, distribution, or
> > copying
> > > > of this communication and its attachments is strictly prohibited.
> > If
> > > > you have received this email in error please notify:
> > > > [EMAIL PROTECTED]
> > >
> > >
> >
>
===========================================================================
> > >===
> > >
> > >
> > >
> >
>
===========================================================================
> > >
> > > > To unsubscribe, send email to [EMAIL PROTECTED] and include
> > in
> > > > the body
> > > > of the message "signoff EJB-INTEREST". For general help, send
> > email
> > > > to
> > > > [EMAIL PROTECTED] and include in the body of the message
> > "help".
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > LAUNCH - Your Yahoo! Music Experience
> > > http://launch.yahoo.com
> > >
> > >
> >
>
===========================================================================
> > > To unsubscribe, send email to [EMAIL PROTECTED] and include in
> > the body
> > > of the message "signoff EJB-INTEREST". For general help, send
> > email to
> > > [EMAIL PROTECTED] and include in the body of the message
> > "help".
> >
> >
>
============================================================================
==
> > This email and any files transmitted with it are confidential and
> > intended solely for the use of the individual or entity to whom they
> > are addressed. All information is the view of the individual and not
> > necessarily the company. If you are not the intended recipient you
> > are hereby notified that any dissemination, distribution, or copying
> > of this communication and its attachments is strictly prohibited. If
> > you have received this email in error please notify:
> > [EMAIL PROTECTED]
> >
> >
> >
>
============================================================================
==
> >
> >
>
===========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in
> > the body
> > of the message "signoff EJB-INTEREST". For general help, send email
> > to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> LAUNCH - Your Yahoo! Music Experience
> http://launch.yahoo.com
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
