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 4 years ago.
Improve this question
Why do we use OOPs concepts?
What are the advantages/disadvantages of OOP?
Where do we use OOP?
How do we tell if a program can be written in OOP paradigm? How is it organized?
Note : I'm not related to technical field... So please consider this in your answers.
In short: to reduce the cognitive load required to write, maintain and understand the software.
Software systems are inherently complex, so developers need some tools to break things down to the modules and individual components that could be analyzed and understood without enormous efforts — and OOP is just that kind of tool.
Thats quite a big question. And I try to give you a feeling why we do develop principals like oop ,soa,....
Most of the principal target to make software less complex. Imagine a file with 1.000.000 functions. it would become difficult to find the you want to change. Especially if there are not veryx wqell name like "Update" so you could have a thousand "update" methods.
Often things are less complex if you don't see the complete information pool so you can focus and things you may need. Thats also why there ideas like the information hiding principle .
Another thing is that when you have standards you have to think about. For example in Real life you know that you can sit on a chair (thats a standard) you don't ahve to think about it. Thats why standards make like easier. Some aspects of OOP establish standards (e.g. use of classes) therefore there is little less complexity.
Having class which are grouping the functions may be the first step towards oop. Now when you search a function you would most propably know what you want to udpat "a custoemr" so you know this function may be in the customer class and you have to only look over these methods.
And most of the time thats what principals are made for. making software more read and understandable
OOP is much much more and not the only paradigm .But there is so much more and OOP has so much principals and interprations. It would be too much to explaind and discuss it here. I would also recommend you to have a look at the CleanCoders Movement which provide this in a more general way.
CleanCoders Webcasts
Does ORganization matter
Related
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 wanted to ask little bit generic question about Java API's. I'm new in Java, learning myself and of course I enjoy it while learning. But when it comes to Java API's, to me it's hard to understand even if I know OOP's Concepts. Actually I often confuse while reading JavaDoc's. Agree that there are bunch of information about what class's(interface, enum..) has, what they extend, implements or whatever. Even though I couldn't use them without looking from the internet.
So, what is the best way of learning those API's in general, just give me your followed way while learning Java.
The best way to learn Java is to read articles with examples. It is common approach for newbies and professionals. JavaDocs is dry, too formal and really are often confusing (especially for methods from Stream API with 3+ generic parameters).
The way I did was to read certification books, for OCA and OCP, they start from the very basic, and builds up on the top of that, with examples and exercises.
It is a really nice way to build your core knowledge of the language. With that solidified knowledge you can start reading articles about different subjects in the Java universe ...
Just be patient, code as much as possible, and it will become natural aftar some time.
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
I always hear that we need to encapsulate whenever we write object-oriented code. If I'm the only developer on a project, do I still need to use encapsulation?
One way to put an answer: Encapsulation, conceptually, exists for writing better, safer, less error-prone code. It doesn't exist, primarily, to facilitate teams working together on code (that might be a side effect, but that's not the purpose).
So the goods that encapsulation seeks to foster scale from one coder to many coders, and they are goods that do not really have to do with the number of coders, although those goods may find stronger expression the larger the project and teams are.
Encapsulation is there for a reason.
Someone has to maintain and manage your code after you are done, right? What if the project gets bigger and you get team members?
So, the answer is "yes", it is always best to use encapsulation whenever possible.
The fact you are asking this question makes me wonder you actually did not get the actual value of encapsulation as a means to reduce and thus deal with complexity.
My theoretical computer science professor used to tell me that in the end, if you think at the whole binary representation of a program, any program is just a number. Very big indeed but, only a number. And that is true, any other construct we use but 0 and 1 (i.e. C++, Java, Python, functional programming, object oriented programming, aspect oriented programming, etc..) is just because of the fact we need more abstract means to get the one number we need.
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 9 years ago.
Improve this question
We want to implement a model or guideline for our OO designs,. We like Domain-Driven Design. Our specific question is: do you think DDD is still valid right now beyond the pattern design? If so, do other approaches or variants exist that we should evaluate ?
Fundamentally we develop enterprise web and desktop applications using Visual studio (c#).
Thanks in advance
In my opinion, DDD is as pertinent today as ever. The idea that one should strive for an Ubiquitous Language, such that the domain in code is not divorced from the domain as described by the domain experts, will probably remain a good idea for a long time, and it is easier today to focus on the domain first and consider persistence as a "secondary" problem than it used to be. It is also still true that DDD requires an important design effort, and its value is going to be proportional to how complex the domain is.
I have not written any application using the methodology, but I have been reading a lot on Event Sourcing and CQRS lately, and they both seems like a very interesting approach which should fit well with DDD (and are usually advocated by people who are DDD proponents).
I can't find it right now, but there is a video interviews of Eric Evans floating around somewhere on the web,You may be interested in watching this video of Eric Evans, which is a form of retrospective on the methodology a few years after writing the book, and what he would have done differently now.
I think DDD is quite alive (or quite as dead) as before. My opinion is that the "domain" is a hot topic today because of DSLs (Domain-Specific Languages) and MDE (Model-Driven Engineering).
You may want to learn more about a similar "domain-driven" aproach, called DSM - Domain-Specific modeling. In DSM, you can work through patterns but you also define code generators that translate your domain-specific design into working code.
Check the DSM Forum or Wikipedia for more information about DSM.
The two most notable tools right now in this area are MetaEdit+ from MetaCase and AtomWeaver from Isomeris.
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
I see many developers disagree on which style of test to use while starting a new project. I'd like to know why you choose this particular style over the other.
BDD and TDD are not excluding each other. I think, BDD addresses more the software development as a whole, beginning from requirement analysis. TDD is purely related to implementation and is actually a personal work technique of a developer.
I usually use the outside-in principle. Whether you will call that TDD or BDD is of less importance to me.
What this means is that I start at the most significant part of the feature that I want to implement, and work from there. This is often the User Interface, but it doesn't have to be. Sometimes the most significant area is a service operation or a background process, and then I start there.
I use Test Doubles to define how the classes I define interact with its environment, and then implement more and more of the abstractions defined by these Test Doubles as I implement the feature.
So I guess you could say that I start out in a BDD mindset, and then move more and more towards TDD as I work my way down the call stack, so to speak.
TDD v BDD is really a state of mind. The way I see it is, in TDD a lot of emphasis is on what should this value be at this point, where as I see BDD, which will also test values of course and how we got them, as being more of, when this is in this state, what should this part of my application do.
I learned to do TDD in a BDD style. Its all really a matter of how you do your thinking.
Many people have made the mistake thinking that TDD was about testing. Thus BDD was created' to minimise confusion by emphasising behavior over testing.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
In a program, I can design lock to threads,lock to object or files.
Are there difference between these locks?
If yes,
how many kinds of lock are there which can be used to design?
Are there some tutorials to design locks in object-oriented programming?
As someone dss538 said, the "answer" really depends on the context of the question.
What exactly is it that you need to protect access to?
An piece of data or single object, items in a container of some sort, a piece of code, a system resource like a shared file?
Another really meaningful question is how frequently are you going to be accessing this "thing" and what are you going to do with it?
Different locking techniques tend to have different overheads and while a critical section or mutex may be perfectly fine for something that is rarely accesseed and rarely updated, if you're rarely updating it and frequently accessing it you might want to look at a reader writer lock. Another follow up question here is "should I be using spin-locks" here, and again the answer is it depends? What else is going on in the system and are you going to trade one kind of bottleneck (a coarse grained lock) for another?
A final question I like to ask is what are the alternatives to "locking" something, i.e. if I can "safely" take a copy of my protected thing and work with that copy "safely" (ideally without modifying it), it's certainly a lot easier than worrying about every place I might modify said "thing."
I apologize for the vague answer but a more specific question would help here.
I would encourage you to read up on concurrency prinicples and understand the traditional "Dining Philosopers" "Sleeping Barber" and perhaps even "Santa Clause" problems to understand more context of how these things work.
A lot of the content on Wikipedia is good, particularly 'Concurrency Control' is a useful starting reference point if you don't have a good OS / Concurrency book on your shelf.
The answer depends on the context of your question.
Are you obtaining locks from some API? Check the API documentation.
In general, though, I would say no. A lock is a lock. The fact that you are using it to protect a file or an object does not matter to the API. How you use it is up to you. You certainly could abstract away and have FileLocks and ObjectLocks if you wish, but that is up to you.