Originally Posted by
alexdevmaster
Ive also found that many people who use design patterns use them using the exact same names for certain methods as outlined in literature, say given classes Observer and Observable, they would inherit or impliment these classes such that their interface includes methods named like observe, notify, addSubscriber, etc. I think it would be better to write methods that better communicate what u want to do and even hide the design pattern specific speach inside your class with the appropriate code documentation, the result being code better communities what its doing as opposed to the emphasis on how its doing it.
actually i disagree-ish... code that uses names from design pattern retain the names to indicate that they are low level code, objects that form the framework of your application.
now lets say u inherit that functionality in a business object, thats where u use the business friendly names and lose the framework/design pattern name.
as an example, microsoft implements base classes and interfaces to connect to a database in ADO.NET...
Code:
ICommand ... Command design pattern
IConnection ...
IDataAdapter ... Adapter design pattern
then in another layer, it implements these classes, keeping the design pattern names
Code:
SqlCommand ... Command design pattern implementation
SqlConnection ... implementation
SqlDataAdapter ... Adapter design pattern implementation
now thats still framework, so when it reaches ur level u dont need to say that u have connections and commands, what u need are Users and Managers etc
Code:
IUser ... models a user
IManager ... models a manager
next layer, implementation... business objects with business rules, they dont even know theres a database, with stored procedures, etc
Code:
Cambio.Data.User ... implements a user
Cambio.Data.Manager ... implements a manager
next layer ...implements crud operations, ur classes use the connection/command and dataadapter, but u shouldnt expose it on ur interfaces or business objects
Code:
Cambio.DataAccess.User
Cambio.DataAccess.Manager ...