design_pattern | 二十三种设计模式JAVA实现 | Architecture library
kandi X-RAY | design_pattern Summary
kandi X-RAY | design_pattern Summary
二十三种设计模式JAVA实现
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
- Main entry point
- Shortcut for testing
- The main entry point
- Test program
- Main method
- Entry point for the Terminal
- The main method
- Main runner
- Main method for testing
- Main method
- Entry point
- The main method
- Handle state transitions
- Set state
- Removes an observer from the set
- Checks if the current aggregator is done
- Set the B builder part
- Gets the current item
- Executes the action
- Visits the given visitor visit this element
- Makes the visitor visit this element
- Retrieves the first item in the aggregate
- Visit a concrete element B
- Handles an event
- Handle a request
- Returns the next item
- Displays the current subject
- Displays the named depth
- Visit a concrete element
- Send a message
- Invoked after decorator is invoked
design_pattern Key Features
design_pattern Examples and Code Snippets
Community Discussions
Trending Discussions on design_pattern
QUESTION
I asked here how I should handle the situation when I need to inform observers only when specific attribute of object changes.
I received very nice reply with reference to GoF where is written:
Blockquote Specifying modifications of interest explicitly. You can improve update efficiency by extending the subject's registration interface to allow registering observers only for specific events of interest. When such an event occurs, the subject informs only those observers that have registered interest in that event. One way to support this uses the notion of aspects for Subject objects. To register interest in particular events, observers are attached to their subjects using
void Subject::Attach(Observer*, Aspects interest);
Blockquote where interest specifies the event of interest. At notification time, the subject supplies the changed aspect to its observers as a parameter to the Update operation. For example:
void Observer::Update(Subject*, Aspect& interest);
This makes sense and I would like to ask how to correctly implement this in Java. I have few ideas but I am not sure if there isn't something better.
Let's imagine I have subject class WeatherStation[temperature, humidity, windSpeed ...]
and I have observer class LimitedDisplay[show (shows only temperature and humidity)
and for some reason I need that the display should be able to differentiate when only temperature was changed and when only humidity was changed.
I was thinking that I could create some enum WeatherStationInterest[TEMPERATURE, HUMIDITY WIND_SPEED...]
and then have the subject interface like this:
ANSWER
Answered 2020-Dec-10 at 11:31Another option is to have a set of interfaces:
QUESTION
I was going through Builder pattern and had a couple of question that I thought needed clarification
- Is builder pattern implemented through Abstract class or through interfaces. There are few posts that uses interface https://sourcemaking.com/design_patterns/builder
https://refactoring.guru/design-patterns/builder
...can list more
and others uses abstract class https://www.dofactory.com/net/builder-design-pattern
Note: The way I think is that it should be implemented using Abstract class. This rationale is based on the assumption that this way I may/may not implement them in derived class (as there could be a possibility that a few concrete class does not implement them)...
This assumption could be entirely wrong though.
- If the above assumption is wrong then wont it violate LSP. Since one condition in LSP say that you cant have "not implemented methods" in your derived class.
Or I have misunderstood it completely...
...ANSWER
Answered 2020-Sep-10 at 00:01This became too long for a comment...
The patterns from the GoF book are older than Java. It was Java that later introduced the (silly) distinction between interface and abstract class. When the GoF refers to an interface, they simply mean an abstraction, and you can implement it using any language feature that enables abstraction.
That being said, the GoF Builder Pattern is overcomplicated. The pattern is useful even without polymorphism. And I think that is how it's most often implemented. If you're using Java, that would be Josh Bloch's Builder Pattern from Effective Java.
I don't mean to dismiss the LSP question, but if the real goal here is to learn to use a Builder effectively, then my advice is to ignore the (outdated) version from the GoF and look at a modern implementation where that question doesn't arise. If you really wanted to ask about the LSP, then I suggest a new question focused specifically on that topic, separate from the Builder Pattern.
To more directly address the questions in the OP,
- The builder pattern can be implemented through abstract classes or through interfaces. It does not matter which. Modern implementations more often use neither.
- LSP conformity will depend on how you implement (and document) the pattern. It would be possible to violate the LSP (or not) using interfaces or abstract classes. Eliminating both eliminates this question.
QUESTION
The factory in this tutorial obviously violates the OCP. Every time a shape is added to the system, we need to add it in the factory to support it. I'm thinking of another implementation and I'd like to know if there are any drawbacks.
...ANSWER
Answered 2020-Apr-12 at 08:13There are a few drawbacks to this method.
Firstly, when the Class passed to getShape requires a constructor argument, the .newInstance will fail. For example:
QUESTION
I feel like I have an ok grasp on the design pattern, however I can't seem to get my head around one thing and it doesn't seem to be exactly explained in the resources I've looked at.
That question is, how is the data common, without the data being static, considering the objects are separate entities?
https://www.tutorialspoint.com/design_pattern/flyweight_pattern.htm
In this example, I cannot figure out where the optimisation is occurring, as it looks as if the objects are just being created each time as normal.
...ANSWER
Answered 2017-Nov-13 at 12:36The ShapeFactory
in your linked example will create one Circle
per color:
QUESTION
I am trying to make an implementation of the Bridge Design Pattern, following the steps on Tutorials Point. I am converting the code from Java to PHP and changing some names.
The problem is, when I try to pass the concrete bridge implementer class to the concrete class implementing interface, an error is throw.
My code is as follows:
...ANSWER
Answered 2018-Jun-20 at 02:49yeah should be $redRocket->launch();
instead of $redRocket.launch();
like what nigel ren said
QUESTION
Suppose we a design pattern similar to this one:
...ANSWER
Answered 2019-Oct-03 at 16:29A move constructor would be appropriate:
QUESTION
I'm following the Singleton design pattern as described in this book (https://github.com/PacktPublishing/Go-Design-Patterns/blob/master/Chapter02/main.go) and I have this code in file "singleton2.go":
...ANSWER
Answered 2019-Jun-12 at 22:01Follow the logic of your code and it's apparent where the problem is.
When you declare, but do not initialize the singleton (var instance *singleton
) then instance
is nil
. Calling GetInstance
evaluates instance == nil
as true and returns a new *singleton
every time it is called. That is why counter2
will never equal expectedCounter
- each call to GetInstance
is returning a new counter instance.
When you initialize the singleton instance (var instance = &singleton{}
) then calls to GetInstance
will return that singleton instance since it is not nil
.
I imagine you'd want to modify GetInstance
to something like this:
QUESTION
In the 1994 book Design Patterns: Elements of Reusable Object-Oriented Software by the "Gang of Four", I noticed in the C++ code examples that all methods are either declared as public
or protected
(never as private
) and that all attributes are declared as private
(never as public
or protected
).
In the first case, I suppose that the authors used protected
methods instead of private
methods to allow implementation inheritance (subclasses can delegate to them).
In the second case, while I understand that avoiding public
and protected
attributes prevents breaking data encapsulation, how do you do without them if a subclass need access a parent class attribute?
For example, the following Python code would have raised an AttributeError
at the get_salary()
method call if the _age
attribute was private
instead of protected
, that is to say if it was named __age
:
ANSWER
Answered 2019-Jun-09 at 07:39I have finally found out an obvious solution by myself: redeclaring the private
attribute of the parent class in the subclass:
QUESTION
I am currently learning the Template Method pattern in python.
I am wondering if there is any way to protect some of the functions from the base class so that the subclass cannot overwrite? As below, the _primitive_operation_3
from the subclass overwrites the same function from the base class.
ANSWER
Answered 2019-Apr-15 at 18:38You can't prevent subclasses from using the same names, no. You can protect names against accidental shadowing, however, by giving the name a double underscore prefix:
QUESTION
Im dealing with this problem.
I have base class Worker
that is abstract. Its base class for Driver
and AmountBonus
. That Bonus
is writed based on Decorator design pattern. My decorator decorate one of property from Worker
.
How it looks in code:
...ANSWER
Answered 2019-Jan-10 at 19:09What you're doing makes no sense. Decorators are utility classes; they overlay programmatic functionality on to the classes they decorate. They are not something that can nor should be persisted to something like a database.
In other words, if your object is a Driver
, then you need to keep it a Driver
, not wrap it in an AmountBonus
decorator and then attempt to persist that. Later, if you need whatever functionality the AmountBonus
decorator adds again, you simply wrap your Driver
instance in it again.
It doesn't even look like you're doing anything interesting with the decorator here, but if there is something that occurs just by the act of wrapping a Driver
instance, then you'll need to fetch out somehow that wrapped Driver
instance afterwards to actually save that and not your decorator.
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install design_pattern
You can use design_pattern like any standard Java library. Please include the the jar files in your classpath. You can also use any IDE and you can run and debug the design_pattern component as you would do with any other Java program. Best practice is to use a build tool that supports dependency management such as Maven or Gradle. For Maven installation, please refer maven.apache.org. For Gradle installation, please refer gradle.org .
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page