factory-pattern | 易学教程

Hiding classes in a jar file

阅读更多关于 Hiding classes in a jar file

问题 Is it really impossible to hide some classes in a jar file? I wanted not to allow direct instantiation of the classes to keep it more flexible. Only the factory (or a facade) should be visible of this jar. Is there any other way than solve this problem than creating two projects? (Two projects: the first one contains the classes (implementation) and the other one references to the first one and contains the factory; later only the second one will be referenced) 回答1: I think you will have

How to avoid 'instanceof' when implementing factory design pattern?

阅读更多关于 How to avoid 'instanceof' when implementing factory design pattern?

I am attempting to implement my first Factory Design Pattern, and I'm not sure how to avoid using instanceof when adding the factory-made objects to lists. This is what I'm trying to do: for (ABluePrint bp : bluePrints) { AVehicle v = AVehicleFactory.buildVehicle(bp); allVehicles.add(v); // Can I accomplish this without using 'instanceof'? if (v instanceof ACar) { cars.add((ACar) v); } else if (v instanceof ABoat) { boats.add((ABoat) v); } else if (v instanceof APlane) { planes.add((APlane) v); } } From what I've read on SO, using 'instanceof' is a code smell. Is there a better way to check

What is the difference between Builder Design pattern and Factory Design pattern?

阅读更多关于 What is the difference between Builder Design pattern and Factory Design pattern?

What is the difference between the Builder design pattern and the Factory design pattern? Which one is more advantageous and why ? How do I represent my findings as a graph if I want to test and compare/contrast these patterns ? With design patterns, there usually is no "more advantageous" solution that works for all cases. It depends on what you need to implement. From Wikipedia: Builder focuses on constructing a complex object step by step. Abstract Factory emphasizes a family of product objects (either simple or complex). Builder returns the product as a final step, but as far as the

Improper use of new to generate classes?

阅读更多关于 Improper use of __new__ to generate classes?

问题 I'm creating some classes for dealing with filenames in various types of file shares (nfs, afp, s3, local disk) etc. I get as user input a string that identifies the data source (i.e. "nfs://192.168.1.3" or "s3://mybucket/data" ) etc. I'm subclassing the specific filesystems from a base class that has common code. Where I'm confused is in the object creation. What I have is the following: import os class FileSystem(object): class NoAccess(Exception): pass def __new__(cls,path): if cls is

What is the difference between Factory and Strategy patterns?

阅读更多关于 What is the difference between Factory and Strategy patterns?

问题 Can any one explain the difference between factory and strategy patterns? For me both are looking same other than an extra factory class (which create an object of product in factory patterns) 回答1: A factory pattern is a creational pattern. A strategy pattern is an operational pattern. Put another way, a factory pattern is used to create objects of a specific type. A strategy pattern is use to perform an operation (or set of operations) in a particular manner. In the classic example, a

Why does Hibernate require no argument constructor?

阅读更多关于 Why does Hibernate require no argument constructor?

The no-argument constructor is a requirement (tools like Hibernate use reflection on this constructor to instantiate objects). I got this hand-wavy answer but could somebody explain further? Thanks mdma Hibernate, and code in general that creates objects via reflection use Class<T>.newInstance() to create a new instance of your classes. This method requires a public no-arg constructor to be able to instantiate the object. For most use cases, providing a no-arg constructor is not a problem. There are hacks based on serialization that can work around not having a no-arg constructor, since

c++ automatic factory registration of derived types

阅读更多关于 c++ automatic factory registration of derived types

问题 Like many before me, I\'m trying so get my derived types to automatically register with my factory. I read through many question and tried to focus on what I didn\'t find there. I\'ve got everything running nicely except the automatic registration. My Goals: automatically register any derived class of my base class Base only classes I mark as registrable not only direct sub-classes of Base ex: Base -> Device -> Camera -> Webcam this would make using the CRTP like described in this question

Factory, Abstract Factory and Factory Method

阅读更多关于 Factory, Abstract Factory and Factory Method

问题 I am really confused about these three terms. My understanding is that: in the Factory pattern, there is no concrete factory. The factory builds the new objects according to the parameters. in Abstract Factory pattern, there are multiple concrete factories. The client has to create different concrete factories explicitly. Is that right? What are the other differences? Furthermore, what is the Factory Method pattern? Is it same as the Factory pattern? 回答1: The Gang Of Four "Design Patterns;

How to avoid 'instanceof' when implementing factory design pattern?

阅读更多关于 How to avoid 'instanceof' when implementing factory design pattern?

问题 I am attempting to implement my first Factory Design Pattern, and I\'m not sure how to avoid using instanceof when adding the factory-made objects to lists. This is what I\'m trying to do: for (ABluePrint bp : bluePrints) { AVehicle v = AVehicleFactory.buildVehicle(bp); allVehicles.add(v); // Can I accomplish this without using \'instanceof\'? if (v instanceof ACar) { cars.add((ACar) v); } else if (v instanceof ABoat) { boats.add((ABoat) v); } else if (v instanceof APlane) { planes.add(

Dependency Injection vs Factory Pattern

阅读更多关于 Dependency Injection vs Factory Pattern

问题 Most of the examples quoted for usage of Dependency Injection, we can solve using the factory pattern as well. Looks like when it comes to usage/design the difference between dependency injection and factory is blurred or thin. Once someone told me that its how you use it that makes a difference! I once used StructureMap a DI container to solve a problem, later on I redesigned it to work with a simple factory and removed references to StructureMap. Can anyone tell me what is the difference