-2

One of NASA's coding rules for writing safety critical programs is:

Declare data objects at the smallest possible scope

My question is, what if I have a large data object that I would like to pass around. Should I parse the object to a smaller object whenever it goes out of scope (e.g. package-level)? What if it needs to be passed to multiple packages? Do I have to create a package-level object every time?

EDIT: To clarify, I was referring to POJOs, perhaps obtained by deserializing an API response. All this time I've been making POJO classes with public fields.

geft
  • 615
  • 1
  • 6
  • 18
  • What exactly do you mean by the data object being "large" and is size relevant to this design principle? – Thilo Apr 22 '17 at 08:35
  • 1
    I think you have misunderstood the rule -size of the data object has nothing to do with it – Joni Apr 22 '17 at 08:36
  • @Thilo I understand that they want the object to preferably have the private modifier, but my concern is if you need the data to be passed around multiple packages. If it's small I can easily extract 1 or 2 objects, but what if it's large enough that parsing into smaller objects is difficult? Dealing with a package-level data object becomes difficult if you need it in another package and it has many fields (say, 15?). – geft Apr 22 '17 at 08:44
  • How is breaking one object into 15 objects an improvement? Doesn't it make the problem even worse (because now the client code needs to know how to assemble it back, hence tightening coupling between modules)? – Thilo Apr 22 '17 at 08:51
  • What do you mean by "package-level data object"? And why would the number of fields have anything to do with how difficult it would be to "deal with" it in another package? – Kevin Anderson Apr 22 '17 at 08:56
  • 1. There is no such thing as a public data object in Java. 2. See (1). Your question doesn't make sense. If you need to pass your object around, the places you need to pass it to *define* the scope it should be declared at. – user207421 Apr 22 '17 at 09:18
  • Maybe I could be more clear. I was referring to POJOs, perhaps obtained by deserializing an API response. – geft Apr 22 '17 at 12:24

1 Answers1

1

Clearly, if objects of a certain class must be manipulated in different packages then either the class itself or some interface it implements must have public visibility. But that doesn't mean you need to expose every little detail about the class to public scrutiny or interference. The rule is just saying that you should not, nay, must not, expose every little detail.

Obviously some details must be publicly visible or else the class wouldn't be too useful. But there are almost always some other details which are none of the public's business, and the rule is telling you that you need to identify which details are which and not make public those details which are, in fact, none of the public's business.

The rule also relates to scope of variable declarations: declare things in the smallest scope possible. For example, if you need a variable to hold onto a result temporarily, declare a local variable inside the method where it is needed: 

// YES
public class C {
    private void meth1(){
        int x = ...
    }
}

not an instance variable in the containing class:

// NO!
public class C {
    private int x;    // an even worse sin would have been to make x public

    private void meth1() {
        x = ...
    }
}
Kevin Anderson
  • 4,568
  • 3
  • 13
  • 21