Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Context: Student working through Class design in personal/side project for Summer. I've never written anything implemented by others or had to maintain code. Trying to maximize encapsulation and imagining what would make code easy to maintain.

Concept: Tight/Loose Class design where Tight and Loose refer to access modifiers and constructors.

Tight: initially, everything, including setters, is private and a no-arg constructor is not provided (only a full constructor).

Loose: not Tight

Exceptions: the obvious like toString

Reasoning: If code, at the very beginning, is tight, then it should be guaranteed that changes, with respect to access/creation, should never damage existing implementations. The loosening of code happens incrementally and must be thought through, justified, and safe (validated).

Benefit: Existing implementing code should not break if changes are made later.

Cost: Takes more time to create.

Since this is my own thinking, I hope to get feedback as to whether I should push to work this way. Good idea or bad idea?

share|improve this question
The principles are good, though you should (imo) favor parameterless constructors where it makes sense. It's often beneficial to have some known sane default state for all objects since many times you don't need your invariants set based on input on construction. – Telastyn May 10 '12 at 19:25
Good enough - thanks! – yas May 12 '12 at 2:24
Many tools require no-argument constructors, e.g. Guice. – user1249 Jun 27 '12 at 9:47
up vote 0 down vote accepted

Keep your public API a small as possible. Don't expose setters to class members unless you absolutely have to. Don't implement features you think may become useful in the future (this often leads to feature bloat).

share|improve this answer
keeping public API small is a better way to put it than mine. Thanks for the answer. – yas Jun 28 '12 at 15:08

Tight coupling is when a group of classes are highly dependent on one another.

Let us see tight coupling between java objects first, take an example..

class Traveler
    Car c=new Car();
    void startJourney()


class Car
  void move()
     // logic...

In the above example, Traveler object is depends on car object. So traveler class creating an object of Car class inside it

If the other class object is created in the dependent class, there exist tight coupling, I mean if method in car object is changed then we need to do the changes in the Traveler class too so its the tight coupling between Traveler and Car class objects.

Loose coupling is achieved by means of a design that promotes single-responsibility and separation of concerns.

A loosely-coupled class can be consumed and tested independently of other (concrete) classes.

Interfaces are a powerful tool to use for decoupling.

Let us see loose coupling between java objects, take an example..

In order to over come tight coupling between objects, spring framework uses dependency injection mechanism with the help of POJO/POJI model and through dependency injection its possible to achieve loose coupling

In the above example Traveler , Car are tightly coupled. If we want to achieve loose coupling between the objects Traveler and Car, we need to re-write the application like….

class Traveler
    Vehicle v;
    public void setV(Vehicle v)
      this.v = v;

    void startJourney()
share|improve this answer
The use of Interfaces as a means of decoupling is a way of seeing it I haven't had before - thanks for that. However, I wasn't refering to coupling in using "tight" or "loose"; I was refering to exposure of members. – yas Jun 28 '12 at 15:05

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.