DEV Community

Discussion on: Code Smell 89 - Math Feature Envy

Collapse
 
jamesrweb profile image
James Robb • Edited

I suppose it depends on the implementation, for example:

function rectangularArea(rectangle) { 
  return rectangle.width * rectangle.height;
}
Enter fullscreen mode Exit fullscreen mode

This is perfectly fine code for me as it describes what the area is for.

Using a type system allows us to enforce this also:

type Rectangle = { width: number, height: number };

function rectangularArea(rectangle: Rectangle) { 
  return rectangle.width * rectangle.height;
}
Enter fullscreen mode Exit fullscreen mode

We could even enforce behavioral logic on the type if we really wanted to:

type Shape = { area: () => number };
type Rectangle = Shape & { width: number, height: number };

function rectangularArea(rectangle: Rectangle) { 
  return rectangle.area();
}
Enter fullscreen mode Exit fullscreen mode

Interested to hear your thoughts on this kind of direction though, is it too much or too little or causing other smells potentially?

Collapse
 
mcsee profile image
Maxi Contieri • Edited

You are using an external function, stripping object accidental properties and performing calculations outside of it. this violates reuse, information hiding principle, class cohesion and encapsulation.

The area is what the rectangle points out. not an external function.
You are confusing data (accidental) with behavior (essential)

Collapse
 
jamesrweb profile image
James Robb

Can you give an example of each case you mentioned and a suitable resolution in your opinion?

What about in functional languages, how should this be approached there in your opinion?

Thread Thread
 
mcsee profile image
Maxi Contieri

Hi again

Thanks for the comment.
I am not an expert on Functional Programming.
I'll stick to OOP, my area of knowledge.
Calculating the area of a shape (and how it does) it is shape's reposibility.
Example is on the article above.
Doing external manipulations is a code smell, according to my opinion