2

Is it a sign that something is wrong with the code design if you end up with a layer of functions that just forward request to a component? Exposing the component would avoid this but hurts encapsulation.

An example in a C++ like language.

class AnimalManager
{
    public:
    int GetNumAnimalsOfType(EAnimalType AnimalType) { return 77; }
// Other animal related stuff

}

class Zoo { public: int GetNumAnimalsOfType(EAnimalType AnimalType) { return m_AnimalManager.GetNumAnimalsOfType(); }

private: AnimalManager m_AnimalManager;

// Other Zoo related stuff

}

gjcapl
  • 29

2 Answers2

3

I see this most when people add a layer which might be best practice, but they dont have enough logic to fill it out.

eg in a MVC design

MyController 
{
   GetThings() { return myService.GetThings(); }
}
MyService
{
   GetThings() { return myRepository.GetThings(); }
}
MyRepository
{
   GetThings() { return myOffTheShelfDAL.Get<Thing>("select * from thing"); }
}

So yeah, best practice says all these layers are good, maybe you will fill them out some day, maybe you are just doing them from muscle memory and its not taken any more time. You cant say its bad per-se. But is the same app had had been written with...

MyController 
{
   GetThings() { return myOffTheShelfDAL.Get<Thing>("select * from thing"); }
}

No-one would be saying "Oh! you need a service layer and a repository!!"

Ewan
  • 83,178
3

You cannot make this judgement by looking at the AnimalManager and Zoo classes alone. If AnimalManager is used in other classes, the logic in that class may have originated in Zoo, but was refactored into another class to promote code reuse.

If AnimalManager is only used in Zoo, then yes, it is useless boilerplate code. Any code depending on Zoo is dealing with the abstraction that Zoo provides, which makes AnimalManager an implementation detail transparent to code outside Zoo.

Then again, if AnimalManager has non-trivial logic that reaches out to a database, file system or web service, and the purpose of Zoo is to provide an abstraction that separates other code from data access logic, then what you call boiler plate might be a necessary separation of concerns for code outside Zoo and AnimalManager.

So, this could be a bad design or a good design. Either way, you need to look at the entire Zoo and AnimalManager classes, as well as classes using Zoo and AnimalManager before making this determination.