Maxi Contieri

Posted on Oct 4, 2021 • Originally published at maximilianocontieri.com

Code Smell 89 - Math Feature Envy

#oop #webdev #cleancode #tutorial

One class calculating formulas for another class.

TL;DR: Leave the formulas to the objects gathering the information.

Problems

Declaratively
Low reuse
Real-world concept missing
Encapsulation

Solutions

Move the math formula to the class
Search for real-world abstractions

Sample Code

Wrong

function area(rectangle) { 
  return rectange.width * rectangle.height;
  //Notice we are sending consecutive messages to
  //the same object and doing calculations
}

Right

class Rectangle {
    constructor(width, height, color) { 
         this.height = height;
         this.width = width;
    }

    area() {
        return this.width * this.height;
    }
}

Detection

Since many cascading messages are sending to the same object, we can detect a pattern.

Conclusion

This is a very basic smell. If we are manipulating another object characteristics, we should let it do it the maths for us.

Relations

Code Smell 63 - Feature Envy

Maxi Contieri ・ Mar 23 '21

#codenewbie #programming #oop #webdev

More Info

The one and only one software principle

Credits

Photo by Michal Matlon on Unsplash

Computer science is not about machines, in the same way that astronomy is not about telescopes. There is an essential unity of mathematics and computer science.

Michael R. Fellows

Software Engineering Great Quotes

Maxi Contieri ・ Dec 28 '20

#codenewbie #programming #quotes #software

This article is part of the CodeSmell Series.

How to Find the Stinky parts of your Code

Maxi Contieri ・ May 21 '21

#codenewbie #tutorial #codequality #beginners

Top comments (4)

James Robb • Oct 5 '21 • Edited

I suppose it depends on the implementation, for example:

function rectangularArea(rectangle) { 
  return rectangle.width * rectangle.height;
}

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;
}

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();
}

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

Maxi Contieri • Oct 5 '21 • 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)

James Robb • Oct 6 '21

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?

Maxi Contieri • Oct 6 '21

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

DEV Community