[DESIGN PATTERN] Factory: Define Method Area

Hi Guys,
I have a question regarding the Design Pattern:Factory. According my need the question is below as:
I have the Abstract Class AAA with it own Abstract method that create objects (only one method).
I have a Final Sub-Class BBB with 20 instantiate methods + the inherited method from Class AAA.
BBB->method_bbb1().
BBB->method_bbb2().
BBB->method_bbb3().
I have a Final Sub-Class CCC with 10 instantiate methods + the inherited method from Class AAA.
CCC->method_ccc1().
CCC->method_ccc2().
CCC->method_ccc3().
Afterwards:
Class BBB is instantiated through the Factory. The TYPE of BBB is AAA.
Class CCC is instantiated through the Factory. The TYPE of CCC is AAA.
My question is:
How could I use the 20 methods of BBB without to declare them in AAA (without inheritance). Because, if I declare them in AAA, consequently they will be visible in CCC. And I don't want to ...
DATA BBB TYPE REF TO AAA. "Var Object BBB is type of Class AAA
DATA CCC TYPE REF TO AAA. "Var Object CCC is type of Class AAA
BBB = AAA=>Factory( 'BBB' ).
CCC = AAA=>Factory( 'CCC' ).
" I want to call, in that way:
BBB->method_bbb1().
CCC->method_ccc1().
CCC->method_bbb1(). " RAISE ERROR
I have found a way but I don't know if it's breaking the rules of the Factory Concept.
Have you got any idea?
Thank you in advance.
Rachid.

Hi,
If you have declared the methods in abstract class as protected or public and if you are inheriting it to the sub classes, then the methods will be available in the subclasses. There is no way to restrict like few abstract methods needs to be inherited and others need not be inherited. The inherited classes are forced to implement the abstract methods.
In your scenario, i do not think there is a need of abstract class, as I assume that both of your classes does some stand alone logic( as per your question ) compared to the other and doesn't have any common operations. Could you please let us know about this in detail ?? What about INTERFACES ?, Please have a look into it.
Kesav

Similar Messages

Design-pattern(Factory)

can any body tell me under which sceniro it would be beneficial to use factory and abstract factory pattern
thanks in advance

We will need to use a factory pattern when we want to delegate the logic of creation of classes to a different class. This class holds the responsibilty of handling the creation of the the range of realated Objects of the same type.
Ex: In an ice cream parlour the cones are the same and the method of filling in the cones is also the same, only thing that differs is the cream that needs to be filled. Delegate this responsibility to a factory method.
You will go for an abstract factory pattern if you have the a class which itself has several varieties and even the compose classes within this class has several varieties.
Ex: Extending the above example if there are range of cones available to choose from and a range of cream to choose from we will go for an abstract factory.

Factory v/s Facade Design Pattern.

Folks,
I was just going thru the Design Patterns (Factory Pattern and the
Facade Pattern)
The Factory Pattern :
The factory completely abstracts the creation and initialization of the product from the client
This indirection enables the client to focus on its discrete role in the application without concerning itself with the details of how the product is created. Thus, as the product implementation changes over time, the client remains unchanged.
Client--------------------->Factory----------------->Product
The Facade Pattern
Encapsulate the subsystem using a High-Level Interface/provides a
simplified and uniform interface to a large subsytem of classes.
The Client communicates with the 'Facade' which has methods to interact
with subsystems.The Client very rarely accesses objects in the subsystems.
Subsystems objects usually retain no knowledge of the client.
Subsystem objects do not normally maintain any reference to Fa�ade.
Client------------------->Facade------->Subsystems
My Question is this:
Arent both these pattern quite similar becos both designs access an Interface
which inturn invokes the required object of the subsystems?
Can anyone explain the major difference?

Perhaps these definitions will clarify things a little for ya...
Fa�ade
The Fa�ade pattern simplifies access to a related set of objects by providing one object that all objects outside the set use to communicate
with the set. This also promotes a weak coupling between the subsystem and its clients. This weak coupling allows you to vary the
components of the subsystem without affecting the clients.
Factory
Centralize the assembly of resources necessary to create an object. This prevents the need to change all classes from changing when a
Product changes and makes any change needed occur only in the Factory.

Design Patterns in Dynamic Programming

I mentioned this on a thread some time ago - that many of the GoF patterns disappear in languages such as Lisp, but didn't have the reference handy. Came across it again today so I thought I'd post the link:
http://www.norvig.com/design-patterns/
Pete

hi sourdi
Below are the list of Design pattern in abap .
Singleton: ensuring single class instantiation
Adapter: making class interfaces compatible
Factory: encapsulating object creation
MVC: decoupling business logic from the view
Facade: providing a simplified interface
Composite: treating individual objects and compositions uniformly
Decorator: forming a dynamic chain of components to be used as one by the client
regards
chinnaiya P

