oop - Why setters are bad in interfaces? -

why setters bad in interfaces if speaking domain objects?

clarification:

i have domain object stores in db. has several fields costly set. i.e.

class jurasicpark {    private long area;    ...other fields ...    getters , setters    ....    private collection<dinosaur> dinosaurs;   private collection<exotictree> flora;    public collection<dinosaur> getdinosaurus(){       ...   }    public collection<exotictree> getflora(){       ...   }   } 

fields dinosaurs , flora costly init , set. in many cases don't need fields set every time.

the problem if return user instance of jurasicpark class dinosaurs or flora don't initialized fill lead either npe or expection throw myself. don't want make api user think , remember fields may not set.

so solve thought creating 2 interfaces ijurasicpark , ifulljurasicpark first declare access methods simple fields, former declare access methods flora , dinosaurs fields.

   interface ifulljurasicpark extends ijurasicpark      class ijurasicpark implements ifulljurasicpark 

in approach ijurasicpark interface contain getters , setters, asks design bad one?

i don't want implement in hibernate style lazyinit exceptions.

who told that? not true in general.

it may true in cases, property in question should not modified external parties. e.g. interface of immutable class surely must not contain setters.

it true 1 should think when designing interfaces, instead of blindly autogenerating getters+setters properties of class. not mean setters bad.

update after clarification of question

your clarification changes question completely... have saved yours , others' time starting question right away. although no complaints part - got lot of (undeserved) upvotes :-)

so problem initializing / setting costly collection properties in domain object. first approach indeed lazy load / save, can implemented in lot of different ways depending on context.

your post suggests (but not state explicitly) collections in question fetched / persisted db. however, don't mention persistence solution use. neither explain why don't want "hibernate style lazy init" - imho efficient , easy use in cases. if give more details on these, might able provide better answers.

the splitting of interfaces suggest may make sense if jurassicpark object without dinosaurs , flora makes logical sense , usable is. again, difficult judge without more context. seem making design decision based on implementation detail, not idea in general.

if want go way, shouldn't need separate interfaces - define jurassicpark (abstract) base class containing simple members plus accessor methods, subclass class adds heavyweight fields.