Editing Balking pattern

{{Short description|Software design pattern}}
{{Multiple issues|
{{More citations needed|date=December 2010}}
{{More footnotes|date=December 2010}}
{{lead extra info |date=July 2023}}
}}

The '''balking pattern''' is a [[design pattern (computer science)|software design pattern]] that only executes an action on an [[object (computer science)|object]] when the object is in a particular state. For example, if an object reads [[ZIP file format|ZIP]] files and a calling method invokes a get method on the object when the ZIP file is not open, the object would "balk" at the request.  In the [[Java (programming language)|Java]] programming language, for example, an <code>IllegalStateException</code> might be thrown under these circumstances. In [[C Sharp (programming language)|C#]] it would be <code>InvalidOperationException</code>.
 
There are some specialists{{who|date=November 2010}} in this field who consider balking more of an [[anti-pattern]] than a design pattern.  If an object cannot support its [[API]], it should either limit the API so that the offending call is not available, or so that the call can be made without limitation. It should:
* Be created in a "sane state";{{elucidate|date=April 2015}}
* not make itself available until it is in a sane state;
* become a [[Facade pattern|facade]] and answer back an object that is in a sane state.

==Usage==
Objects that use this pattern are generally only in a state that is prone to balking temporarily but for an unknown amount of time.{{Citation needed|date=May 2009}}  If objects are to remain in a state which is prone to balking for a known, finite period of time, then the [[guarded suspension pattern]] may be preferred.

==Implementation==
Below is a general, simple example for an implementation of the balking pattern.<ref name=Grand>{{cite book| last = Grand | first = Mark| title = Patterns in Java, Volume 1: A Catalog of Reusable Design Patterns Illustrated with UML, Second Edition| year = 2002| publisher = John Wiley & Sons| location = Indianapolis, Ind}}</ref> As demonstrated by the definition above, notice how the "synchronized" line is utilized. If there are multiple calls to the job method, only one will proceed while the other calls will return with nothing. Another thing to note is the <code>jobCompleted()</code> method. The reason it is synchronized is because the only way to guarantee another thread will see a change to a field is to synchronize all access to it. Actually, since it is a boolean variable, it could be left not explicitly synchronized, only declared volatile - to guarantee that the other thread will not read an obsolete cached value.

<syntaxhighlight lang="java">
public class Example {
    private boolean jobInProgress = false;

    public void job() {
        synchronized(this) {
            if (jobInProgress) {
                return;
            }
            jobInProgress = true;
        }
        // Code to execute job goes here
        // ...
        jobCompleted();
    }

    void jobCompleted() {
        synchronized(this) {
            jobInProgress = false;
        }
    }
}
</syntaxhighlight>

==See also==
*[[Read and write lock pattern]]
*[[Guarded suspension|Guarded suspension pattern]]

==References==
{{reflist}}

{{Design Patterns patterns}}

[[Category:Software design patterns]]
[[Category:Articles with example Java code]]
[[Category:Concurrency (computer science)]]


{{compu-prog-stub}}