In java, I have see so many "container" and it provide "context" to it's client.
Such as EJB container, Web Container, IoC/DI container and "ApplicationContext".
Is this concept a kind of design pattern? I have searched in GoF, and it seems didn't
describe a thing like this.
Not a design pattern, more of a design construct (well, I guess you could argue that the difference is in semantics). A Container would provide an environment (i.e. external code) for your code to run in, and a Context would provide environment settings and additional information for your code.
Instead of 'design pattern' a more suitable concept for 'Container' is Framework.
... a software framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software. A software framework is a universal, reusable software platform to develop software applications, products and solutions. ...
In java, I have see so many "container" and it provide "context" to it's client.
'Context' is the environment execution information provided by the Container to the Components that run on it. With the previous definition in mind you can see the 'Context' as one of the generic functionality provided by the Container.
More clear, you have a Container that runs components, each component access the environment information through the Context. Of course this not pretend to be a formal definition, it is just the way I like to think about this concept.
The GoF book is about OO design patterns, it was published in 1995
before all these Java enterprise patterns and servers came up.
It is at the level of classes, methods, etc. i.e. about OO concepts.
You may consider containers and contexts some sort of patterns, yes.
But they are about modules, components, containers, servers, and how
to make these modules and components run into containers and servers.
These are just things from a different time and at a different level.
Related
By System Architecture I mean the computational components of the software system and interactions/relationship among those components. The components may be tasks, processes, objects or modules etc. Different components are connected by connectors(procedure call, implicit invocation, message passing, instantiation, shared database etc).
I have generated UML diagrams via reverse engineering using Visual Paradigm, but can I also generate Architecture?
Since components and interactions can be not explicit in code in general case you can not generate such diagram automatically. You should study different aspects of your application: source code, existing documentation, user interface, configuration, jira tasks, etc and try to restore the original architecture.
An "architecture" is just a view of some code properties, that don't change very fast. (If a property changes fast, it isn't the basis of an architecture).
From this perspective, UML diagrams are a kind of architecture. So is a call graph, and so is any modularization scheme you might have chosen.
The lesson is that "extracting architecture" first requires you decide what properties of the code you want to see abstractly, and then building (if you can) machinery to extract that information.
Since people mostly don't agree on what properties are useful, you gets lots of arguments about "what's an (my favorite) architecture", and you don't get a lot of tools since they are hard to build and there are lots of them.
What is the proper way to make java reusable components that is capable of used in various applications. I mean for example I'm doing a application that has its own user interface and database and etc. If I want to make this app reusable for many other applications as a component of other applications. For example one feature of my first app may needed by other app. So how to make it possible for other apps to use this feature of my app without changing my original code. What are the proper ways to achieve this re usability.
Write something simple which does what it does very well. Document it and unit test it and make it open source.
Have the the reusable components in another project (e.g. "common") and package them as .jar. Then include that jar in the projects where it's needed.
Extracting a separate project might be tricky though. You should observer the following:
the common components should not be dependent on anything in the higher level of abstraction (i.e. you services must not have any UI-related dependencies)
the internals of the components must not be visible to the application using them. I.e. your jar should expose a minimum API.
You have a couple of options for the mechanics of packaging:
simple IDE-dependant packaging - declare a inter-project dependency. On build export the jar and put on the classpath of the client application
Maven/Ivy - install the dependency in a repository (local or remote) and use the dependency resolution mechanisms of maven/ivy
This is a rather broad question. As such, I am offering broad suggestions:
Know your OO basics. Inheritance, encapsulation, polymorphism. It gets crazier from there on out.
Learn about design patterns, start observing them in applications you already use.
Look at popular open libraries to see how they implement patterns and modules.
Try things in sandbox projects. Grow your knowledge in clean environments.
Since you mention Java, check out the Spring Framework.
Hope that helps.
You need code in such a way that your components are loosely coupled. Then the re-usability is very much high. Take a look at this and this.
Sun Microsystems, the creators of the Java language, have at last recognized this need, and have released the Java Beans Component Architecture. Java Beans are, quite simply, reusable controls written in Java, for Java application development.
Beans are "capsules" of code, each designed for a specific purpose. The advantage of Java Beans over standard programming controls is that Beans are independent. They are not specific to operating systems or development environments. A Bean created in one development environment can be easily copied and modified by another. This allows Java Beans greater flexibility in enterprise computing, as components are easily shared between developers.
Although I'm a Java developer and this is question concerns OSGi and modularity according to Java, the question really applies for any object-oriented, 3GL.
I'm beginning to grasp the concepts of truly "modular" development and beginning to take a real liking to OSGi. For the first time ever I'm beginning of thinking of deploying jars in very granular, reusable, specialized deployments. However this new mode of thinking has stirred up a few questions.
In pure component-based architectures, does every class get jarred up? If not how granular should components be? Is it possible to make every component reusable?
What are some "rules of thumb" to use when determining how granular a modular component should be? Thanks in advance!
I'm going to answer this mostly from an OSGi perspective.
IMHO it's important to distinguish between components and modules. A component is a programming artefact: something that has behaviour and may offer services to other components. In implementation terms, you program a component using one of OSGi's component models such as Declarative Services. See http://wiki.osgi.org/wiki/Component_Models_Overview
A module is a deployment artefact: it is the packaging of components and/or APIs into an artefact that can be copied around and installed in various runtimes. Therefore implicitly you can package multiple components in one module, OR create one module per component.
The fact is, module contents are quite easy to refactor, so you shouldn't worry too much up front about the granularity: as you get more experience with OSGi you will find the right level for your own needs. However bear in mind the following general advice:
Components packaged together in the same module are (re)deployed together. If one of those components is being released more frequently than the others then you may be creating more work than necessary (e.g., testing by downstream consumers) by repeatedly releasing unchanged components, just because they happen to be in the same module as the changing component.
One cannot deploy half a module. Therefore all the components in a module should be closely related, so you do not make users wish "if only I could deploy just some of the components in this module"...
APIs change very slowly and cautiously, whereas components change frequently. For this and other reasons, APIs are best deployed in their own API bundles. See http://wiki.osgi.org/wiki/Separate_API_from_Implementation
In order to ensure module contents can be refactored without breaking users, always express your dependencies in terms of Import-Package rather than Require-Bundle. See http://wiki.osgi.org/wiki/Use_Import-Package_instead_of_Require-Bundle
In web development we use java .net or php5 .
All are OO. and have all the OO features.
But in real time websites do these OO features play any major role other than inheritance.?
Can anybody list some with real time examples.
In application development there may be a vast use of OO.
But in case of websites, does OO playing a major role?
How?
Back in 1995 the book Design Patterns managed to produce this phenomenal insight on page 20:
Favor object composition over class inheritance
Since then, proper object-orientation has been about that instead of inheritance. Particularly, the SOLID principles describe a set of principles for object-orientation that are applicable for any code base where maintainability is important. Polymorphism is important, but inheritance is irrelevant.
That applies to web applications as well as any other type of application.
I make heavy use of encapsulation and polymorphism. Specifically I use the Strategy Pattern (among others) pretty heavily to compartmentalize a great deal of my functionality. When combined with dependency injection, it makes it really easy for me to separate functionality of say, my persistence layer, from my business logic or presentation layer.
For instance, it's trivial to swap out a hibernate implementation with a JDBC implementation, etc. Actually, recently, I just switched from an e-mail service that operates synchronously with the web request to one that uses a message queue to asynchronously send mail. All I had to do once I'd implemented the new layer was change which class was injected into my beans that use it.
Edit: To address your comment, #zod, I don't use it so with with regards to the pages that are executed although that does happen from time to time (for instance, I have different classes for HTML email and plain text email depending on what the user has requested) but I primarily make use of the OO principals in the configuration of the application. Does that make sense?
As a start, the main principles of OO come in handy.Take for example data encapsulation in an MVC pattern; The fact that you can have a User model that does all the user stuff means that everything that has to do with users is encapsulated in that one model. This makes it easier to add and modify features later on. The extensibility also comes in handy when you want to extend your program with the code other people have written. As long as you know the public interface of their classes, you can use them.
TO give a simple example we as a company heavily use it for security. We have plugins for various frameworks that controls who tries to reach which class and method. In addition to that we can avoid user to reach that class and method without adding extra lines to class.
Other than that we are using them to clarify the code as well.
Beside all of those doing OOP is good way to create a big project with a big team.
Having used DDD for a web site and finding it to be a neat approach, I'm wondering if this can/should be applied to desktop applications? Also, with the classes being separated into different packages, how could the MVC pattern be mixed in?
Generally speaking, there is no reason why you should not use DDD for desktop/GUI applications. The problem you hint at is IMHO more of an architecture/design problem. Mainstream approach to build web applications today is the MVC architecture, however, in the GUI world, there is a component based architecture with event handling. You can build components out of MVC, i think Cocoa is done in such a way. Retrofitting components into MVC might be harder. The reason is that components/widgets often contain logic which should be split in views and controllers. However it is still possible, but it is up to you to decide if you really want to go into MVC, which is IMHO sort of lower level architecture than components.
I find it difficult to implement DDD in rich applications namely because of how difficult it is to facilitate the controller because of the necessary listeners. I like using the Observer pattern in conjunction with Strategy where an Observer uses a Strategy object to operate on an Observable.