Design Pattern Names

Started fooling around with some industry-specific software implementations. In one software design document, I came across a reference to an old familiar term "design patterns". This part of the text was describing XML Schema Design Patterns. Below is the first paragraph, which made me laugh :o)
"As with software design, there are design patterns associated with XML Schema design. The most popular XML Schema design patterns are Russian Doll, Salami, Bologna, Venetian Blind and Garden of Eden."
Unlike the GoF, these guys seem to be hungry....
Anybody have any experience implementing the Bologna design pattern?

I agree with dubwai's take on this. These are not design patterns, in my opinion. These are language-specific, very defined, programming algorithms for handling a few typical issues with processsing XML-based data.
To label these as "design patterns" is a bad thing and just another step to adding to the confusion of what an object-oriented design pattern really is.
Moreover, the name of an object-oriented design has a very important role. Care should be taken when naming a design pattern; a name should convey the meaning or intent of the pattern. To call a "design pattern" Salami Slice is a joke, in my opinion.
One of the most important aspects of design patterns is that they are NOT specific, coded solutions to any problem. And, they are design tools to guide the process of designing software. Implementation details are outside the scope of design patterns.
Generally, I find that these work well with the Provolone and SandwichOil patterns. lol

What is a design pattern?

Howdy,
I hear a lot of talk of deasign patterns in ABAP...
My question is what on earth is a design pattern and why/how would it be useful?
Any ideas anyone

Hi Steve.
The good point to start with design patterns is to read book "Design Patterns - Elements of Reusable Object-Oriented Software" by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. It gives strong, consistent understanding of patterns basis with real life examples.
Short introduction extract:
"Christopher Alexander says, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice". Even though Alexander was talking about patterns in buildings and towns, what he says is true about object-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead of walls and doors, but at the core of both kinds of patterns is a solution to a problem in a context.
In general, a pattern has four essential elements:
The pattern name is a handle we can use to describe a design problem, its solutions, and consequences in a word or two. Naming a pattern immediately increases our design vocabulary. It lets us design at a higher level of abstraction. Having a vocabulary for patterns lets us talk about them with our colleagues, in our documentation, and even to ourselves. It makes it easier to think about designs and to communicate them and their trade-offs to others. Finding good names has been one of the hardest parts of developing our catalog.
The problem describes when to apply the pattern. It explains the problem and its context. It might describe specific design problems such as how to represent algorithms as objects. It might describe class or object structures that are symptomatic of an inflexible design. Sometimes the problem will include a list of conditions that must be met before it makes sense to apply the pattern.
The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations. The solution doesn't describe a particular concrete design or implementation, because a pattern is like a template that can be applied in many different situations. Instead, the pattern provides an abstract description of a design problem and how a general arrangement of elements (classes and objects in our case) solves it.
The consequences are the results and trade-offs of applying the pattern. Though consequences are often unvoiced when we describe design decisions, they are critical for evaluating design alternatives and for understanding the costs and benefits of applying the pattern. The consequences for software often concern space and time trade-offs. They may address language and implementation issues as well. Since reuse is often a factor in object-oriented design, the consequences of a pattern include its impact on a system's flexibility, extensibility, or portability. Listing these consequences explicitly helps you understand and evaluate them."
Regards,
Maxim.

Design Patterns: 'Program to an interface, not an impl.' and Factory Method

Design Patterns: 'Program to an interface, not an implementation' and Factory Method.
Hi All,
I've 4 questions. And 1M thanks for your precious input.
1. OOAD steps:
Requirement-->Use Cases-->Analysis Classes-->Sequence Diagrams-->CRC-->other UML diagrams if needed--> Domain/Business Classes.
If we follow the rule 'Program to an interface, not an implementation',
would that imply NECESSARILY we should have another set of Interface Classes for our Domain Classes? i.e Interface_ClassX for ClassX_Impl.
2. If the point 1 is a MUST because of the rule 'Program to an interface, not an implementation',
ie we should have an Interface classe for every one Domain classe,
would that NECESSARILY imply we should have as many Factory Methods as they are Domain Classes to abstract the creation process?
Interface_ClassX X= Factory.GetClassX() ( return new ClassX_Impl)
Interface_ClassY Y= Factory.GetClassY() ( return new ClassY_Impl)
Interface_ClassZ Z= Factory.GetClassZ() ( return new ClassZ_Impl)
3. On the point 2, the underlying principle used is Factory Methods.
Now on the surface, what are other possible business and/or technical naming for such Factory Methods? I mean should we call it a kind of Business Facade?
4. Is the point 1 and point 2 considered to be the best practices?

