Singleton Vs. Factory Pattern

Most commonly, singletons don't allow any parameters to be specified when creating the instance - as otherwise a second request for an instance but with a different parameter could be problematic! (If the same instance should be accessed for all requests with the same parameter, the factory pattern is more appropriate.)...

• The factory pattern can be used if you need a single instance of a base type, but the exact type isn't known until runtime.

http://csharpindepth.com/Articles/General/Singleton.aspx

Fowler's Observations Outdated?

Fowler’s initial thinking was confined to HTML web presentation problems. He expanded the inventory in subsequent years through a series of posts that can be reached from here. The combined corpus of patterns still resonate for WPF and Silverlight developers even if the details aren’t a perfect fit for these more recent technologies.

http://neverindoubtnet.blogspot.com/2009/05/birth-and-death-of-m-v-vm-triads.html

Singleton Misused

 I saw a singleton used to store a reference to a web service, and then the developer called it from everywhere. So instead of properly designing her class library, she just had a spaghetti bowl of code interaction.
http://forums.silverlight.net/p/14017/45946.aspx

Association and aggregation -- semantic mismatch

At the code level, a pointer (reference in Java and C#) is used to represent both association and aggregation. There is a semantic mismatch between the code and the object model .

http://www.agiledeveloper.com/articles/cloning072002.htm

Boolean: a type of Enum

the Boolean data type ... is an enumerated type, that can have one of only two values : True or False.

http://www.delphibasics.co.uk/Article.asp?Name=Logic

Protected instance variables are an abomination

[A]n object's instance variables (member fields that aren't constants), should always be private. Period. No exceptions. Ever. I mean it. (You can occasionally use protected methods effectively, but protected instance variables are an abomination.) You should never use get/set functions for the same reason—they're just overly complicated ways to make a field public (though access functions that return full-blown objects rather than a basic-type value are reasonable in situations where the returned object's class is a key abstraction in the design). 

http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html?page=2

Small Method Size Good for Debugging

Also bear in mind that the less code in each method the easier it will be to pin-point the location of the error.

Also you should bear in mind that throwing an exception is a big overhead and should only be used when a real exception has occurred...something you really did not expect and cannot recover from.

http://web.archive.org/web/20100402092458/http://blog.thekid.me.uk/archive/2007/07/25/debugging-tips-for-sharepoint-and-wss-exceptions.aspx

Web Services vs. Native Invocation

The performance overhead of invoking web service operations is several orders of magnitude larger than that of invoking native Java classes. That's because marshaling and un-marshaling XML, processing SOAP envelopes, etc. are expensive operations.

 http://www.oracle.com/technetwork/articles/soa/data-tier-caching-for-soa-101753.html

Do Input Normalization Server Side

"I could either handle it on the client or more likely handle it [upper case conversion of input search value] at the [WCF] service ... that way I don't need the client developer to have to worry about it."

Robert Green - WPF Using Visual C# 2010

C# 'using' = syntatic sugar

As you know, the using statement is syntactic sugar for a try/finally that disposes of the IDisposable object. 

Michael Burr
 - http://stackoverflow.com/questions/248961/c-sharp-using-statement-catch-error 

Perlis Epigrams

e.g. "It is easier to change the specification to fit the program than vice versa

We will never run out of things to program as long as there is a single program around.

http://web.archive.org/web/19990117034445/http://www-pu.informatik.uni-tuebingen.de/users/klaeren/epigrams.html

ECM Strategy

Technology can enable streamlined management of content, but the underlying strategy must come first.

http://www.aiim.org/What-is-ECM-Enterprise-Content-Management

Three Types of State

Screen State is data displayed on a user interface. Session State is data that the user is currently working on. Session state is seen by the user as somewhat temporary, they usually have the ability to save or discard their work. Record State refers to more permanent data, data that's expected to sit around between the sessions.

 http://martinfowler.com/eaaDev/OrganizingPresentations.html

Adoption of View/Controller Separation

[T]he MVC approach did two separations. The most important separation was Separated Presentation - separating the model from the view/controller. The other separation, that of the view and controller, was not popular in rich client GUI frameworks, although it did have a resurgance with web based user interfaces. In MVC the view was a simple display of information in the model and the controller handled the various user input events. This doesn't work well with most GUI frameworks because they are designed so that the UI controls both display and receive the user input events.

 http://martinfowler.com/eaaDev/OrganizingPresentations.html

