As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I want to know the differences between SOA and OO, and why SOA is going to popular?
SOA is getting popular, because it introduces several benefits:
Makes your system more extensible
Easier for use by third-party code, for example you client's clients and their systems
It conserves your business logic and gives the ability to add additional presentation layers easier. This can be achieved in other methods, too.
These are the main benefits of SOA, I think. But you cannot compare OOP and SOA .. they're different things and they are not interchangeable. SOA is software architecture in general, on the other hand OOP is programming paradigm.
You can't really compare those two.
OOP is a programming language paradigm. Others are "functional programming" or "procedural programming".
You can use a OO language to use or create a service, but you could also use a functional language to do that.
In a nutshell SOA and OOP are two different things and you can't play them off against each other.
To put things in perspective:
OO is a methodology for building applications in a single address space. The public contract is the API
SOA is the architecture pattern for building applications that spans multiple address spaces (distributed applications). The public contract is the persistent data (ie. wire format) itself.
Before SOA, there was effort to extend OO to building distributed applications, the effort, called CORBA, utterly failed. One thing people learned is that building distributed application, you have to explict expose the wire format (the data), which OO attempts to hide... don't think services as RPC but instead as message producer and generators.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
The use of design patterns in programming is wide spread across many programming languages. A number of examples are the factory, or singleton design pattern. Many of these patterns use object orientation to create abstraction and encapsulation in the code, they aim at make code re-usable and structured. Many of these design patterns could also be used in R, maybe by using the proto library, or standard R object orientation?
My questions are:
What base code (S3, S4) / packages (proto, R.oo) can I use to reproduce design patterns as for example mentioned in the book by Gamma et al?
Are there examples of design patterns implemented in R, both in base R, or in packages?
Some examples of design patterns:
The system.time() function seems to behave much like a decorator pattern. However, almost exclusively decorators are mentioned in the context of object oriented programming. But still, it has the feel of a decorator, it extends (or decorates) an existing piece of code (in OOP always an object) with additional functionality without any need to change the piece of code. Here system.time() is shown in action:
system.time(bla <- Sys.sleep(1000))
#jverzani posted an example of singleton pattern on github.
An example of a Strategy Design Pattern is the apply family of functions. The functionality of looping over the given object is generic, the function that is applied (the strategy) is chosen when the user supplies the function.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm always hearing that RoR is good for Agile implementation. Could someone plaese summarize this statement and explain me why with some examples.P.S I can't read "Agile Web Development with Rails" yet.
Tools are never agile in the matter of software engineering. Tools support in being agile. Ruby on rails is a framework to rapidly build basic functionalities with ease and Agile in most minds is a way to build your system without having the knowledge of every requirement needed by your system.
So tools which support the developers to rapidly bootstrap a software or change functionalities rapidly help you in being agile. Because most of the times the understanding of "How things work" differs between the customer and the developer perspective.
Aligning those perspectives is a success factor on every project and most of the times it is better to show something for a common understanding than painting some flow charts, uml charts or whatever which imply domain knowledge.
Another thing is if you may bootstrap a project rapidly you may react on reordering of priorities more flexible.
For the nitpickers.: Agile is a buzzword. There are lots of definitions and different understandings whats agile is and it may always be that my view on being agile or developing agile differs from some other definitions.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
limesurvey is good enough and it is open-source, but why are wufoo-like services so popular nowadays?
Wufoo has a much more fancy user interface than limesurvey but why does limesurvey not make some improvements(2.0??)?
For business solution, which will be preferred in general case?
For one, I think the fact that the UI is so slick is one of the BIG reasons why services like Wufoo are indeed so popular. The target audience of these services is generally non-developer types who use mostly point-and-click interfaces and are very visual with their work, so a clean, well-organized UI that lends itself to ease of use will always win out.
After briefly testing both Wufoo and LimeSurvey, the difference in usage of drag-and-drop (Wufoo) vs. traditional text box and dropdown (Limesurvey) is readily apparent. While I felt overwhelmed at the start of both services, I did feel that Wufoo at least had some hints on which direction to go next if I was stuck, and never had a ton of controls on the page for me to see. It actually felt like a WYSIWYG editor for forms/surveys.
LimeSurvey on the other hand does not feel like it has any flow, and it's incredibly easy to get a bunch of toolbars on-screen that further confuse me. I can't speak to how comparable it is to Wufoo, or how powerful it is, but I have a feeling that while it can probably match what Wufoo can produce in terms of surveys, it probably requires much more expertise on my part.
But these are just my observations as a developer who has just recently heard of and tried both services.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Object orientation is probably the most dominant programming paradigm today. Some people say, there are certain disadvantages, flaws or faults to this paradigm. Some even consider it a complete failure. What are the concrete reasons/arguments for that?
What I found the biggest flaw of OOP is that the most prominent frameworks/methods encourage writing not object-oriented code. If we are developing service and DAO layer with no state at all (just business methods passing arguments from layer to layer) and have a domain model with no logic at all (just a bunch of fields and maybe getters/setters/properties), it is no longer OOP. Most of the enterprise projects, even considered to be well written, aren't actually object oriented. They have a collection of functions grouped together in logical namespaces (called classes) and a collection of data structures, having private fields to annoy programmers (called domain). The domain does not have any operations.
IMHO OOP model was sacrificed in enterprise applications because it does not handle concurrency properly (or maybe because people prefer to have a stable set of objects rather than creating new instance per request ?!?). This is probably the reason why functional languages (and immutable objects to some degree) are getting much more attention.
On the other hand, are immutable objects actually in the spirit of OOP? I am not sure.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
There are various books written for Design Patterns ranging from "Design Patterns: Elements of Reusable Object-Oriented Software" to "Pattern-Oriented Software Architecture Volume 1-4".
But, I did not found any good book which explains Objects Oriented Design, how to design classes, interfaces, etc for large scale and complex systems and make system design as simple as possible through those techniques.
Please share your thoughts about it.
A couple of the most obvious:
Object Oriented Analysis and Design With Applications (Grady Booch)
Object Oriented Software Construction (Bertrand Meyer)
IMHO good OOD is about keeping modules as small, compact and consistent as possible (e.g. the "SOLID" principles). Therefore, good large-scale OOD is "just" a bunch of good small-scale OOD together.
The only thing that really changes in larger scale systems is the importance of getting the smaller scale bits right. Get your abstractions in good order before you get down to actual code.