Siirry sisältöön
Softagram
  • Etusivu
  • Palvelut
    • Toiminnanohjaus
    • Tekoälypalvelut
    • Tietoturvapalvelut
  • Yritys
  • Ota yhteyttä
  • Uutiset ja oppaat
    • Uutiset
    • Oppaat
  • Tech
  • Kirjaudu sisään
  • Ota yhteyttä
Softagram
      • Etusivu
      • Palvelut
        • Toiminnanohjaus
        • Tekoälypalvelut
        • Tietoturvapalvelut
      • Yritys
      • Ota yhteyttä
      • Uutiset ja oppaat
        • Uutiset
        • Oppaat
      • Tech
    • Kirjaudu sisään
    • Ota yhteyttä

    How to get rid of cyclic dependencies with the help of Softagram Desktop

    Tutorials
  • Kaikki blogit
  • Oppaat
  • How to get rid of cyclic dependencies with the help of Softagram Desktop
  • 15. toukokuuta 2019 kirjoittanut
    How to get rid of cyclic dependencies with the help of Softagram Desktop
    Ville Laitila

    Cyclic dependencies creates technical debt by creating complexity. With Softagram you can refactor your code with proposals how to change the cyclic dependencies from your software. These proposals are made with algorithm that would create fully acyclic model. Note that you naturally should consider the proposed changes one by one, if it make sense to swap the proposed dependencies between the elements.

    First directly to steps to use the funcitonality: 

    1. From Tools->Improve Code and Architecture->Simplify Dependencies, select "Propose Dependency Changes in Current view"

    2. Softagram shows in yellow color what kind of and how many changes needs to be done. Animated gif below:

    Example and bacground for dependency related technical debt

    Sometimes developers maximize re-use and forget to keep the design good. It may lead to difficult situation with two way dependencies and cycles. It naturally makes the software more difficult to change in the future, and also complicates unit testing.

    In practise, the symptoms are that there are not many interfaces used, the state is shared between classes, data is exchanged between classes via static members and getter/setters.

    Also, when doing procedural coding and forgetting the functional paradigm, the design easily gets skewed and difficult to maintain. Mostly this is seen as a huge amount of dependency cycles.

    Example case, Netflix blitz4J project

    This blitz4j case shows that the project suffers from a design that makes it rather static. Every unwanted dependency is related to accessing static members. It seems to be using Singleton pattern for two central classes. This pattern often breaks the good design and makes testing more difficult. See the situation from screenshot below:

    Softagram proposes to change the direction of three dependencies.  These three dependencies go against the good layering that is otherwise well designed in this project. See the picture below with proposed (in yellow) changes:
    ​

    Usually dependency injection or using parameters (and functional programming style) would prevent this kind of problem. Afterwards it might be very difficult or impossible to fix, so this supports the fact that Softagram should be used in the project from the very beginning.
    ​

    Originally published at help.softagram.com

    in Oppaat
    # Softagram Analyzer

    Älyä toiminnanohjaukseen

    Olemme intohimoinen tiimi, jonka tavoitteena on parantaa kaikkien elämää mullistavien tuotteiden avulla. Kehitämme loistavia tuotteita liiketoimintasi ongelmien ratkaisemiseksi. Tuotteemme on suunniteltu pienille ja keskisuurille yrityksille, jotka haluavat optimoida suorituskykynsä.

    Ota yhteyttä

    Softagram Oy
    Ketolanperäntie 469 
    90450 ​Kempele 

    • +358504836173
    • info@softagram.com
    Seuraa meitä
    Copyright © Softagram Oy
    Järjestelmää pyörittää Odoo - Luo ilmainen verkkosivu