The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

getters/setters confusion...immutable objects

Some people argue not to have getter/setters..I have a simple requirement...user should be able to creat transport packages..which application saves into database..if user wants to change some attributes of a package..app displays that package..user makes changes and then the app saves the updated package..now,without getter how will i display to user..maybe ,use a toString method which returns a string..which then I will have to be split to show in different UI elements..and to change state of an object i will need setters..or..make object immutable..so when user makes changes create a new object with same identity(database)..and then save into database..
Would really like to hear opinions on this aspect..
thks
vishy
Saturday, July 22, 2006
 
 
Avoiding Getter/Setter is hard, extremely hard.  But I don't mean stop trying.

To your question, how do you get data without Getter to display, persist and etc.  An inperfect solution goes like this.

public enum ObjectField
{
  Identity,
  Destination,
  etc.
}

interface IDataCollectable
{
  void ExportData <T> (ObjectField, T value);
}

class DomainObject
{
    private long identity;
    private string destinationName;

    void ExportData(IDataCollectable dataCollector)
    {
        dataCollector.ExportData<string>(ObjectField.Destination, destinationName);
       
        dataCollector.ExportData<long>(ObjectField.Identity, identity); 
    }
}

public DomainObjectVisualView : IDataCollectable
{
    public void ExportData<T>(ObjectField field, T value)
    {
        //
        // As you can see, there will be a lot of
        // conditional branches.  Then you will figure
        // something out to remove the branches. using
        // other patterns.
        //
        if ( field == ObjectField.Destination )
              destinationNameTextBox.Name = value;
    }
}

public DomainObjectDataAcces : IDataCollectable
{
    public void ExportData<T>(ObjectField field, T value)
    {
        if ( field == Objectfield.Destination )
            // Save to the data base
        etc.
    }
}

Essentially, it is a getter but the Domain object decides when and how its data will be exported.  The above example is exporting data one field at a time, maybe you want to do bulk-export.

Warning, It is hard and require disciplines, otherwise you will end up with messy code.

Hope, it'll give you some hints how to proceed.

Saturday, July 22, 2006
 
 
Just use getters/setters.  Anyone who has to work with your code later will thank you.  You're not going to gain much, other than a ton of bugs and a case of carpal tunnel, by hiding your getters/setters behind convoluted ExportData/ImportData interfaces or a toString hack. 

The problem with getters/setters is when they're created indiscriminately for every private data member of a class.  You want to encapsulate behaviors inside classes.  You don't want classes that are just transparent data holders.
SomeBody Send private email
Saturday, July 22, 2006
 
 
There is nothing inherently wrong with getter/setter - just so long as the application fits the usage. And your case it sounds reasonable. There is no reason to try to avoid something that may be an obvious fit.
hoser
Monday, July 24, 2006
 
 
>>>
Some people argue not to have getter/setters..I have a simple requirement...
>>>

Some people will argue about anything that works!

Seriously, what do you think is wrong with getters to access the data within your class?

And you may have a need for setter methods too, in which case include them as well.

Don't reinvent the wheel with a convoluted set of tank tracks, if the wheel does what you need.
John Rutter Send private email
Monday, July 24, 2006
 
 
Eh, save some effort - just use a C style struct. All this architecture astronaut "setter and getter" crap is a waste of time.

Monday, July 24, 2006
 
 
> "setter and getter" crap is a waste of time.

Screw that. Just use a binary buffer and cast in and out of it.
son of parnas
Monday, July 24, 2006
 
 
One of the reasons that it's difficult to dispense with getters and setters in common OO languages is due to the lack of multiple inheritance.

A common approach to design when multiple inheritance is present is to create base classes that implement raw model behaviors.  These classes are generally generic in the sense that they don't really depend on application context very much.  Next, these classes are extended to implement application/context specific versions of those classes.  These subclasses will extend other base classes as well, such as widget, DBRecord, etc.  The subclasses are then both Domain objects and also widgets - they can display themselves using the display mechanism of the application. They can also accept input using whatever mechanism the application uses (HTML, command line, Form controls, etc).  The application uses a Factory to generate the proper context-specific subclass.

This drives the need for getters and setters down drastically - all the common reasons for pushing and pulling data are handled by the objects themselves, rather than smearing the behaviors out into a bunch of different cooperating objects.

I don't have a lot of experience with this kind of implementation, so I wouldn't be comfortable recommending it as a preferred approach, but it is an option when you have multiple inheritance available.
Code Fogey Send private email
Tuesday, July 25, 2006
 
 
Even Java (and, I believe, C#) has multiple inheritance of interface.

If the concrete implementation class uses a little careful composition of smaller concrete classes, then you can get a good chunk of the benefit of multiple inheritance.

Ok, the design of Java annoys me but if you must use Java then you ought to use it properly.

Tuesday, July 25, 2006
 
 
Interface inheritance doesn't do you much good if the guy that designed the library you want to inherit from didn't build it off of interfaces, though.  Even aside from that, though, trying to copy the implementation of a complicated widget so that you can implement its interface exactly like the "standalone" version of the widget wouldn't be trivial.  It would be much more economical if you could just use it directly, or at least had that option, eh?
Code Fogey Send private email
Thursday, July 27, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz