Apps Standard convention regarding shared code

[Deleted User]

Hi,

I'm digging into Android and Java here and I've a question regarding code architecture in Java.

(Note: My programming experience is C++ and then .NET, so I'm sure you'll understand)

Say, for whatever reason, I have two Activities with lists that pull and populate from the same table in the application's database. Obviously I want this code modularized.

My gut is telling me, since Java is all about OOP, I'll need to create an object that represents that data and both Activities will just instantiate and use that object.

What I want to do is create a package that contains .java files of common methods modularized out. These .java files don't really represent any particular object (though they may be organized appropriately). They're just a code dump of related methods.

Is the latter strictly against Java ideology? Should I strictly adhere to the former? I want to use whatever method is appropriate for programming in Java, but from programming in C++ and .NET, I've always had common files of code that can be used anywhere.

Thanks for your time,
Andrew

 

[Deleted User]

There's in error in my original post's logic; so I'm going to split this into two questions. One is about data, the other is about generic methods.



Question 1:

Say I want an object to represent data from a particular table in the database. I can do this one of two methods:

1) (the Java way?) Create an object which represents an element (a row) of this set. Member variables would represent each column. Create another object which would have a member variable that is an array of the previous object. This "outer" object would contain the method that gets back a dataset and creates the elements of the array in memory.

2) Create an object which extends some dataset object. Again, the member variables would represent the columns, but there would be functions to traverse each element in the set. (This is what I've traditionally done using ODBC objects in C++ and DataSet/DataTable objects in .NET)

Are both acceptable in Java? I would prefer to use method 2




Question 2:

What about entirely generic functions? Being a C++ programmer, I can't imagine not coming across them. What should I do in this case? Find a way to mold them into an object that actually represents something? Or would it be fine to just create an "object" that's just a conglomeration of generic methods that are used in multiple places.

 

[Deleted User]

The one thing that leads me towards method 1 of the first question is that the application will be web service-heavy. When I pull this information, I'll want something to stuff it into.

 

[markb]

Just to address question 2, as there's another thread for question 1.

If you want some generic functions that don't fit into any particular classes, and aren't part of your object model, then you can put them into separate classes as static methods.

For example, at work I've got a set of utility functions for dealing with strings, dates, maths etc. and I use them in virtually every project. (That's not Android stuff, not that it matters.) I've put them in a separate project, and I add that project as a dependency to my applications. That way I have one shared set of code in one place. If you don't need to share code across projects then you don't have to go that far.

You might put string & date utility functions into classes as folows:

in StringUtils.java

package myapp.utils ;

public class StringUtils
{
  public static boolean isEmpty(String str) { . . . }
  public static String reverse(String str) { . . . }
  public static String[] tokenise(String str, String delimiter) { . . .}
  etc...
}

in DateUtils.java

package myapp.utils ;

public class DateUtils
{
  public static Date lastDateInMonth(Date date) { . . .}
  public static Date firstDateInMonth(Date date)  { . . . }
  public static int dayOfWeek(Date date) { . . . }
  etc...
}

In this case I've put the classes in a package called myapp.utils (to address a point from your other thread).

Mark

 

[Deleted User]

Thanks markb. It's good to know it's ok to have generic classes for common functions. I always hear people hammering in the idea that all Java objects should represent something.

For my first question, could you please point me to that other thread?

Thanks again for your help

 

[markb]

For my first question, could you please point me to that other thread?

I was actually thinking of your other thread about global objects.
But now I re-read your posts in this thread, I think that's probably not answering your question.

In short though....

Are both acceptable in Java? I would prefer to use method 2

I'd say both are acceptable. It's more of an OO design question, and I think C++ and Java would share the same common OO approach. So the way you do it in C++ will be ok in Java.

Mapping a relational DB to objects is not a trivial topic (as you'll already know), and there are many approaches. If you already know an approach that works for you, I'd stick with it.

Mark

 

[Deleted User]

All right, sounds good.

Thank Mark