Win a copy of JDBC Workbook this week in the JDBC and Relational Databases forum
or A Day in Code in the A Day in Code forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
  • Piet Souris
  • salvin francis
  • fred rosenberger

Mikado and Lakos

author and iconoclast
Posts: 24203
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Have you guys read John Lakos "Large-Scale C++ Software Design?" For those that haven't, it's essentially a whole book about physical dependencies in software, and how to write code that can be separately compiled without spaghetti dependencies. In a sense, it describes alla prima strategies for getting to the end state Mikado is shooting for. If you've read the book, care to comment on the relationship? Does Mikado help you guide your system towards Lakos' ideal physical design?

Note: Amazon seems to indicate that a new edition of this rather dated book is due out soon!
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

We have not read that book, probably because we haven't worked with C++. :-)

As Ola has stated in one of the threads here, the Mikado Method helps you find what is stopping you and keep track of your change path (graph) to achieve a goal. The direction in which to take your codebase is up to you, speaking strictly Mikado Method.

But, we thought it would be evil to just leave our readers with that ;-) so in part II of the book, we do have a chapter where we talk about the things that has helped us immensely when restructuring (OO) code: Design principles. Low coupling, high cohesion, SOLID and the package principles, DRY, and more.

Looking at for instance SOLID and the packaging principles, they are what usually makes us avoid changes to ripple through the code base, making it possible for a large system to compile fast. We don't go into great detail, but we explain the basics and some smaller examples of what it might look like, in packages and in Mikado Graphs.

If Lakos takes the code in some other direction, you can use that direction when deciding how to resolve what is stopping you.

I hope that was some sort of comment on the matter. :-)
Can you really tell me that we aren't dealing with suspicious baked goods? And then there is this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!
    Bookmark Topic Watch Topic
  • New Topic