So the question here is whether we can predict having
more than one possible implementations which required
option c. Is this a dilema? I guess it's hard to
predict the future.Right. Hopefully it's fairly obvious while designing things and
deciding what objects are needed.
Now, if the Presentation Tier, says JSP, needs that
ClassNormal object. Would we still keep that line of
code a.
OR would we introduce an intermediate object to free
JSP from the direct creational aspect using new
keyword like the choice b. that you reject.
The point here is to reduce the direct coupling aspect
between the Presentation Tier and Business Tier. So
what would that intermediate object be?In that case, you have to ask yourself if there is a valid
need for reducing the coupling. If you simply make an intermediate
object, what keeps you from making an intermediate object to your
new intermediate object, ad infinitum.
That intermediate object could be a Facade pattern, or simply
an abstraction. We actually did that here, we began a massive
java project, and we abstracted away from Swing J-classes and created
our own "wrappers" that simply extended all the J-classes and we had
all our programmers develop using our wrappers instead of the Swing
classes. That allowed us to add some custom code, some temporary bug fixes, etc. Some of our classes were nothing more than "EPPasswordField extends JPasswordField" with nothing overridden. It does allow us a place to hook in and adjust or fix things if needed though.

Could someone explain the Factory Method Design Pattern

Hi Experts.
Could someone please explain for me the Factory Method Design Pattern. I read it a little and I understand that it is used in JDBC drivers but i'm not clear on it.
Could someone explain.
Thanks in advance
stephen

