|
jschell wrote:
Yes, but does that really relate to what GoF defines?
I'd seriously wouldn't know, I don't go there often 
jschell wrote:
When you and/or the Architect says 'Factory' in a design discussion is the idea that it will follow, exactly, the first definition above?
No, just the generic idea, otherwise he would specify exactly what the requirements are. If he doesn't, then it is up to the developer to choose the most appropriate solution - which usually means going for the simplest thing possible (whilst still only returning an interface).
..but when in doubt, simply ask 
jschell wrote: As for myself I am rather certain I follow neither. I expect that I use "Factory" to mean what GoF documents in the "Factory Method" to be 'ConcreteCreator' and I might use "Abstract Factory" in implementation (if I use it at all) as something that more closely resembles what "Factory Method" is. But not exactly.
Depends heavily on what is required; do you want a static factory, a singleton, or would you prefer an object? If it has to be combined with an object-manager pattern, then I'd think that the object is preferred. Do you want one object, or do you want multiple objects? In the first case, all objects created in the factory will be available over the manager globally. In the second case, only those objects are available that the specific factory created (in that thread).
Point is, you don't want to explain how a "single point of creation in code" can save you from having to update a 1000 references in code where there's normally a "new"-keyword. That's the problem that a factory solves, with the trade-off that one introduces a tiny bit of overhead (in terms of execution).
It is not just something you learn to impress during the interview, they're simply descriptions of a way to solve something. Lots of "developers" here would struggle with a undo/redo pattern, while others simply request a memento-pattern.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
All true, but in terms of the OP the specifics of what is in GoF doesn't seem to really have been all that useful useful.
|
|
|
|
|
Seems like a collection of formalized descriptions of some common patterns, but without much explanation.
I don't think the website is meant as a source to learn those patterns; that is what their book is for
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Seems like a collection of formalized descriptions of some common patterns, but without much explanation.
Ok, but I was actually referencing the book. The copy of the book sits on my shelf above my computer. Been there for years.
|
|
|
|
|
Quote: The "patterns" are out there and are being used; whether the "users" realize it or not.
Patterns like the "copy/paste"- pattern and the "do it fast and Dirty"- pattern 
|
|
|
|
|
Or brain patterns: scales; fretboards.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
As has been amply pointed out, people do use code libs whose structure is based on the instantiation of design patterns whether they know it or not.
My question was more about "do you use patterns," but I get and agree with your point.
Once one has an understanding of the more common patterns, one starts to see them everywhere; kind of like buying a make and model of car you've never owned before and then suddenly seeing them on the road everywhere.
Thank you to those who responded. You have been helpful and have convinced me it's time to reacquaint myself with the subject. I also appreciate the links.
Cheers,
Mike Fidler
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
"I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
|
|
|
|
|
MikeTheFid wrote: I have referred to it and used patterns on only a few occasions since then. It never really caught on with me and became an automatic go-to while I'm at the design stage.
Because the reality is that most of those patterns have little usage in the vast mess that is implementation.
Not to mention of course that singleton, which is the only one used a lot, tends to be used incorrectly a lot as well. So that didn't help much.
MikeTheFid wrote: Do you use design patterns on a regular basis?
In the generic sense, not the book, yes.
MikeTheFid wrote: If you use patterns regularly, do you have a source or sources of new patterns?
My head. And not as rigorously as GoF defines it.
I looked at several of the follow on books to the GoF and found that most were really struggling to find patterns. That along with how seldom I had seen (even then) most of the patterns in the GoF didn't really bode well. Further experience seems to have supported my determination that although the idea was valid it just wasn't prevalent enough to attempt to normalize it.
|
|
|
|
|
jschell wrote: Not to mention of course that singleton, which is the only one used a lot
The decorator is used throughout the .NET framework (streams), as well as the command-pattern, factories (DbFactory, ThreadFactory), strategy-patterns, object-managers..
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: The decorator is used throughout the .NET framework (streams),
Yes I stand corrected. It is used in other frameworks and languages as well. Perhaps percentage wise used more correctly as well.
|
|
|
|
|
Hi All,
I want to create software for education like wordshark and numbershark but not sure what language to use java or C#
Thanks for your help
Ch
|
|
|
|
|
Whichever you're better at. If neither, then either will do.
|
|
|
|
|
I have recently started exploring DDD and planning to use it. I am looking for some clarifications for which I have created a sample problem and designed a solution using DDD followed by some questions. Please go through it and revert should you need further details.
Problem Statement: Architecture a manufacturing station for Vehicles which allows assembling of different parts and creating a vehicle.
Architecture Style: Domain Driven Design (DDD)
Domain terms and relationships
- Manufacturing Station may have 0…* vehicles
- Vehicle may be a Car/Truck etc.
- Vehicle may have Engine, Transmission, Wheels, Music Player, Rear View Camera, etc
- Engine could be of Petrol/Diesel
- Transmission could be Auto or Manual
- Wheel may have Tube or Tubeless Tyre
- There may be millions of parameters within a vehicle such as Speed, RPM, Tyre Pressure.
- A group of parameter belong to a certain component (Engine, Transmission, Wheels, etc).
Hierarchical representation of System
- Manufacturing Station
o Vehicles
Car/Truck
• Engine (E)
o Petrol/Diesel
• Transmission (T)
o Auto/Manual
• Wheels (W)
o Tube/Tubeless
• Parameters (Could range upto millions)
o Speed - E
o RPM - E
o Coolant - E
o Tyre Pressure - W
o Audio Level
o RearCameraOn
o DoorLocked
DDD Solution
Bounded Contexts (Identified)
Station
Vehicle
Engine
Transmission
Wheels
Bounded Context Details
Bounded Context – Station
Aggregate Root
o Station
Slots : List<slot>
Entities
o Slot
o Vehicle : Car/Truck
Value Objects
Repositories
o StationRepository
Services
o SlotService
Events
o VehicleAllocatedToSlot
o VehicleDeallocatedFromSlot
Bounded Context – Vehicle
Aggregate Root
o Vehicle : Car/Truck - How to manage inheritance and new vehicle types such as Bus
Parameters: List<parameter>
Entities
o Registration
o Chassis
Value Objects
o Manufacturer
o Model
o Parameter
Name
Value
Type
Default Value
Unit
o Audio System
Repositories
o VehicleRepository
Services
o AssemblingService
Events
o VehicleCreated
o VehicleDeleted
o VehicleRegistered
o VehicleDeregistered
o AudioSystemAdded
o AudioSystemRemoved
Bounded Context – Engine
Aggregate Root
o Engine
Parameters: List<parameter>
Entities
o ElectronicControllingUnit
Value Objects
o Gas Pump
o Valve
o Filter
o Fan
o Parameter
Name
Value
Type
Default Value
Unit
Repositories
o EngineRepository
Services
Events
o EngineCreated
o EngineRemoved
o FilterAdded
o FilterRemoved
o FilterReplaced
o GasPumpAdded
o GasPumpRemoved
o GasPumpReplaced
o FanAdded
o FanRemoved
o FanReplaced
Questions:
- DRY is violated. We could see Parameter defined in almost all the services.
o Is it advisable to have a separate service for Parameters? In that case, does a component(Engine Or Wheel) keep a list of parameter id within itself OR each parameter hold a parent Id? - How does a client create a Car with Engine,Transmission and 4 wheels in a single call?
- How does the relationship between different components achieved? Fo e.g how does a specific engine know to which car/truck it belongs to? How can we reconstruct a car/truck?
- How to manage inheritance depth using DDD?
o Vehicle -> Car -> Ford/Toyota? - How to manage deep level composition using DDD? How do we flatten the aggregates?
o Station -> Car -> Engine -> Fan -> Parameter(Fan Sped) -> value
Station.Car.Engine.Fan.Speed How to retrieve Speed(Parameter) value in other Bounded context
Thanks in advance!
|
|
|
|
|
Praveen Raghuvanshi wrote: I have recently started exploring DDD ...Architecture Style: Domain Driven Design (DDD)
Had to look that up and I can say is...versus what other idiom exactly?
If you are not designing for the domain, then you are not solving the domain problem. Seems like there is no alternative there.
So any process that reaches a solution of the domain would be DDD. Anything that doesn't would be, by definition, a failure.
Praveen Raghuvanshi wrote: Domain terms and relationships
Hard to read (you could format it) and seems likely (guessing on a quick look) that you have an entity model. If so then you should start with the entities themselves first, before adding details (attributes.) Then add major attributes to clarify functional needs. And likely skip non-significant attributes at all for the model (they are implementation details.)
Praveen Raghuvanshi wrote: o FilterAdded
o FilterRemoved
o FilterReplaced
Domain modeling should start with the actual/real domain.
Above doesn't represent a real domain. When you build a car from scratch you don't remove nor replace the filter. If you service a car you might replace it, but that is not part of building the car from scratch.
Modeling the entire real world eco-system of manufacturing to servicing is too large for a single model and would not be approached that way.
|
|
|
|
|
You're modelling a "Bill of Materials" for a vehicle's "dealer invoice".
Not exactly a "vehicle manufacturing station". For that, you need more "functionality".
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Can you share some thoughts on modelling this problem?
|
|
|
|
|
You have not stated (or determined) what "problem" you are trying to model / solve.
Stating that one wants to build a "car manufacturing station" is not a proper "problem definition" and will lead to nada.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
I created an Azure SQL server VM and am unable to connect to it with SSMS.
I followed this article: https://forums.asp.net/post/edit/6168801
Now when I go to my local machine cmd prompt and type:
ping trainingsqldev25.eastus.cloudapp.azure.com
I can see the ping resolve the DNS name to the correct IP address but the requests still time out.
|
|
|
|
|
|
Installed the latest version of SSMS and used my host name as follows:
trainingsqldev25.eastus.cloudapp.azure.com, 1433
I still can't connect. Now, everything I find on the internet points to the same article:
Provision a SQL Server Virtual Machine | Microsoft Docs[^]
Here I recreated my SQL VM several times and still the same results.
|
|
|
|
|
I will note that ping is not a good way to test connectivity.
Much better to use 'telnet' and provide the domain and port. Success is with a blank screen and failure is when a error message it reported.
|
|
|
|
|
Hi All,
I am preparing for Java Architect and not able to understand the diagrams used for software architecture and high level design diagrams..
|
|
|
|
|
You need to start learning Software Engineering, and in such a course you can learn those diagrams. Typically you would be needed to learn how a user would be using the application, how the data flows, and how application works. So there is a diagram for all of those, which you must know. It would be best, if you could join a local institute where they train and teach you, online and self-paced would still be confusing.
Software engineering - Wikipedia
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
UML would be a good preparation
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
As already pointed out learning UML is a good starting Point for a object-oriented language like Java.
I can recommend the book "Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development" by Craig Larman [^] to learn about how to actually apply modelling in real scenarios.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