Crystalization vs. Entropy

The formation of crystals does not disprove the second law of thermodynamics:

It is true that crystals and other regular configurations can be formed by unguided processes. And we are accustomed to saying that these configurations are "organized." But crystals have not been spontaneously "furnished with organs." The correct term for such regular configurations is "ordered." The recipe for a crystal is already present in the solution it grows from — the crystal lattice is prescribed by the structure of the molecules that compose it. The formation of crystals is the straightforward result of chemical and physical laws that do not evolve and that are, compared to genetic programs, very simple.
http://www.panspermia.org/seconlaw.htm

Controller-View = Tool

The Controller is responsible for creating and coordinating a number of related Views. I sometimes think of the Controller-View combination as a Tool that the user employs to work with the system’s latent information.

http://heim.ifi.uio.no/~trygver/2006/09-JavaZone/mvc-dca.pdf

Person.Save()

A person “saves” themselves into various domains when they register to vote, sign up for a mailing list, sign a petition, apply for citizenship. We could come up with all sorts of cute analogies where the immigration clerk is the DAO, etc., but the basic point is that these things are initiated by the person (and indeed some can only be initiated by the person themselves).

Jaime Metcher - http://blog.objectmentor.com/articles/2007/11/02/active-record-vs-objects

Benefits of Objects over Data Structures

In short, algorithms that employ objects are immune to the addition of new types.

http://blog.objectmentor.com/articles/2007/11/02/active-record-vs-objects

Why SRP?

If a class assumes more than one responsibility, then there will be more than one reason for it to change.

http://www.objectmentor.com/resources/articles/srp.pdf

Mixins vs. OO

[M]ixins are a type of inheritance ... Inheritance is fundamentally at odds with encapsulation, the addition of capabilities to objects with a single line quickly muddle the responsibilities of classes, and mixins themselves aren’t even the best option for code reuse across classes.

 http://justinleitgeb.com/2012/05/moving-beyond-mixins/

DCI Presentation

"A use case is not an algorithm because a use case can be non-deterministic"
"DCI is really about capturing the algorithms in a framework that reflects the use cases"

"Good objects are dumb, not smart...and that's probably against what your professors told you"

"One of the important things about your grandfather's object-oriented programming is that you couldn't reason about the state of the system. You could only reason about the state of an object. "

"TDD is about the state of an object that has no business value"

"Keep use-cases goal driven, and use habits for these things at a lower level [i.e. the 'include's of use cases]"

"A withdrawal is a fairly complex business practice. It doesn't belong in a dumb object [e.g. savings account - re: decreaseBalance vs. withdraw]"

"Customer says, 'I want this account to pay all my bills'. Ok, well define some roles from the use-case 'pay all bills' and will inject the right parts of this use case into this class [savings account] at run time to make it do what it needs to do. And then we don't have to worry about this dumb domain class. That can remain relatively stable. Good design is about separating what is stable from what changes. "

"'transfer funds' is a use-case. How do I represent use-cases, well, as a context"

"All [the context 'execute' method] does is say source account.transfer to, and the rest just happens because all the wiring has been done here [context initialization], we just go to the first role in the use-case, initiate it with an event, and the rest just happens.  This 'execute' in context is a way of stacking the context. Contexts stack. ... I can call a context. This is a way of reusing use-cases or really, re-using habits, where I can build a context that represents a habit, and call it from another use case. "

re: "chunking," " It might be nice to have this full use-case laid out before you, but you couldn't understand that anyhow. We understand things by well ... two different cognitive tools. One is divide and conquer (or partitioning) and the other is compression, and we need both; and so this notion of context is the way of doing divide and conquer, of splitting things up into units of use cases that we can understand. Roles are a further chunking of functionality ... "

