Thursday, April 13, 2006
The need for public method vs. published method
A public method is relying on a language syntax to make it public, usually a concrete class that contains public method will
mark its methods signature with a "public" keyword.
A published method is relying on a language interface to make it published. Usually a concrete class will implement some interfaces
that will contain methods, and in it is a contract that the particular class will abide.
The need for published method arise when different client will be exposed to different "public" method, ie. instead of exposing the
concrete class, we're only exposing certain methods to the client based on what the client "need" or allowed to access. When design
correctly published methods in interfaces can decouple client with concrete implementation of the class while supporting the Open Close
Principle.
For example, when using class to just expose its data for setter/getter to a client front end, to be mapped to user fields, the creator
of the class doesn't need to make other state changing methods that would otherwise be called by the layer where it isn't supposed to. Thus
exposing only the interface for getter/setter to the presentation layer, will prevent client on the layer to perform any business logic that
would have to be done in the other layer.
This idea was introduced by Robert Martin in his Seggregated Interface Pattern. The pattern was created to support the idea that different clients
will have their own need and concerns, thus they don't have to / shouldn't be exposed to just "one" interface, ie. the concrete implementation of
the class.
mark its methods signature with a "public" keyword.
A published method is relying on a language interface to make it published. Usually a concrete class will implement some interfaces
that will contain methods, and in it is a contract that the particular class will abide.
The need for published method arise when different client will be exposed to different "public" method, ie. instead of exposing the
concrete class, we're only exposing certain methods to the client based on what the client "need" or allowed to access. When design
correctly published methods in interfaces can decouple client with concrete implementation of the class while supporting the Open Close
Principle.
For example, when using class to just expose its data for setter/getter to a client front end, to be mapped to user fields, the creator
of the class doesn't need to make other state changing methods that would otherwise be called by the layer where it isn't supposed to. Thus
exposing only the interface for getter/setter to the presentation layer, will prevent client on the layer to perform any business logic that
would have to be done in the other layer.
This idea was introduced by Robert Martin in his Seggregated Interface Pattern. The pattern was created to support the idea that different clients
will have their own need and concerns, thus they don't have to / shouldn't be exposed to just "one" interface, ie. the concrete implementation of
the class.
Wednesday, April 05, 2006
Why big upfront design will never work.
- According to McConnell, design effort consume about 75% of the whole development effort, thus investing that much time without proving that it works
make the whole effort very risky
- design with UML can't be verified, the best we can do is peer review, but without automated verification tool, and relying on human effort also increase
the risk of design correctness, esp. since design is largest effort in the whole software development
- nature of human being is to work best when dealing with multiple smaller things instead of big thing at once in order to lower the risk of incorrectness
- unpredictable requirements due to designer understanding of the problems to be solved, the analyst effort of their gathered requirements, the customer
needs of what he/she wants are not perfect from the get go. Business also evolves what's good now might not be good in the future
This doesn't mean that there isn't a case where big upfront design can be made to work, such case where it can work are as follows:
- software migration development in which all requirements are solid and will not change, assuming the analyst, customer and development team had worked
with previous product that needs to be migrated
- governmental type of project where they could afford to spend a lot of money and a lot of time and also be able to absorb any losses necessary, think about
big weapons or airplane project that had cost billions of dollars but were never used
The best thing is to be able to recognize how agile we can be, or how much plan do we need to have without stranglehold the development process and become
inefficient. How agile measure sucesful project is by how much business value the system adds for the customer, while also keeping the cost and budget
reasonable.
"A late change in requirements is a competitive advantage" - Mary Poppendieck
make the whole effort very risky
- design with UML can't be verified, the best we can do is peer review, but without automated verification tool, and relying on human effort also increase
the risk of design correctness, esp. since design is largest effort in the whole software development
- nature of human being is to work best when dealing with multiple smaller things instead of big thing at once in order to lower the risk of incorrectness
- unpredictable requirements due to designer understanding of the problems to be solved, the analyst effort of their gathered requirements, the customer
needs of what he/she wants are not perfect from the get go. Business also evolves what's good now might not be good in the future
This doesn't mean that there isn't a case where big upfront design can be made to work, such case where it can work are as follows:
- software migration development in which all requirements are solid and will not change, assuming the analyst, customer and development team had worked
with previous product that needs to be migrated
- governmental type of project where they could afford to spend a lot of money and a lot of time and also be able to absorb any losses necessary, think about
big weapons or airplane project that had cost billions of dollars but were never used
The best thing is to be able to recognize how agile we can be, or how much plan do we need to have without stranglehold the development process and become
inefficient. How agile measure sucesful project is by how much business value the system adds for the customer, while also keeping the cost and budget
reasonable.
"A late change in requirements is a competitive advantage" - Mary Poppendieck
