DEV Community

Discussion on: Code Smell 147 - Too Many Methods

Collapse
 
mcsee profile image
Maxi Contieri

Hi

Objects have protocols and behavior

Subroutines don't.
This is another Code Smell called 'Helpers'

Collapse
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️

Subroutines don't.

This sentence has more flaws than words and that's kind of impressive.

  1. The "behaviour" is literally a bunch of subroutines
  2. Having behaviour is literally what subroutines are about
  3. How do you think calling subroutines even works if there are no protocols...?
Thread Thread
 
mcsee profile image
Maxi Contieri

hi

1 - The behavior is on the real world objects. I could never have a real world metaphore for a subroutine.
2 - Having behavior is always related to real world objects
3 - I don't do structured programming. So I don't know about subroutines. I am fine with them in structured paradigm.

Thread Thread
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️

 So I don't know about subroutines

So you don't use methods on your objects?

Thread Thread
 
mcsee profile image
Maxi Contieri

of course.

Methods are the way to implement the accidental 'how' and to perform the essential 'what'
An object is what it does.
And methods fullfill the object's contract

Thread Thread
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️

So the contract and the behaviour originate in the real world and manifest themselves in subroutines; then what do we need objects for?

Thread Thread
 
mcsee profile image
Maxi Contieri

Subroutines are fine for programming in the small.
For example a solo work

In order to manage complexity and very large systems you need to follow principles like these

IMHO, You cannot built a serious system based on subroutines.
That was 1950's approach and didn't scale. It was called 'The software crisis'.

And that's the difference between beeing a software engineer and a coder

Thread Thread
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️

I assume you just misunderstand what a subroutine is, because you seem to think they're somehow a different thing than methods. They're not. When you call a method on an object, you're using a subroutine.

And since the behaviour of any object-oriented system is implemented in methods, and the protocols, as you've mentioned earlier, emerge from the real-world objects, not the program objects built to parallel them, you really don't need said objects in your code whatsoever to represent the protocols and behaviour of a real-world system.

Add to that a mechanism to store subroutines in variables and data structures, and you can easily write code in an object-oriented way with just those basic building blocks, as languages like Lua or early JavaScript have shown.