"I said that an account is an object right? I lied. ... what are the objects in a bank, are they accounts? what are the objects? transaction logs, audit trails. What is the balance on your account? It's the iteration over an audit trail, adding up all the deposits and subtracting all of the withdrawals. Your balance isn't sitting on a disk somewhere, it's computed, it's a use case! An account isn't an object. The account ID might be an object, but the account is an active thing -- in your terms a business process. ... What is an account in DCI, because if it's an object, then its a domain object and has to be smart; and we don't like smart domain objects, they don't evolve well. ... It it part of the user mental model? Of course. We talk about accounts, so it must be a thing if we're doing object-oriented programming which is capturing the end-user model in the code, then it [the account] should kind of fly like an object, quack like an object, and walk like an object. Well what is it? It's a context [ see also how inbox is a context, i.e. InboxContext]. What is a context? A context is a use-case. Well can we make a context to be a collection of related scenarios that involve a certain set of roles? What is a collection of related potential scenarios between an end-user and system under construction? That's a use case. And we reflect it in DCI as a context object. "

"Roles ... have the algorithms in them but they really don't have state. Most roles in DCI are stateless. They are pure algorithm. The state has to be remembered in the domain objects. And each role works with one ore more contexts or gets injected into some domain object, so that contexts can organize their bindings and kick off new executions as events come in. But it turns out that contexts [ points to blue ball on path between role and domain object pink ball] ... can behave like domain objects, like...savings account does. It's not an object, it is a collection of interactions between roles around a set of scenarios [see 'scenario' in BDD] that we call use-cases. And so this kind of solves a very very very longstanding problem in object-orientation, 'cuz everyone wants to make an account an object, and it really isn't. And there's all kinds of problems with the lifetime of these ideas if you treat them as objects. It's the algorithms of the account that are long-lived, and the identity of the account. The account identity may be a long-lived object, but not the account. Things like the account balance are very ephemeral. So they're computations. We now have architectural home for these computations that you don't find in most object-oriented methods.

"I said that domain models should be dumb. Do I have any rules for saying what things should go there and what things don't. It has to do with this concept of shear layers [layers of maintenance frequency, see house architecture] and understanding how stable are things. And so you go to something like Eric Evans book on domain driven design, and you look for the things that are stable. Those are the things that I want in my domain model. If things are going to be part of things I sell to the business that are going to be more dynamic, I want those in the roles [above]. So ... another way of looking at it; it's a dichotomy of what the system is and what the system does. So the domain model, the dumb dumb dumb classes down there are what the system is, so a system is transaction logs, audit trails, what it does is transfer money and pay bills. ...  [explains how 'domain model' or 'data model' is the D in DCI and M in MVC]... This is the programmers side of MVC  MVC is the end-user's side to get their mental model lined up; [DCI] is getting the programmer's mental model lined up. Same model, same 'M'.

James O. Coplien

http://vimeo.com/8235574

Algorithms in DCI

The passive objects are the Data in DCI, and the active objects are the algorithms that coordinate and manipulate the passive objects. ...

 ...there needs to be a few application-specific things: the trigger for a spell checking use case, the context in which the use case executes (the casting or wiring up of the actors to play different roles), and the code for the use case itself.

 http://pettermahlen.com/2010/09/10/dci-architecture-good-not-great-or-both/

SRP killed OOP?

Without taking into account the basics of what an object’s responsibilities are one could follow SRP to the demise of their object oriented code and easily end up with procedural code and many do. 

 http://codebetter.com/gregyoung/2010/03/24/the-98th-thing-every-programmer-should-know/

Compiler vs. Unit Test Feedback

The benefit of unit testing is that it provides us with faster feedback than integration testing or systems testing would do. That's all fine, but the compiler provides even faster feedback, so why should I resort to unit testing if the compiler can give me feedback sooner?

 

 Mark Seemann - http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx

Use Cases - Poor Modeling Tool

Use-case driven analysis leads to poor object modelling in my experience. My position on this is that use-cases should be used to validate the object model, not to identify it.

http://blog.nakedobjects.org/2007/11/19/workflow-a-triumph-of-hope-over-experience/

Windows vs. Web Apps

The system should be responsive, with no delays between execution and
the results, except where those delays are appropriate for the knowledge
domain itself.

http://hci.ucsd.edu/hollan/direct-manip.pdf

Linguistic Determinism

... the notion of linguistic determinism ... the way we think about something is shaped by the vocabulary we have for talking about it .... changing the users’ conception of the domain may
prevent some intentions from arising at all.

http://hci.ucsd.edu/hollan/direct-manip.pdf

Coarse-grained vs. Fine-grained

