It is acceptable if the copied code can change independently from the original code.
If you are copying code and every future change has to be maintained in two different code bases, you could better create a shared library. Then both applications have a dependency on the library, but not on each other.
Libraries and dependencies are like persons and relatives: One is just an entity (something), the other is a relational entity.
I am a person. My niece is also a person. But to her, I'm a relative. You cannot simply be a relative by nature; you're always a relative of someone else.
Similarly, a code library becomes a dependency only when another project ...
... We are forced to stay on the lowest API level of the framework (.NET Standard) …
This to me highlights the fact that, not only are you potentially restricting yourselves too much, you may also be heading for a nasty fall with your approach.
.NET Standard is not, and never will be "the lowest API level of the framework". The most restrictive set of APIs ...
Use dependency injection, but whenever your constructor argument lists become too big, refactor it using a Facade Service. The idea is to group some of the constructor arguments together, introducing a new abstraction.
For example, you could introduce a new type SessionEnvironment encapsulating a DBSessionProvider, the UserSession and the loaded ...
We are forced to stay on the lowest API level of the framework (.net standard). The reasoning behind this is that a new platform could one day arrive that only supports that very low API level.
The reasoning here is rather backwards. Older, lower API levels are more likely to become obsolete and unsupported than newer ones. While I agree that staying a ...
If an application uses a library, the application has a dependency on that library.
Libraries are not the only type of dependency an application can have. Software can also depend on:
So 'dependency vs library' is like 'fruit vs apple'. Libraries are one type of dependency, just as apples are one type of ...
You should generally upgrade dependencies when:
There's an advantage to do so
Not doing so is disadvantageous
(These are not mutually exclusive.)
Motivation 1 ("when you have to") is the most urgent driver. Some component or platform on which you depend (e.g. Heroku) demands it, and you have to fall in line. Required upgrades often cascade ...
It maintains referential integrity (yes but can be maintained without it too)
You are technically correct that if you're able to maintain referential integrity yourself, you don't need the constraint to exist. But by that same logic, you don't need fire insurance as long as your house doesn't burn down, and you don't need health insurance as long as you don'...
For .NET it may depend on the deployment target. .NET 3.5 is supported in even early editions of Windows XP, whereas 4.5 is only supported on Vista and above.
At my workplace we opted to stay on 4.0 because we still have workstations running on Windows XP Pro SP3 (which 4.0 supports). We cannot consider migrating until next year or so just because of that.
Dependecy injection massively swells constructor argument lists and it smears some aspects all over your code.
From that, it doesn't seem like you understand DI proper - the idea is to invert the object instantiation pattern inside of a factory.
Your specific problem seems to be a more general OOP problem. Why can't the objects just throw normal, non-...
This is one of the reasons you're using open-source software, right?
You could make the very same argument for "what happens if my very expensive, proprietary, closed-source library suddenly falls over? Will there be someone available at [large, monolithic software company] to fix it for me?" With open-source software, at least you have the chance to ...
create a one extra project in which all common things are defined
This is the exactly first step to share reusable parts - and its the easy part. The more challenging part is to decide if the two projects which are using the shared library shall have independent release cycles (or not), and if it should be possible that "project A" uses version 1.0 of your ...
In theory it's the best practice to put any significant common piece of code in a separate library that both applications use, rather than duplicating the code across both applications.
In reality I would say the choice is a trade-off between:
Avoid code duplication
Having duplicated code means there's more code that needs to be understood to understand ...
I'd personally go for many small libraries.
Discourages developers from creating dependencies between otherwise unrelated packages.
Smaller more manageable libraries that are much more focused.
Easier to break up and have separate teams manage each library.
Once you have a new requirement that's sufficiently complex, its better to add a new module
"Good enough is the enemy of better." -- Jerry Pournelle
Seriously, there has to be a reason for an upgrade besides just "ooh, shiny!". Among other issues, any time you switch versions of a package your code depends on, you switch out one set of bugs that you're adapted for to another set that you may not be. In the process of switching, you frequently ...
I am comfortable to say that an object belonging to a layer can depend on objects from lower layers
To be honest, I don't think you should be comfortable with that. When dealing with anything but a trivial system, I'd aim to ensure all layers only ever depend on abstractions from other layers; both lower and higher.
So for example, Obj 1 should not depend ...
Your solution is the right one. Put the shared code into a another project that builds its own JAR file, and use it in both projects. When building the JAR file, you may want to include the version in the name, e.g. in Debian style;
It doesn't prevent versioning trouble, but it should help. I've never used Maven, but I ...
If you want simple optional dependencies like plugins, e.g. if you install foo you will run it colorful but if not installed, you don't have any problem and see it in gray, then you could use optionalDependecies in the package.json:
And in the code:
You have already listed the disadvantages of the static factory pattern quite well, but I don't quite agree with the disadvantages of the dependency injection pattern:
That dependency injection requires you to write code for each dependency is a not a bug, but a feature: It forces you to think about whether you really need these dependencies, thereby ...
Git submodules are broken:
(Previous link was this one but went down unfortunately)
workflow is hard to follow
history is cluttered
unintuitive behaviour for non-git-experts
easily broken (see section "Submodules break easily, and submodules break badly" in the link above)
We have been using them for something similar as you describe, and it is ...
The question you ask is generalized, but the issue here is not what you think it is. The majority of this answer focuses on the real issue, but I want to respond to your direct question first.
So my question is, should I move the codes in validateFormat() into submit(), in order to fit YAGNI rule?
Unless your validation logic is complex enough to warrant ...
The codependency module may be what you're looking for, or anything that does something similar to:
declare optional dependencies in package.json that aren't automatically installed by npm install, say optionalPeerDependencies
a custom require-style function that knows about optionalPeerDependencies and does the right thing, including throwing/warning when ...
The solution to developing applications where bugs or lack of features have a high risk of causing your work to stop is to not use high risk libraries. Boring and lame, I know..
You said this is an alpha release. Don't use alpha releases for critical projects. It's not even a beta release, let alone 1.0 so this sort of thing is to be expected. The entire ...
It's not your problem. It is up to your end user to resolve. It just comes with the territory of using third-party dependencies, and I've had to resolve dependency conflicts more times than I count. You can't expect to accommodate every project's specific dependency conflicts.
Your software should operate correctly with the latest versions of your ...
I have always avoided this problem by using NuGet. If you are developing .NET, it's the 'standard' out of the box package manager and works very well.
The downside, if any, is that your dependencies are now binary DLLs rather than source code, which you can debug and edit as you go.
This imposes some restrictions on your day-to-day working practices. You ...
On the whole these things are good for your customers. Even a popular open source library might be impossible for them to use for some reason.
For example, they may have signed a contract with their customers promising not to use open source products.
However, as you point out, these features are not without cost.
Time to market
Size of package
A library is a specific piece of software that is intended to be consumed by another program. Typically, the library will address a specific/group of specific issues (although they can sometimes grow to a point where it's hard to identify what the original issue is/was). A library can be either internal or from a third party. Typically, a library is also ...
Data must always be validated again in the backend, even if it is already validated in the frontend.
The fundamental principle at work here is this: you cannot trust the frontend. It could contain a bug or virus. It might not be your frontend at all; it might be some other program written by a bad actor to gain access to your systems.
So why validate in ...
Is it better to expose or hide dependency in OOP?
It's best to do both.
Before I explain that let me explore the problems with your proposals.
Let's say I have an object A, which is too big(having too many methods and variables).
So, I break it down to smaller objects.
This is good. Always break objects down until they have only one responsibility, that ...