For Stateless object Which one we should use, whether to create Singleton class for it or create Object pool for it.
Where does the difference come between object pooling and singleton class?
what are the condition when we can choose them over each other?
Think around Stateless object only.
When we light weight objects which do not have internal state there we can us object pool. This is same as fly weight pattern from (GOF). If object is heavy and costly in terms of resource then we go for singleton.
Related
I have a interface of IType which has solve() method in it. Their are two concrete class concreteA, concreteB, which implement solve() method. Their is also a TypeFactory which takes care of creating object for concreateA and concreteB respectively. This object creation part is exposed using Facade design pattern to client.
My question is how I can expose functionlity in facade class to let client define their own defination of IType to support creation of UserDefinedType?
I think adapter or decorator pattern can be used, but I am not sure how to expose it through Facade class.
I have read lot of D-Bus documentation and understood various concepts such as:
1. Object
2. Interface
3. Method
4. Signal
5. Bus Connection
6. System vs Session Daemon
However while reading through ObjectManager::GetManagedObjects I came across this concept of "Object Tree". I know that I when I invoke the above method on a service object, it gives me all the interfaces in the tree with the service object as the root (Since the service object implements ObjectManager interface from D-Bus).
I would like someone to very clearly explain what does it mean exactly when one object comes "under" a root object in an "object tree"
Are children object just properties of parent object?
Do children object subclass the parent object (Just like OOP)
What is D-Bus Object Tree? Please!
The semantics of the object tree are determined by the particular service which is providing it. By convention, the location of objects in a tree is just determined by their object path. For example, /org/freedesktop/Accounts/User1000 is considered to be a ‘child object’ of /org/freedesktop/Accounts. However, there is no formal relationship beyond this.
To answer your specific questions:
Are children object just properties of parent object? No, they are separate objects with their own set of properties. The only thing they have in common with the parent is a prefix on their object path.
Do children object subclass the parent object (Just like OOP)? No. They may implement the same interfaces, different interfaces, or anything inbetween. Typically, they will implement a different interface — it’s quite common to have a parent object implement a ‘manager’ interface, and the child objects implement an ‘item’ interface, for describing collections of items.
Domain-driven design suggest that we should create an aggregate root by using a factory to hide the complexity. We can use the following ways to create the aggregate root:
Static factory method in a factory class
Aggregate root that has a factory method
On What basis do we make a selection between (1) and (2)?
Consider having a factory method on the on the AR when the resulting code aligns better with your ubiquitous language and when the AR has some knowledge that will simplify the creation process.
For instance, if in your domain you can add tasks to a project and tasks are modeled as ARs then Task task = project.addTask(taskId, taskName); is more expressive and simple than Task task = new Task(taskId, taskName, projectId);.
Factories are not exactly specific to DDD. You can find the Factory pattern in GoF, for example.
Usually, you make your choice based on the following:
If your factory returns different types, depending on the arguments, it should be placed in a class
If your factory always returns an instance of one class, it should be made as a static method inside this class
When it comes to DDD, you normally would have factory methods on your aggregate roots anyway, to encapsulate the complex creation logic, if you have such logic of course. Factories are named according your Ubiquitous Language and ensure that only consistent aggregates can be created.
Your first suggestion
Static factory method in a factory class
is something you should generally avoid. Public static methods are a code smell if they have service character (which factories do). It's better to create a non-static class, inject it wherever it is used and call the instance method on it. Create an interface if necessary. This approach improves testability and makes dependencies between classes explicit.
If you follow this advice, your question becomes a question of factory method pattern vs abstract factory pattern.
Factory Method
Use factory methods when there are multiple ways to construct an object of a certain class. Factory methods are preferable to direct constructor calls in this case because you can give them a descriptive name. If you use them, it usually makes sense to make the constructor private, so that clients realize that they should not call the constructor, but call the appropriate factory method.
Factory methods just wrap the constructor. As a consequence, they cannot really simplify the construction of an object (apart from giving it a name).
Abstract Factory
If constructing an object is non-trivial, the pattern of choice is the abstract factory pattern. Note that you are not required to have multiple classes to be able to use an abstract factory as suggested by Alexey Zimarev. An abstract factory makes perfect sense with just one type of object that is being created.
Abstract factories are a special kind of a service, namely a service that creates objects. As such, they can have dependencies, which they can provide to the created objects for example.
Example: Let's say you want to create an object that needs a string value and a dependency to ISomeService. Here, an abstract factory can help by providing ISomeService. The interface of the factory would then look like this:
interface IFooFactory {
IBar CreateBar(string value);
}
This factory simplifies creation of an IBar for clients, because they don't have to provide the ISomeService themselves.
In the context of DDD Aggregates
Aggregates often contain references to domain services. As such, instantiation of aggregates is often non-trivial, so the abstract factory pattern is a good fit here.
They are basically the same. Option 1. might help you avoid having a bloated entity class. Option 2. is better if the creation reads more naturally when prefixing by the name of the entity, as in
LoyaltyCard.ForCustomer(...)
SavedSearch.WithCriteria(...)
how hazelcast deals with object with in object. let me give you an example,
class Students{
String name, rollNumber;
Enrollments enrolments[];
// some methods
}
class Enrollments {
String id, subjectName;
// some methods and fields
}
as you see, Students class holds an array/list of enrollment objects. My question is, how hazelcast deals with objects in side object(in respect to memory)? what's the best way to do that?
It serializes it. Obviously you need to implement Serializable for both classes at the very least. Avoid circular dependencies and generally complex hierarchies. Otherwise as long as all member classes and their members are serializable, you are fine.
Standard Java serialization memory footprint is pretty bad, so if you have complex structures, consider DataSerializable or Portable.
Given tha nature of ValueObjects in DDD,it can be considered a collection of them as a container that contains the result set of a database query?
for example,this pseudocode could be a reasonable usage of ValueObject concept?:
List<ValueObject> resultSet = GetValueObjectsFromDB();
List<ValueObject> GetValueObjectsFromDB()
{
return ExecuteCommand("SELECT * FROM dbo.AnEntity");
}
I think you confuse Value Object which is one of the building blocks of Domain Driven Design and DTO (Data Transfert Object) which is a dumb data container.
Value Object : An object has no conceptual identity. They should be treated as immutable. Value Object plays his role in a domain model and very often have a behaviour associated with it.
DTO : It's just a dumb data container that can be used for transfering data on the wire or between architectural layers.
What you would use on the 'query' side is a DTOs tailored to your specific needs. If you want to display it on the screen or transfert this data to another system the DTOs is the way to do it.