Coarse-grained components exhibit loose coupling, whereas fine-grained components are often tightly coupled. For example, if recompiling both the consumer and the provider resolve some problem in the interaction, then the two components were tightly coupled.

 http://www.ibm.com/developerworks/webservices/library/ws-soa-granularity/

On Direct (UI) Manipulation

The goal ... is to minimize cognitive effort.

http://hci.ucsd.edu/hollan/direct-manip.pdf

Naked Objects or MVC

The belief that views should be independent of objects is just a self-fulfilling prophecy.

http://blog.nakedobjects.org/2007/10/25/user-interfaces-the-enemy-of-domain-driven-design/

Law of Demeter

When applied to object-oriented programs, the Law of Demeter can be more precisely called the “Law of Demeter for Functions/Methods” (LoD-F). In this case, an object A can request a service (call a method) of an object instance B, but object A cannot "reach through" object B to access yet another object, C, to request its services. Doing so would mean that object A implicitly requires greater knowledge of object B's internal structure. Instead, B's interface should be modified if necessary so it can directly serve object A's request, propagating it to any relevant subcomponents. Alternatively, A might have a direct reference to object C and make the request directly to that. If the law is followed, only object B knows its own internal structure.

 http://en.wikipedia.org/wiki/Law_of_Demeter

Bounded Contexts

People are talking about two entirely different things when they chat about a policy in the context of a general workflow versus a policy in the context of payroll auditing. If you use the same policy class, you're fattening the profile of that class and getting a long way from tried-and-true best practices such as the Single Responsibility Principle (SRP).
Systems that fail to isolate and insulate Bounded Contexts often slip into an architectural style (amusingly) called The Big Ball of Mud. ... 
When you use modules (or namespaces) to divide up your model, you really want to question whether you're dealing with a separate context. The cost of cleaving out another context is usually much higher: now you have two models, likely in two assemblies, that you need to connect with application services, controllers, and so on.

http://msdn.microsoft.com/en-us/magazine/dd419654.aspx

Interface vs. Implementation

The repository implementations can reference and implement all the interfaces they want, now that I picture it more. In fact, there's nothing stopping you from having one giant implementing class which implements all repository interfaces in every domain you have. It's kind of silly, but it's allowed. The abstractions and separation of concerns are in the interfaces. The implementation is of less concern because it should be disposable/replaceable. – David Mar 21 '11 at 22:37    http://stackoverflow.com/questions/5384246/ioc-and-managing-interfaces

DataContext Represents the Database

1. Notice that the code contains classes named TasksDataContext and TasksList. The TasksDataContext class represents the database, and the TasksList class represents the database table.
   
   http://msdn.microsoft.com/en-us/library/bb470374(v=VS.90).aspx

Active Record vs. Domain Model

How do you devise your classes? Which capabilities should they feature? In particular, should your classes be aware of the database? Should they include logic (that is, methods) or be limited to just exposing properties? There are two main patterns you can refer to: Active Record and Domain Model.
In the Active Record pattern, your classes are closely modeled after database tables. You mostly have one class per table and one property per column. More importantly, classes are responsible for their own persistence and their own simple, minimal domain logic.
According to the Domain Model pattern, your classes are aimed at providing a conceptual view of the problem’s domain. These classes have no relationships with the database and have both properties and methods. Finally, these classes aren’t responsible for their own persistence. If you opt for a Domain Model approach, persistence has to be delegated to a distinct layer—the DAL. You can write this layer yourself, but it wouldn’t be much fun. A well-done DAL for a library designed according to the Domain Model pattern is nearly the same as an ORM tool. So why not use one of the existing ORM tools?

 http://msdn.microsoft.com/en-us/magazine/hh456393.aspx

Domain Model (DDD) vs. "Entity Model"

In the scope of this article, I’m not using the meaning that results from the Domain-Driven Design (DDD) methodology. For me, here, the domain model is simply the object model you persist—entity model might be another equivalent—and less confusing—term.

 http://msdn.microsoft.com/en-us/magazine/hh456393.aspx

Benefit of Published APIs

You definitely can create your own solutions for all these problems, but there are a lot of benefits to using applications with published APIs. One of the main benefits is that many developers know and understand what these APIs are and how they work. If you need to augment your staff, for instance, you can hire a consultant that is already familiar with these well-documented APIs. If you write your own, guess what; you also get to pay that person to learn your proprietary system.

