Conversation

Notices

1. Borutzki (borutzki@mastodon.social)'s status on Thursday, 04-Apr-2024 22:55:08 JST Borutzki

   in reply to

   So, you know what I'll do with that?

   I'll probably stick with this huuuuge class. It's already simple and complicated at once. And seems like I can only sacrifice "simple" without reducing complexity.

   All in all, it seems better to have it all in one class and go `CTRL+F` in my IDE (or use autocompletion) instead of creating structures that may result in some smaller classes, with no reasonable explanation for these classes other than "their smaller".

   • Borutzki (borutzki@mastodon.social)'s status on Thursday, 04-Apr-2024 22:55:08 JST Borutzki

     in reply to

     Of course I'm open to new ideas that fedipeople may give me on that. If you have any - let's share experiences. I've already shared mine ;)

     #python #programming #softwarearchitecture

   • Kuba Orlik (kuba@toot.kuba-orlik.name)'s status on Thursday, 04-Apr-2024 22:55:08 JST Kuba Orlik

     in reply to

     @borutzki How complex is the internal state? I'm thinking maybe to create a "state" class that would be passed to each of the method, and that method would return a modified state, and you would pass the state around. Seems easier to test.

     Or maybe implement it as a finite state machine?

   • Borutzki (borutzki@mastodon.social)'s status on Thursday, 04-Apr-2024 22:55:09 JST Borutzki

     in reply to

     Okay, so composition is there and inheritance adds no value. Then what?

     At first, I thought: maybe some more "pro", like mixin classes? Well, this would not only add the burden of subclassing but also make me explain my colleagues what do I mean with "this class won't work on its own".

     Maybe I could split the class into independent classes?

     Maybe - but this still similar code, using the same API underneath, but now it has multiple names and connect/disconnect methods.

   • Borutzki (borutzki@mastodon.social)'s status on Thursday, 04-Apr-2024 22:55:09 JST Borutzki

     in reply to

     Now you see where it goes. I have one huuuuge class with 1500 lines of code and corresponding unit test file similar in size.

     And all options to change it, are "complicate it more so it may seem simpler".

     You see where it goes? To adding additional layer of abstraction to achieve nothing.

   • Borutzki (borutzki@mastodon.social)'s status on Thursday, 04-Apr-2024 22:55:10 JST Borutzki

     in reply to

     So the first solution was: "let's play with composition".

     But there is no way to get it well at composition. I already have this API class that is an internal object of my class, and all methods in my class touch this internal class.

     And this internal API class is also a huuuuge (~2000 lines) class which I am not the owner of.

     So, composition here is probably not a good advice, as it already is on the board...

   • Borutzki (borutzki@mastodon.social)'s status on Thursday, 04-Apr-2024 22:55:10 JST Borutzki

     in reply to

     Well, "if not composition, then maybe inheritance". I thought.

     Then I started doing this kind of refactor, like splitting methods into separate classes, based on functionality.

     And guess what - I've achieved nothing. Like, I still have to share the same internal state, but now I have e.g. 4 different big classes and one kind of "god object" that subclasses them all.

     Basically, there is no added value, because code is the same and I've only added inheritance to existing composition.

   • Borutzki (borutzki@mastodon.social)'s status on Thursday, 04-Apr-2024 22:55:11 JST Borutzki

     Ah, let me share with you that weird thought process I was into today.

     So, there's that huuuuge class (~1500 lines) in our repository. It's a wrapper for some API that may be used in another API - kind of layer of abstraction, with some simple data operations in between (like translating names and variables).

     My starting point was: how can I get this huuuuge class split across multiple smaller classes?

     #python