Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
On my first attempt to create a program that's too big to fit into one source file, I keep running into problems with separating it into several. For example, what should I do if one module is to be used by several other modules, which end up being included into one another. Say, linear_algebra.cpp (or .py or whatever) requires tensor_operations.cpp, and they both require matrix_operations.cpp. Should I include matrix_operations.cpp into both other files, or just into one or what? And what if then I add matrix_operations into some other module, that on some point suddenly turns up requiring linear_algebra as well?
This whole business keeps confusing me constantly. Sometimes I figure it out, but there has to be a "proper" way, so that you don't have to figure out by yourself.
So, where can I get a manual on how to do this sort of stuff properly (or at least what do they call it, because google does not understand me when I say "this sort of stuff")?
It sounds like you're trying to avoid cyclic dependencies, which is the key term you want to search for.
For example if you have modules A and B and you find that A needs to refer to B and B needs to refer to A then you have a cyclic dependency between A and B. (In other words, if you drew the relationships between modules as a graph with arrows showing the dependencies, there would be a pair of arrows between A and B.)
The solution is to identify the bit of code in A that's needed by B, refactor that bit out into a new module C and then refer to C from both A and B. (This means that B doesn't need to refer to A any more.)
So you go from
A <----> B
to
A -----> B
| |
\/ |
/ |
C ------
\
By doing this, you go from a few large modules to many smaller modules with looser coupling between them. This, in turn, should make your code easier to maintain and reuse.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Rakudo Star is a release targeted towards end users (if I'm not mistaken). As such, it includes a number of useful modules that can be used in a wide range of projects.
But how does the team behind it decide which modules to include? Do module developers talk to them and ask for inclusion, or do they look at usage statistics and include the most popular? Or is inclusion completely arbitrary?
What process should one go through to get their module included?
The collection of modules is in the star repository, includes as sub-modules of the repo. I haven't seen any kind of description of what modules are installed there and why, but I guess using the issues and/or pull requests is the way to go. In fact there's this closed issue which points in that direction, including a reference to ecosystem statistics, so I guess regarding your three questions.
There's no established procedure that I have been able to see.
Apparently, they look at statistics, after some developer asks for them.
I don't think that's the case. They at least have to pass all the tests in all platforms to be included. Also, I don't think my evolutionary algorithms module will be included any time soon.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Just to be clear, I'm not asking how to add dependencies in a README.md, but rather, how to handle documenting them given my situation.
Looking at the SO Help Center, I saw this as "a practical, answerable problem that is unique to software development," and I thought it appropriate to ask here.
I need some guidance on a project. To summarize... The project is a technology prototype for a small business, which I'll call "ACME," which contracted with me, and is using Raspberry Pis as a distributed client network to provide a service to their customers. The ACME's owner is not technical. He emphasized simplicity, extensibility, and stability for the project, and I want to avoid unnecessary confusion.
Where I'm becoming concerned is that while my direct dependencies are few, about two or three, my sub-dependencies are numerous. (To clarify, I'm coding the project in Node.js, with the exception of a few small C++ worker programs.) The modules I'm working with collectively sum up to about 40 sub-dependencies or greater.
The most important thing to me is to do the right thing, especially with this being my first official job as a developer, and I'm all on my own with no senior developer to advise.
So... should I only list my direct dependencies (which I would prefer, and which handle documenting their dependences themselves), or list all dependencies?
npm can list your dependencies just fine by itself (npm ls). What you need to document is how to get the system up and running, both as a user and as a developer (your successor or yourself in the future when you need to restore your dev setup from scratch).
EDIT: Additionally you will want to document how your own programs fit together as components in the whole system.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'm currently developing a school project and we are instructed that we are required to implement Object-Oriented Programming concepts in our software. But I don't want to implement it just by simply inheriting this class to that class and overriding this method to implement its own functionality and so on. Though it is still acceptable but I want to do it differently. By differently, I mean by using design patterns. I'm trying to understand it one by one and I noticed that some of them are very useful(Builder, Memento and Adapter). But the problem is there are so many of them and if possible I want to put/implement it all(those 3 design pattern). Is it okay if I do that? Would it mess up the project as a whole?
As always: It depends.
Overusage of patterns on small and simple bits of code can obscure the code. But it can also make it more clear.
Don't use patterns wherever possible. Use them when it serves a purpose. Every pattern has its purpose and if you can't find that purpose in your code, you shouldn't rewrite it to match a pattern. Try to keep your code a) maintainable and b) easy to read. If a pattern fulfills these criteria more than your approach without patterns: go for it.
You can have code with dozens of patterns and code with none. In both cases it can be the ideal choice.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
So, I just started a new job a few weeks back. It is my first job doing software, and I have been tasked with learning how a giant project works. Now, the guy before me left NO (zilch) documentation or comments anywhere in the source code. In addition, he applied basically EVERY design pattern in the famous design patterns book by Gamma, etc...
My question is, how do I start? I have tried setting break points for certain calls that I want to learn (learn bit by bit), but because of the 5 million design patterns employed, every call goes up about 7 levels just to finish, and by then, it's hard to keep track of the 20 some objects being created and used.
Has anyone had a similar experience? A few pointers on different methods to try?
Specs: language - VB.net
IDE - Visual Studio 2010
Using - Windows Forms
Brain - Melting
Inheriting a large project without documentation is always a huge pain in the ass. I hope you have already accustomed your manager to the inconvenient truth that it will take several weeks or even months until you can maintain that project efficiently.
I would start with creating some UML class diagrams. That could tell you a lot about how the system works and which design patterns are used where.
While doing so, I would also add comments to the code with everything I learned about it. When I am not sure if I understood what the code does correctly, I would add a common string like "NOT_SURE" to the comment. Later, when I have a better understanding of the system, I could use a text search to find and revise these comments.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I am not quite sure if this question is relevant here; maybe it's too high level.
Say I have an interface Foo which is implemented by two other concrete classes FooProduction and FooTest. The first one is the production code and the other one the test implementation. Now I want to package everything up but I am not sure which is more suitable. Moving the FooTest class in the test package (where I keep all my tests) or keeping Foo, FooProduction and FooTest in the another package, lets say the foo package?
I would say that making sure FooTest can never find it's way onto a production machine would be the highest priority. As such my vote would be for dividing things along the Test/Production boundary.
I don't know what language you're actually implementing, but in the Java world, the Maven software management system is extremely popular and generally well-regarded, and it makes extremely strong distinctions between so-called "main" and "test" code, resource files, and dependencies. Indeed in their documentation they indicate this is a "testing best practice".
As to where to put the interface Foo and its FooProduction implementation, that's really a question of personal (or site) preference. I like having a package that holds all the domain model objects together for example.
FooTest should be in a separate package than the production code
Whether or not IFoo and FooProduction should go on the same package or on two separate ones depends on the variability of FooProduction (how many implementations are you looking for in the future)