How much functionality in constructor?

Question

Hi
Lets say I have a class 'schedule' which builds a schedule from a set of data
and then holds that schedule for further processing.
Which of these two options is better designed?:
public class Schedule
     public Schedule(SomeInputs inputs)
          buildSchedule(inputs);
     private buildSchedule(SomeInputs inputs)
          //Schedule is initialized here
     public void doOtherStuffWithSchedule()
}or this :
public class Schedule
     public Schedule()
     public buildSchedule(SomeInputs inputs)
          //Schedule is initialized here
     public void doOtherStuffWithSchedule()
}The first version is simpler to use but the second seems intuitively to make more sense.
Is there a standard that talks about this?
Thanks guys

Answer 1

Aharon wrote:
Actually I think you've touched on my problem more clearly,
ALL the Schedule class does is build a schedule from a complete set of input data (using the buildSchedule method)
and then afterwards it stores this schedule in a database (using the doOtherStuffWithSchedule() method in our example).
Your definition sounds like a DAO
So essentially I could just stick the second db storage method also into the constructor and with that my class would have no public methods, One would just instantiate the class and finished. This just doesn't seem logical to me, should I rather use static methods and no instantiation at all?
Or maybe two classes: One for the Schedule object and another class for a ScheduleFactory object which statically builds schedules. Although I don't like this since surely a class should be in charge of its own data according to OO?
More than anything that probably depends on size. Is there 100 lines, 1000 lines or 10,000 lines of code. If the first then realistically it doesn't matter. If the last then something is probably wrong with the design.
Despite the fact that OO is useful that doesn't alter the fact that there are tasks that lend themselves better, especially for maintenance, to a procedural approach.