http://msdn.microsoft.com/en-us/library/ms972319.aspx

Data Access Methods Change Frequently

Data access changes frequently.  Historically, the industry has modified data access techniques at least every three years; therefore, we can count on needing to modify data access three years from now for any healthy, long-lived systems that's mission-critical to the business.

 http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

Dependency Lookup v Dependency Injection

So what should you choose, Dependency Lookup or DI? If you use Dependency Lookup, there are hard dependencies on the framework that you use or the factories that must be created. It becomes larger amount of "glue code" and the code is not as easy to test. Therefore, DI used if possible.

Dependency Lookup or Dependency Injection

Enums and Booleans are Evil

[Y]ou need to be very careful with exposing state that is used for decision making in your code. It can be very easy to end up with a mass of untracked dependencies.

Enums are Evil: The State Pattern

Role Interface

The strength of a role interface is that it clearly communicates the actual collaboration between an activity and its successors. Often a class doesn't use all the methods of a class, so it's good to show which ones are actually needed. This can be particularly useful if you need to substitute it later on. A header interface forces you to implement every method, even if you're not going to need them; but with a role interface you only need to implement exactly what's needed.

http://martinfowler.com/bliki/RoleInterface.html

Leaky Abstractions Paradox

And all this means that paradoxically, even as we have higher and higher level programming tools with better and better abstractions, becoming a proficient programmer is getting harder and harder.

http://www.joelonsoftware.com/articles/LeakyAbstractions.html

Aggregate Roots vs Entities vs Value Objects

Entities can hold references to any Aggregate Root, but never to any other Entity or VO within theAggregate. To access any other part of the Aggregate, you must navigate from the Aggregate Root.

http://devlicio.us/blogs/casey/archive/2009/02/16/ddd-aggregates-and-aggregate-roots.aspx

RDMS vs OOP Data Protection

RDBMS tend to use rule-based and role-based protection and security mechanisms instead of direct interface restrictions. It could be said that OOP encapsulation uses "additive" security and protection control mechanisms; while RDBMS tend to use "subtractive" mechanisms.

http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch

LINQ vs DTOs

Commercial ORMs contain a rich set of features for dealing with the object-relational impedance mismatch. LINQ to SQL tracks changes to object state and converts queries composed using LINQ into native SQL. Populating and returning DTOs from the results of a query executed through ADO.NET is just a different method of transfer from returning datasets

pmarflee
http://stackoverflow.com/questions/817733/using-asp-net-mvc-without-an-orm

Helper Classes and SRP/DRY

The single responsibility principle sometimes drives the creation of helper classes as inclusion of their functionality could leave the core class with multiple responsibilties. Helper classes may also be created to stick with the DRY Principle (Do not Repeat Yourself); i.e. a piece of code that somehow seems to appear in all sorts of places needs to be consolidated in one place but doesn't have a natural home (though one should use this case very sparingly - it's more likely that you don't yet fully comprehend what's going on in your object model).

Peer Reynders
http://www.coderanch.com/t/100578/patterns/helper-functions-good-design

Use Interfaces and Small Classes - Seemann

Lots of small classes sounds just fine :)

Particularly if you let each class implement an interface and have the different collaborators communicate through those interfaces instead of directly with each other, you should be able to achieve a so-called Supple Design (a term from Domain-Driven Design) with lots of loose coupling.

Mark Seemann

http://stackoverflow.com/questions/1963991/srp-and-a-lot-of-classes

An Anti-Pattern Criterion: Requires too much Brain Power

The problem with using a Service Locator isn’t that you take a dependency on a particular Service Locator implementation (although that may be a problem as well), but that it’s a bona-fide anti-pattern. It will give consumers of your API a horrible developer experience, and it will make your life as a maintenance developer worse because you will need to use considerable amounts of brain power to grasp the implications of every change you make.

http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx

Documentation is "Icky"

At least in the context of DI. Take it from Mark Seemann:

By perusing the source code (or using Reflector) or consulting the documentation (ick!) we may finally discover that we need to register an IOrderValidator instance with Locator (a completely unrelated static class) before this will work.

http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx

C is Faster

