Talk:Software design pattern: Difference between revisions

Revision as of 14:13, 11 November 2022

Latest revision as of 22:34, 18 October 2024

(6 intermediate revisions by 6 users not shown)

Line 1:

{{WikiProject Computingbanner shell|class=C|1=
{{WikiProject Computing |importance=High |software=y |software-importance=High |science=y |science-importance=High}}

{{WikiProject Computer science |class=C |importance=High}}

}}

{{archivebox|auto=yes}}

Line 77 ⟶ 79:

I'm not sure about considering encapsulation, inheritance, and exceptions to be design patterns. Encapsulation and inheritance are general directions for structuring code more than they are patterns, re-usable elements of software. They are philosophies more than patterns or blueprints. Patterns (not limited to computer science) must be unanimously recognizable. For example, an architectural design's use of the golden ratio is non-disputable. I've never seen "fundamental patterns" used anywhere outside of that cited college lecture presentation and the book it cites, Barbara Liskov's "Program Development in Java". It strikes me that the author wished to coin a new term; perhaps someone who read it can provide another opinion. My [[http://www.google.com/webhp?hl=en&btnG=Google+Search#hl=en&q=%22fundamental+pattern%22&btnG=Google+Search&aq=f&oq=%22fundamental+pattern%22&aqi=&fp=1mZ_-PL2Zjc|Google query]] yielded few relevant results. Has the term 'fundamental pattern' gained community acceptance or popular usage? And if so, do—and why do—encapsulation and inheritance qualify? Any thoughts?

Also, the page [[Fundamental pattern]] lists [[Proxy pattern]], [[Facade pattern]], and [[Composite pattern]]; all three of which are listed as structural patterns in [[Design pattern (computer science)|this page]]; and it doesn't list inheritance or encapsulation.

[[ User:dmyersturnbull | &nbsp;<fontspan colorstyle="color:#005000;">dm</fontspan><fontspan colorstyle="color:#555555;">yers</fontspan><fontspan colorstyle="color:#005000;">t</fontspan><fontspan colorstyle="color:#555555;">urnbull</fontspan>&nbsp; ]] ⇒ [[User_talk:Dmyersturnbull|talk]] 03:59, 4 June 2009 (UTC)

:If there are no objections, I'll place the ''neologism'' template:

:{{neologism}}

:for the reason cited above. Also, if its contradiction to [[Fundamental pattern]] is not resolved, I think adding contradict-other is warranted:

:{{Contradict-other|[[Fundamental pattern]]}}

:[[ User:dmyersturnbull | &nbsp;<fontspan colorstyle="color:#005000;">dm</fontspan><fontspan colorstyle="color:#555555;">yers</fontspan><fontspan colorstyle="color:#005000;">t</fontspan><fontspan colorstyle="color:#555555;">urnbull</fontspan>&nbsp; ]] ⇒ [[User_talk:Dmyersturnbull|talk]] 06:58, 10 July 2009 (UTC)

I would remove everything referring to "fundamental patterns". They simply don't belong. "Design Patterns" (ISBN-10: 0201633612) is 15 years old and surely one of the seminal works. It's still in print. It catalogs ~15 patterns from factory to vistor. That's what the term normally encompasses and what wikipedia should document.

Line 101 ⟶ 103:

It has its own page on wikipedia as being a creational pattern. <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/208.127.236.194|208.127.236.194]] ([[User talk:208.127.236.194|talk]]) 15:00, 14 August 2009 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

:A plain factory is usually considered different from a factory method no? Considering it's so important, it seem's reasonable to list all three, or just list factory and have the subtypes listed on its respective wiki page. [[Special:Contributions/82.26.250.60|82.26.250.60]] ([[User talk:82.26.250.60|talk]]) 22:26, 6 September 2023 (UTC)

: (Resolved, Factory method now listed)

Line 263 ⟶ 268:

* [http://jt.dev.java.net/files/documents/5553/150311/designPatterns.pdf Messaging Design Pattern]{{dead link|date=August 2012}} Published in the 17th conference on Pattern Languages of Programs (PLoP 2010).

* [http://media.wiley.com/product_data/excerpt/28/04700590/0470059028.pdf On Patterns and Pattern Languages] by Buschmann, Henney, and Schmidt

* {{tlp|dmoz|Computers/Programming/Methodologies/Patterns_and_Anti-Patterns/|Patterns and Anti-Patterns}}

* [http://www.doc.ic.ac.uk/~np2/patterns/scripting/ Patterns for Scripted Applications]

* [http://perfectjpattern.sourceforge.net/ PerfectJPattern Open Source Project] Design Patterns library that aims to provide full or partial componentized version of all known Patterns in Java.

Line 304 ⟶ 309:

Languished? For several years? I *think* what is meant here is that "Although design patterns have been applied practically for a long time, it was only recently that they were formalized." [[User:GeneCallahan|GeneCallahan]] ([[User talk:GeneCallahan|talk]]) 18:34, 23 December 2014 (UTC)

: Even in 2014, when the original comment here was written, this was not true; formalization of "design patterns" predates the books by some years. They were just not called "design patterns". <!-- Template:Unsigned IP --><small class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/171.20.64.8|171.20.64.8]] ([[User talk:171.20.64.8#top|talk]]) 12:33, 16 November 2023 (UTC)</small> <!--Autosigned by SineBot-->

== IVSR ==

Line 459 ⟶ 465:

Do you agree? Which approach would you prefer? [[User:Rp|Rp]] ([[User talk:Rp|talk]]) 14:11, 11 November 2022 (UTC)

== Additional Historical informatoiin ==

I've just clarified some information about Christopher Alexander at the start of the History section.

I've also added a reference to his Keynote Speech to the 1996 OOPSLA Convention. This provides more detail about the history of a Pattern Language in Architecture and how it had evolved more recently. In particular Christopher Alexander suggested significant collaboration opportunities between Software Design and the Architectural Pattern Language work he had helped pioneer. [[User:CuriousMarkE|CuriousMarkE]] ([[User talk:CuriousMarkE|talk]]) 23:35, 24 August 2024 (UTC)