Basically, you have one class that's sole purpose is to create instances of a set of other classes.
What will usually happen is you have a set of related classes that inherit from some base class. We'll say for example that you have a base class CAR and it has sub-classes FORD, GM, HONDA (sorry Crylser). Instead of having the user call the constructors for FORD, GM, and HONDA, you can give the user a Factory Class that will give him a copy. We'll call our factory class Dealership. Inside dealership, you can have a static function :
public static Car makeCar(String type)
if(type.equals("FORD")
return new FORD();
else if(type.equals("GM")
return new GM();
else if(type.equals("HONDA")
return new HONDA();
So when the user needs a car, they will just call
Dealership.makeCar("FORD").
This is a good way to hide the implementation of your classes from the user, or if you require complex initialization of your objects.
Another good example of this is in the Swing library. To get a border around a component, you call static methods on BorderFactory.
Hope this helped.
Ed

Abstract Factory Design Pattern

Could someone please explain the abstract factory design pattern in simple english. As far as I understand it is used to create a bunch of related objects based on parameter/s provided at runtime.
However, why would one use this compared to an Interface.
I actually am reading a great book on design patterns (Design Pattern by James Cooper) but having a bit of problem really understanding this one.
Cheers

As far as I
understand it is used to create a bunch of related
objects based on parameter/s provided at runtime. There may be variations but as I understand it basically an Abstract Factory defines two interfaces, one is the factory and one is the product. A good example is iterators in Java. The iterator factory is the Iterable interface and the iterator product is the Iterator interface.
ArrayList implements Iterable so it's an iterator factory. If you call the iterator() method of an ArrayList object you'll get an Iterator object. The same applies to TreeSet and many other classes.
The Iterator objects sport the same Interface but they're quite different internally of course (Iterating an array is not the same as iterating a tree) so they're a "family of related products".

Design Patterns that are used in standard j2se/j2ee classes/interfaces

Hi All,
I am understanding following design patterns (used within standard j2se/j2ee):
Adapter
Facade
Composite
Bridge
Singleton
Observer
Mediator
Proxy
Chain of Responsibility
Flyweight
Builder
Factory Method
Abstract Factory
Prototype
Memento
Template Method
State
Strategy
Command
Interpreter
Decorator
Iterator
Visitor
I want to see if/where these design patterns are used in j2se/j2ee classes/interfaces. i am looking for few examples of standard java classes/interfaces/cases where these design patterns are used by jdk developers.
for e.g.
WindowAdapter class is an example of Adapter DP.
JOptionPane is an exmple of Facade DP.
MouseListener is an example of Observer DP.
Similarly, where can find examples of jdk classes/interfaces of the remaining DPs.
I searched a lot of books, but they explain the DPs by creating their own classes/interfaces.
I would like to see where these DPs are already utilised in std j2se/j2ee
thanks,
Madhu_1980

877316 wrote:
I searched a lot of books, but they explain the DPs by creating their own classes/interfaces.
I would like to see where these DPs are already utilised in std j2se/j2eeWell, you can go through the javadocs first, they sometimes mention the pattern used.
Then you can get the sources for the jdk and go through the classes yourself, identifying the patterns.

Examples of the Abstract Factory Design Pattern

Could someone please give an example about situations in which you would definitly use the Abstract Factory Design Pattern?

Ok, but they are coupled because Abstract Factory uses Factory methods. Without getting too detailed here, Abstract Factory is useful when you want to swap out entire sets of things (ie. pluggable look and feels). So one subclass of AbstractGUIFactory is MotifGUIFactory while another is WindowsGUIFactory. Your application can gets a specific factory but puts it in an AbstractFUIFactory variable.
AbstractGUIFactory factory = new WindowsGUIFactory();
AbstractButton = factory.makeButton();So you can program generically and swap out entire sets of widgets by changing one line of code.
You should really read Design Patterns by Gamma et al. because it is the definitive book on this topic.

Get instance method and design pattern

Hi All,
1. I New to abap objects and i read the help and some stuff from the forum,
l like to now more about design pattern in abap objects,
2. I saw in some abap class the use of method of GET_INSTANCE i think it's from factory pattern , what is the pros. and cons to use this method ,when i should consider to use it ?
Thanks in Advance
Nina

Hello Nina
A very good introduction into design patterns is the book "Head First: Design Patterns". Here you will find many good reasons why and when to use the factory pattern.
You should use the factory pattern when
- you want to prevent "direct" instantiation (i.e. using a public CONSTRUCTOR method) by the developer
- you want to hide the complexity of instantiation from the user of the class
- the instantiation creates an implementation of an interface and you want to keep control of which implementing class is returned
Regards
Uwe

Need a Effective Design Pattern for Different Validation methods ???

Hi All,
I am having different validation methods with separate functions. I like to know the Best and Effective Design Pattern to do this.
for example
validateUserId()
validatePassword()
validateAuthentication()
validateSession()
validateConnection()
.... etc......
Can anybody help me to solve this?
Thanks,
J.Kathir

Hi there - is this the kind of thing you wanted?.
This structure has served me well. There is quite a lot to it and lots you need to infer but you should be able to work it out!
It works for EJB & swing etc (I believe)..
It doesn't use exceptions to return validation messages.
It doesn't use lots of little objects. The code is very explicit & pretty simple.
public class PersonValidator
Person myData;
public PersonValidator() {
//personId will be 0 and we are in nsert mode
myData = new Person();
public PersonValidator(long personId) {
//personId will have a value and we are in update mode
myData = PersonDb.getPerson(personId);
// =================================Single field validation
// =================================For swing apps to call - not over network.
// =================================Use validateData method
public String validateDateOfBirth(String dataOfBirthStr) {
String msg = "";
msg = validateDateStr(dataOfBirthStr);
if (!msg.equals("")) return msg;
public String validateSurname(String surname) {
String msg = "";
if (surname.equals("")) return "surname must be entered";
//=============================================Cross Validation
public List crossValidateAndSave(boolean saveData) {
String msg = "";
List valerrs = new ArrayList();
if (surname.equals("Collins") && dateOfBirth.compareTo("???")) {
List.add("Candidate is lying about their age. Please enter a realistic Date of birth");
if (valerrs.size() == 0) {
if (saveData()) {
personDb.saveData(myData);
// =========================To validate across the netwrok this lets you
// pass all the data in 1 go & receive multiple messages in reply.
// AN EJB can delegate to this code or this code could be in the EJB.
// @param stopAtFirstMessage flag allow efficiency if app ccan't handle multiple validation
// erros at a time.
// @param saveData flag allows validation without saving - allows for confirm message.
// @param EditPersonGuiData - What the user types in. Numeric data & dates can be
// in Strings. Using struts this could be the formBean.
public List validateData(EditPersonGuiData inputData, boolean stopAtFirstMessage, boolean saveData) {
String msg = "";
List valerrs = new ArrayList();
msg = validateDateOfBirth(inputData.dateOfBirth);
if (!msg.equals("")) valerrs.add(msg);
if (stopAtFirstMessage) return valerrs;
valerrs = crossValidateAndSave()
return valerrs;
}

What are the best practices in design patterns?

What design patterns are likely popular?

If you go to your local bookstore or online book store you will find at least 20 books that describe this.
Some how I doubt you are going to get 20 books worth of an answer.

Are there any Client/Server Application (using sockets) design patterns?

Hi,
The title of the post nearly says it all. I am searching for different design patterns related with the development of a client/server application. I understand that there must be any different ways on how a client/server application can be developed.
Regards,
Sim085
Disclaimer:
When I enter in the Socket forum on this site I recieve this message "Thank you for any participation in this forum. Due to a lack of relevant activity, we have decided to archive this forum on June 16, 2006. For future posts on this topic, we suggest you use the Networking forum" and I am not allowed to create a new post! However I can see posts done yesterday! All i did is add the forum in 'my forums'. Does this happen to you people as well?

Hi Sim085...How are you?
So look this:
http://forum.java.sun.com/thread.jspa?threadID=5148926&tstart=75
I don�t know if is what you want...but I hope in this^^
Ok man...If you have one example for help you is better.
[ ]

[DESIGN PATTERN] Factory: Define Method Area

Similar Messages

Maybe you are looking for