[M]any CGI programs are still written in C, and they work faster and better than any true scripting language.

Ajax - The Definitive Guide (O'Reily, Holdener)

Berners Lee on Taxonomy

[T]he relationships between subjects are web-like rather than tree-like, even for people who agree on a web may pick a different tree representation. These are my (oft repeated) general comments on the dangers of hierarchical classification as a general solution.

http://www.w3.org/Provider/Style/URI

PDLs

Page description languages are textual or binary data streams. In principle, the same data stream could be rendered multiple times to generate multiple copies of the same image. They are distinct from graphics APIs such as GDI and OpenGL that can be called by software to generate graphical output.

http://en.wikipedia.org/wiki/Page_description_language

SVG SMIL would make sense...

SVG SMIL would make sense when you want a high, smooth frame rate while
animating many objects on the screen at once. JS plus a timer would hit a
ceiling at some point as you increase the frame rate and number of objects.
Flash, for example, doesn't have you do animation through a timeout type
method; I believe there are tweening type functions which are essentially
like SMIL where you set the start and end points and what you want to change
over time.http://www.blogger.com/img/blank.gif

Brad Neuberg http://groups.google.com/group/openweb-group/browse_thread/thread/c7da347f0c239751

Troubleshooting - Bacon Style

For Bacon, finding the essence of a thing was a simple process of reduction, and the use of inductive reasoning. In finding the cause of a phenomenal nature such as heat, one must list all of the situations where heat is found. Then another list should be drawn up, listing situations that are similar to those of the first list except for the lack of heat. A third table lists situations where heat can vary. The form nature, or cause, of heat must be that which is common to all instances in the first table, is lacking from all instances of the second table and varies by degree in instances of the third table.

http://en.wikipedia.org/wiki/Novum_Organum

"A Priori"

If these are questions which admit of doubt, that doubt is not to be
met by an endeavour to settle the point of dispute `a priori[...]

An Investigation of the Laws of Thought, by George Boole

Predicate - Meaning

pred·i·cate (prd-kt)
v. pred·i·cat·ed, pred·i·cat·ing, pred·i·cates
v.tr.
1. To base or establish (a statement or action, for example): I predicated my argument on the facts.
2. To state or affirm as an attribute or quality of something: The sermon predicated the perfectibility of humankind.
3. To carry the connotation of; imply.
4. Logic To make (a term or expression) the predicate of a proposition.
5. To proclaim or assert; declare.

http://www.thefreedictionary.com/predicate

Functions versus Methods

Functions stand on their own ... while methods are functions inside an object's dictionary, and we invoke them through the object reference.

http://odetocode.com/blogs/scott/archive/2007/07/05/function-apply-and-function-call-in-javascript.aspx

Javascript OO

[E]very JavaScript method has an implicit "this" parameter that represents the object through which the method was invoked. "this.x" will reference the x property of point1, because we invoke the add method using point1...

When we use the new operator with the Point function, the new operator will first create a new object. The new operator then invokes the Point function and passes a reference to the newly created object in the implicit "this" parameter.

...all objects created by a constructor function will have the same prototype

..so the prototype approach is more efficient (shared function objects)

A closure in JavaScript is an inner function that references a local var or parameter in its outer function. Those local variables and parameters, which typically go out of scope when the outer function finishes execution are now "enclosed" by the inner function, which can continue to reference and use those variables.

http://odetocode.com/Articles/473.aspx

Rube

"She's kind of a rube"

of Erin. Michael Scott, The Office (U.S.): Season 6, Ep. 22 - Secretary's Day

Content Types Vs. List Columns

I always create Site Columns and Content Types. Harsh experience has told me that anything implemented will probably seen as a cool idea by someone and will request it to be implemented elsewhere on the same site collection.

-James Love
http://sharepoint.stackexchange.com/questions/13409/content-types-vs-custom-list-field

Refactoring - Many Small Functions

I look at a method that is too long or look at code that needs a comment to understand its purpose. I then turn that fragment of code into its own method.

http://sourcemaking.com/refactoring/extract-method

Strategy Pattern - What's not to like?

The Strategy pattern uses aggregation instead of inheritance. In the Strategy pattern behaviors are defined as separate interfaces and specific classes that implement these interfaces. Specific classes encapsulate these interfaces. This allows better decoupling between the behavior and the class that uses the behavior.

http://en.wikipedia.org/wiki/Strategy_pattern

We often use small strategy objects when we need to vary behavior. ... such procedural objects usually are small and are used when we have a particular need for flexibility.

http://sourcemaking.com/refactoring/convert-procedural-design-to-objects

Object diagrams

Object diagram gives a pictorial representation of class diagram at any point of time.

http://www.codeproject.com/Articles/28445/UML-Interview-Questions-Part-1

UML Associations (objectmentor)

The black diamond represents composition. It is placed on the Circle class because it is the Circle that is composed of a Point. The arrowhead on the other end of the relationship denotes that the relationship is navigable in only one direction. That is, Point does not know about Circle. In UML relationships are presumed to be bidirectional unless the arrowhead is present to restrict them. Had I omitted the arrowhead, it would have meant that Point knew about Circle. At the code level, this would imply a #include “circle.h” within point.h. For this reason, I tend to use a lot of arrowheads. ... In this case we have represented the composition relationship as a member variable. We could alsohave used a pointer so long as the destructor of Circle deleted the pointer. ... There are other forms of containment that do not have whole / part implications. For example, Each Window refers back to its parent Frame. This is not aggregation since it is not reasonable to consider a parent Frame to be part of a child Window. We use the association relationship to depict this.

http://www.objectmentor.com/resources/articles/umlClassDiagrams.pdf

Scrumbabble

Using the values outlined in the Agile Manifesto, development teams can deliver high quality software fast. But how can development teams balance their quality strategies with mandates to deliver shippable software in short increments?

From a received spam marketing email

Inelegant Ugliness Under the Windows Hood?

If the Security Zones: Use only machine settings setting is not enabled in Group Policy, or if the Security_HKLM_only DWORD value does not exist or is set to 0, computer settings are used together with user settings.

However, only user settings appear in the Internet Options

. For example, when this DWORD value does not exist or is set to 0,

HKEY_LOCAL_MACHINE

settings are read together with

HKEY_CURRENT_USER

settings, but only

HKEY_CURRENT_USER

settings appear in the Internet Options.

http://support.microsoft.com/kb/182569

q

The right way to organize a project

The right way to organize a project is to break it into small enough bits that can be demoed individually. If you can't do any demos until everything is in place the architecture needs to be re-thought.

by MWTJ

http://thedailywtf.com/Comments/The_Brillant_Paula_Bean.aspx

Advantage of IEnumerable - foreach versus for loop

One advantage with using foreach loops in the C# language is that foreach eliminates your need to track indexer variables, such as i or x. The code becomes safer and more robust by hiding all the details from the programmers using the array.

http://www.dotnetperls.com/ienumerable-1

also referenced here: http://awglearned.blogspot.com/2012/02/yield-keyword.html

Dependency Injection

One benefit of using the dependency injection approach is the reduction of boilerplate code in the application objects since all work to initialize or set up dependencies is handled by a provider component.[1]

Another benefit is that it offers configuration flexibility because alternative implementations of a given service can be used without recompiling code. This is useful in unit testing, as it is easy to inject a fake implementation of a service into the object being tested by changing the configuration file, or overriding component registrations at run-time.

http://en.wikipedia.org/wiki/Dependency_Injection

JavaScript prototype property

In JavaScript, object creation is prototype-based...an object creating function can have a prototype property, and any object assigned to that property will be used as a prototype for the objects created with that function.

http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework

Object.prototype.inObj = 1; function A(){ this.inA = 2;} A.prototype.inAProto = 3; B.prototype = new A; // Hook up A into B's prototype chainB.prototype.constructor = B;function B(){ this.inB = 4;} B.prototype.inBProto = 5; x = new B;document.write(x.inObj + ', ' + x.inA + ', ' + x.inAProto + ', ' + x.inB + ', ' + x.inBProto);

http://mckoss.com/jscript/object.htm

String.prototype.trim = function () {

return this.replace(/^\s+|\s+$/g, "");

};

http://alvinabad.wordpress.com/2009/02/12/extending-javascripts-string-object/

C# uses events as special delegates

"C# uses events as special delegates that can only be fired by the class that declares it. "

http://en.wikipedia.org/wiki/Event_(computing)